Choosing a software development agency for your project
Recently I’ve been doing some advisory work with a new fintech startup who are building a brand new greenfield finance application. While they’re testing their product market fit, it doesn’t make any sense to start bringing a permanent team of developers onboard, so I set out to find a great development agency to task with the initial MVP platform build which could then be handed over to a permanent team once the MVP is validated.
Now, finding a good development agency is a pretty intimidating task. The market is saturated with companies that, on paper, seem to be pretty much identical with the services they offer. However there is definitely a very large gap in quality depending on which company you choose. Choosing the right company gets your product off to a great start and really sets you up to succeed; getting it wrong may sink you before you even get going.
Preparation is definitely key. Before you’ve even had your first conversation with any potential agencies, invest some time in really understanding what the problem is you’re trying to solve and how you think you’re going to set about solving it, really deeply understand what your goals are and what you’re trying to achieve.
For me, this involved understanding the MVP functionality from a business point of view, so really thinking about the 1–3 key things that the product needs to be able to do to prove itself on the market to solve the problem you’re looking to solve. The key here is to limit your functionality to a minimum set as possible. You don’t want to spread your scope too wide when you’re validating your idea.
MVP and high-level specification
For this project, we had a good idea what we wanted it to do for MVP (using a mixture of market research, user interviews and user testing), so it was then a debate between the CEO, myself as CTO and the lead Product Manager to create the smallest list of features possible for MVP. We eventually settled on 3 features we thought of as mandatory to prove the idea.
Using these 3 features, I then got to work writing up a high-level technical spec of how this thing could be built. I spent time looking into what the best tech stack for the project would be (more on that in a second), I also did research looking into tools and SDKs we could take off the shelf (at this stage of product development, don’t reinvent the wheel. If something is not your USP and it’s already a solved problem, take a tool off the shelf. Don’t waste crucial time building something that’s not going to be your differentiator). Once I had a good view of the tech stack, I put together a high-level architecture plan as well as flow and interaction diagrams to show where we’d need to do development and how this would interact with the 3rd party tools.
Don’t forget to spend some time thinking about how you’re going to track the success of your MVP. By this I mean making sure you have the right level and types of analytics tools built in so you have the data to determine what’s working and what’s not.
Tech stack selection
Selecting a language and a framework can be a contentious task, but the key is choosing a tech stack that is not only easy for you to scale and support as your company succeeds, you also want to make it an attractive stack to hire developers. If you’re going to be doing the build yourself, you can get away with using something that you know so long as you accept that it may need a refactor in the future. Don’t fall into the trap of spending too long building the perfect tech stack before you’ve solved your product market fit. Don’t spend months attempting to architect a complex system that you don’t yet know, speed is what you’re looking for to find your product market fit. You’re not going to hit Facebook scale on day 1.
So you need to be pragmatic about the payoff of what will get you to market quickest but also set you on a solid technical footing to succeed. Good software architecture is a constantly evolving task and the correct solution for your product absolutely depends on what scale you’re operating at.
As I wasn’t going to be doing the build of this project myself given we had seed funding to invest in the build (plus I have neither the time nor am I the best coder in the room!) I had the luxury of leaning towards the best tech stack that would scale in the future as it didn’t have to be one I was an expert on.
It’s important to stress the tech stack is your choice. Your chosen agency can give you insights and help you make decisions based on their past experience, but the overall technology choice is yours. This is your product and you’re going to be living with the output the agency build, so it needs to be a choice you’re comfortable with. The tech stack you choose will also help you narrow down your agency choice as agencies tend to specialise in specific stacks.
Be clear about what you’re looking for
Now you have a good idea of what it is you want to build, what the scope of the project is, what your tech stack looks like and what your goals are, have a think about what you want from your development agency. Think about things such as:
- Country (can you meet face to face easily)
- Timezone (if there enough cross over with your timezone)
- Spoken language preferences
- Contact with developers
- Skill requirements for your team (at the very least you’ll need a Product Owner on your side)
- Past projects and specific domain knowledge and experience
- Skills (both technical development skills in the stack you choose but also UX, UI etc)
- Developer availabilty (both start time and ramp up time)
- Project development methodology
Pull together your long list
Using your short list of criteria you’re looking for in your chosen agency, you can now get started trying to find your perfect fit. For me, this involved hitting my network to get some recommendations for agencies that had expertise in both the tech stack and market we were looking to launch in. If you don’t have the benefit of good network, LinkedIn can work well or try plain old googling.
Have a look at their websites, look at their case studies and companies they have worked with in the past, pay special attention to those in a similar market to you and what their technical skills are. It’s also worth looking at the credibility of their management team and check on LinkedIn to see the size and skills of their team.
Using all this information, you should be able to draw a long list of up to a dozen potential companies
Narrow the list down
Now you’ve got your long list, you need to start narrowing it down to less than half dozen agencies. Reach out to the companies directly and talk through your requirements. This includes both the functional requirements of your build and non-functional requirements of the type of agency you want to work with. Also ask them for references for other companies they’ve worked with that are similar to what you’re doing, be it in tech stack or product type. You’ll want a contact you can speak to on the phone to have a proper discussion about their experience of working with the agency. You’ll be able to easily eliminate a couple of agencies at this stage.
Get into the details
Going into the RFP process you don’t want to be speaking to too many agencies otherwise you’ll quickly become overwhelmed. 2–3 is ideal. Here you’re going to go through the project is much more detail (make sure you’ve both signed NDAs) and get the agency to put some numbers against it such as the size of team they think they’ll need, day rate for each member of the team as well as indicative view of time of delivery. You need to make sure they’re really clear on your business goals and the future strategy for the company as this will affect their approach to the build.
For an agile project it’s impossible (and not advisable) to try and push the agency to commit to a strict delivery timescale (you may as well go for a waterfall, fixed delivery if you need to be this predictable), you’re just looking for an indication so you can plan around it.
For this project I wanted to get an idea of the roadmap to deliver so I could manage costs but also so I knew when I could start looking to augment my own team into the project. It’s important that you bring your own permanent staff on board at the right time to make the process of handover as seamless and pain free as possible. As you’re starting to find your product market fit the last you thing you want is a lull in delivery because the agency has rolled off and your permanent staff either haven’t joined or aren’t yet up to speed.
An important note: don’t be totally fixated by price. You need a quality application, not a cheap one, so don’t be tempted by the low prices that some companies offer. Choosing cheap development is a shortcut to disappointment. Make sure you’re making the decision for the right reasons.
Once you’ve agreed all costs, signed the contract and chosen the team structure it’s time to get started! The first couple of weeks will be mainly getting everything setup and starting the infrastructure build out, after that every couple of weeks you should be having a demo of what’s been produced. It’s a really good idea to have your own dedicated product owner assigned to the build that works for you so you can keep close tabs on the project. This person can then be directly involved in the daily standups and bi-weekly grooming sessions and will be the main contact for any business questions.
Hopefully that gives you a bit of an idea of the process I went through to choose a development agency for this project and has given you some ideas for choosing one for your own. If you have any questions don’t hesitate to get in touch, I’ll keep you updated with how the build progresses!