You have an idea, or you’re looking to solve a problem. And you have, in your mind, already worked out how you want your product or solution to work.
All you need now is for someone to build it for you.
So, you look for a software development agency.
You speak to a few companies. You even like a few of them. You tell them your requirements, and you get quotes.
Some of them are amazing. For $20,000, you’ll get your entire solution built for you. All you have to do is wait 3 months.
Fast forward 6 months, or 9 months later, and you’ve spent something closer to $60,000, or $100,000. You see a product, but it’s riddled with problems and bugs. Even really obvious ones.
It’s nothing like what you envisioned you were going to delight your users with. You don’t even want to show it to your early users, because it’s embarrassing. It’s not to your standard.
Why did that happen?
The reason
Let me share with you the reason: There is usually no alignment of interests.
You want your product to be perfect. The software agency that you hired wants to get paid, and get more clients.
Unless the software agency is in it for a long-term relationship with you, and believes that the long-term relationship is mutually beneficial, your project is nothing more than a quick job. The agency has no real motivation to test every corner case, and give your users that polished, satisfying experience.
If you think about it, it’s quite common. If you drop your car off at a workshop, a good number of times you will get repairs that you don’t need, a bill that is higher than you expected.
Not all workshops do that. There are some with incredible integrity — who see their business in terms of long-term customers and an impeccable reputation. And they do their work with pride. They’re the real professionals, not just in skill, but in how they approach business.
They’re just fewer of them around.
And it’s the same with software agencies.
Does that mean I should never hire a software agency?
What do I do then? Are all software projects built by an external team doomed to failure?
Not quite. But you do need to find the right agency.
I’ll share with you questions you can ask, to help find the right one.
1. How do you make sure you understand what I want to be built?
Ideally, even from the 1st meeting with you, your agency should demonstrate an incredible ability to understand what you need, and clarify edge cases of what you’re asking for.
In fact, in my experience, the more edge cases they bring up that catch you a little by surprise, in that you didn’t consider it before, the more likely they will build you a correct, robust product.
A professional will not shy away from digging deep, tossing it around mentally, to see what was missed. A professional will also not avoid building the entire picture in their head, to see if all the parts fit together.
Because if there are missing aspects, or if the parts don’t fit together, how would your product even work, much less give your users a good experience?
2. How do you test to make sure things really work?
Ideally, your agency should tell you that as they build your software, they also build automated tests for it.
And they, of course, also perform human testing to catch those cases that automated tests may not.
In the professional world of software, automated testing is paramount. Yet, very few software agencies do it.
It makes perfect sense if you think about it. This is a software project. The team building it are software engineers. Software engineers should be able to automate testing.
Why is this important? For a very simple reason.
Computers don’t get tired. Once a test is written, the computer can be told to execute it every single time a new feature is added to the project. This can happen dozens or even hundreds of times a day.
What this does, is ensure that as your product is built and new features are added, things that were already working, remain working.
This does not replace human testing. But automated tests are incredibly powerful, and should be a part of any professionally built piece of software.
3. When we inevitably miscommunicate, how will you handle that?
Ideally, your agency should tell you that this is something normal, and they have enough experience to know how to buffer time and expenses for that.
This is also partly why professionally built software costs more.
They should also share with you that if the miscommunication results is a small rework, it’s all taken care of. However, if there is something that is truly a requirement that got changed along the way, then what they will do is to estimate the additional time and effort for that, and let you know about it.
Participate, participate, participate
On your side, as a client, you can also help — by participating early and frequently.
This doesn’t mean you need to spend an insane amount of time. But yes, it means you do need to spend some additional quality time.
Borrowing from Russian culture, what you should do is “trust but verify”. The agency’s team is (probably) far more experienced at building great software. Therefore, trusting them to leverage their expertise is a given.
However, you need to check in periodically, and ask the right questions.
It’s not difficult. Your goal is to behave like how your users would. You know your users best, so you’re the best person to play this role.
Put yourself in the shoes of your users, tell your software agency that is where you’re coming from, and then check in.
- Check on how your system is performing — is it fluid and responsive?
- Check on the user interface — is it clear and does it guide the user and give them confidence?
- Take a look from a distance — does everything come together nicely and cohesively?
And if anything doesn’t quite sit right, flag it out early.
Why flagging things out early is really important
The earlier you flag things out, the more willing your agency will be to change or fix it.
Let me illustrate with an example.
Suppose you’re building your e-commerce ordering system that your customers will use, and you want a feature that “helps to limit the number of a specific item that each of your customers can pre-order”.
Your agency understood this as:
Make sure that 1 customer can only pre-order 5 pieces of product X.
But what you really meant is:
Make sure that 1 customer can only pre-order 5 pieces of product X at a time (i.e. if they place multiple orders, for your business, that’s okay!)
If you realize early that the feature that was built isn’t quite what you want, and let your agency know, they’ll probably quickly and quite willingly change it.
But if you raise it towards the end of the project, that might not be the case anymore.
Why?
Here’s why, from least to most significant:
- They appreciate you raising the issue early.
- The nuances of the feature is still fresh in the team’s mind, and changing it is way faster.
- Other parts of the system have not been built on top of it.
- Fewer automated tests have been written for it.
- The feature has likely not yet gone through days of (human) testing, which would be tossed out of the window when the feature is changed.
The last 3 points are very significant.
If other parts of the system have been built on top of a feature that needs to be changed, those other parts will also need to be changed.
And everything that is changed, will have to be re-reviewed, and re-tested.
That can amount to days, if not weeks of work.
If the agency charges you for it as a “change request”, even if you agree to it, it costs you more. Not to mention the frustration of “they didn’t get me right in the first place and now I have to pay for it?”. Totally understandable.
And, if the agency makes the change for you without charging you, the frustration now transfers to them. “Why couldn’t the client have been clearer from the beginning? This totally changes things!” They’re not getting paid, but have to spend days or weeks of extra time.
Either situation is not a good one. But the fact is, these things will happen.
In our experience, checking in early and often reduces things like this a whole lot.
In fact, doing this well can mean the difference between a successful, on-time product, and one that isn’t.
