Commission custom software and you’re not hiring a product, you’re hiring a team. As a client you can barely judge the code; you can judge the people who write it. Yet conversations with a software partner tend to focus on technology and price, rarely on who will actually work on your system.
Most advice on the ideal team composition is written for organisations building their own development department. For most companies the situation is different: you’re hiring in a team and need to be able to tell whether it’s any good. That doesn’t call for recruitment expertise, just a sharp eye on a few points.
The roles you want to see in place
A team delivering custom work needs more than programmers. Someone has to translate your work process into functionality and guard the priorities; one agency calls that role product owner, another project lead. You also want developers who are equally at home with the interface and with the underlying logic and integrations, and a way of working where testing and reviewing each other’s code are standard practice.
More important than job titles is whether those roles are actually covered. Ask who your fixed point of contact will be, and whether you speak to the people doing the work. If an account manager sits between you and the team, every question gets translated twice, and something gets lost along the way.
Small and experienced beats large and layered
A large team sounds like a safe bet, but it often works the other way round. Every extra person means extra coordination, and you pay for that overhead. A compact team of experienced engineers who know each other’s work moves faster and makes fewer mistakes than a layered organisation where work passes from hand to hand.
So don’t look at the headcount on the quote, but at who actually works on your project. Are those the engineers who will build it, or a sample team assembled for the sales pitch? And is there seniority in the places where the difficult decisions get made, such as the architecture and the integrations with your existing systems?
Continuity is the quiet condition
Custom software lasts for years, and a great deal changes over that time: people leave, your organisation grows, requirements shift. So the question isn’t just who builds it now, but how knowledge is retained. If everything sits with one developer, your project grinds to a halt the moment that person is unavailable.
A few questions that quickly expose this:
- Does more than one person hold knowledge of the system?
- Is there documentation that lets a new engineer take over the work?
- What arrangements apply to maintenance and further development after delivery?
You’ll find more questions like these, including on source code ownership and budget, in what to ask before commissioning bespoke software.
The first conversation gives the collaboration away
The best predictor of a good working relationship is how the first conversation goes. A strong team asks about your goals and your work process before it starts talking technology, and is willing to say what doesn’t need building. A team that arrives with a solution straight away ends up building what was asked for rather than what’s needed.
That’s how we work ourselves: we develop custom applications in compact teams of software engineers, with a fixed point of contact who knows the subject matter. Bring us your challenge, and you’ll also hear what the team taking it on looks like.