Compete on quality
Competing based on charging less than your competitors can help you get your business off the ground, but in the long term, undercutting using pricing is a race to the bottom, and there is always someone in the world who can run faster than you.
Instead of using price, position your business around quality. For a small business building custom software, focusing on "high quality" over "dirt cheap" is generally a better offering, allowing
- An emphasis on craftsmanship over just "cutting code" (I hate that term)
- Stronger client relationships
- A clearer path to becoming a trusted consultant
- Greater chance of repeat business
- A higher hourly/daily/weekly rate
- Meaning more revenue for less effort
The hard part is that everyone already says they focus on high quality work - even those dirt cheap dev shops. So whilst saying it is still important, you need to go deeper, you need to make sure you consistently walk-the-walk.
Quality as your competitive edge 🥊
When I say high quality, I don't just mean in engineering, but quality everything.
- A seamless sales process - making the potential client feel comfortable, really listened to, and that they are talking to true experts in their field
- A structured delivery process - there should be little to no surprises to the client, meaning you have educated them on how it will work, and they understand what their involvement needs to be and when.
- A trusted partnership - your relationship doesn't end when the project ends, you have multiple ways of working long term with them to fit whatever they are looking for.
It's starts at the start 👋
Super professional from the first interaction through to the last - although hopefully the last interaction is many years away.
Sales is one of the most important chances you'll get to differentiate yourself from the competition. You want the potential client leaving that first interaction knowing 2 things
- You truely understand the problem they have
- You have high quality standards and processes that return the best results
They will hear you talk about benefits of the project workshops you've designed from years of experience working with clients like them, and they will also want to hear about (or see) some case studies. I always took the chance to address that although my agency was smaller than the 50+ competitors, here's why I believe small can be great.
The myth around programmers is that they sit in a dark room all day and can't communicate with other (normal) humans. You need to bust this myth, but I also think it's important you don't gloss over the high quality of standards and processes you have in place to deliver their software.
Many software agencies focus so much on the human side (to prove they are human!) they end up skipping over the impressive work they do behind the scenes to ensure high quality. Make sure your clients know about the behind-the-scenes work you do, e.g.
- Store all their sourcecode in a secure best practise distributed version control system
- Architect your code to balance future extendability with speed to market (and you can highlight that this is a spectrum that can be moved to suite their needs, e.g. an MVP)
- Conduct peer code reviews, ensuring multiple developers are across the exact code written. Often involving nuanced conversation about the specific changes to the code, which can then lead to edits of these changes based on the wider teams feedback
- Write automated test cases to not only ensure high quality code at the time of writing, but also act as a regression test suite meaning a long-term investment in quality
Don't go overboard, but make sure they understand what you do is a craft, and that you are a collection of craftspeople that put a lot of effort and energy into ensuring a high quality output.
High quality software 💻
High quality software means a lot of things, and a lot of those are invisible. Easily maintainable, refactorable, testable etc (there are many books on this already), however to your client, the real measure of high quality software is the amount of bugs it has.
Now there are two types of bugs,
- An implementation bug - meaning something you tried to do wasn't working as you expected
- An understanding bug - meaning something between the client and you was lost in translation, and what was working as you expected was not working how they expected
When dealing with implementation bugs, I think first and foremost it's integral to set realistic client expectations, and educate your client right upfront that zero bugs is an illusion. Bugs will happen, it's just a matter of finding them as fast as possible, and it will take their involvement to ensure we - both us and them - find and squash them before they ever get to the end user.
But I also feel it's ultimately up to you to instil within your agency a thorough internal practise for reducing bugs, and letting everyone in your team know the level of quality you are aiming for. Thorough peer code reviews, automated testing, code linting / static analysis, detailed quality assurance testing, and aiding the client to do thorough user acceptance testing - I feel this is a minimum standard to be deemed high quality.
I've also had success with what I call "developer testing" - where once a developer has completed a feature on a specific branch, but before their peers do a code review, another developer manually checks out their branch and does a round of quality assurance testing. Sure, this takes more developer time, but it can fix bugs quicker (before the PR is reviewed), and also helps developers learn other parts of the system they didn't code - which is also great for knowledge sharing.
The second category of bugs is what I call "understanding bugs", and these usually take place in the requirements gather phases - but a misunderstanding can take place anywhere in the process.
From many years running my agency I believe living documentation that is continuously updated from both yourself and the client is a great way to reduce understanding bugs. I know documentation is often frowned upon (it's not agile!), but it worked really well for me, and my clients often asked for this documentation after the project as they also found it so valuable. I will followup with another whole article about this, as it's something I feel strongly about.
Lead by example 📢
I personally met with all new leads for that first interaction. This is a benefit of having a small company, but I knew I didn't want a salesperson in charge of this, as being a highly technical director of the company at that first meeting shows what the business is built upon. If the CEO is that passionate about high quality software, that means something.
I was often heavily personally involved in the scoping phases for sprints. As I rarely wrote the code, having that hands-on time to help map business requirements into technical features is a great opportunity to show that quality you uphold, and that everything you do as the owner, director, CEO of the business - is of that same high quality. This is both beneficial for your clients and your staff to be reminded of, as high quality comes from the top down.