Agency, freelancer, or first in-house hire
Each suits a different stage. A freelancer is cost-effective for contained, well-specified work but represents a single point of failure. An agency provides a team, an established process, and continuity, which suits a genuine product or an ongoing build. A first in-house engineer makes sense once the software is core and permanent, though hiring well is difficult and slow when you cannot yet assess the work yourself.
Many companies engage a partner to reach a working, proven product, then hire in-house to own it. That approach depends on the partner having built the product to be handed over.
Warning signs when evaluating a partner
The clearest signs tend to appear in the first few conversations.
- A large fixed price quoted before they understand your problem.
- An inability to explain their technical choices in terms you can follow.
- No clear answer on who owns the code, accounts, and intellectual property; it should be you.
- Everything built bespoke and unusual, making it hard to hire for and maintain.
- Vagueness about what happens after launch, or support treated as an afterthought.
Fixed-bid versus time-and-materials
A fixed bid feels safe because the figure is known, but it shifts risk onto the vendor, who protects against that risk by padding the price and resisting change. It suits genuinely well-defined work. Time-and-materials suits real product work where you will learn and adjust as you go; it requires more trust and visibility but does not penalise you for changing direction. The healthier arrangements are transparent either way, with progress visible each week and no surprises on the invoice.
What a custom build actually costs
Any precise price quoted before the partner understands your problem is a guess. Cost is driven by scope, complexity, the number of integrations, and how much of the work is genuinely new rather than standard. A more useful question than what it costs is what the smallest version that proves value would cost, since that figure is far lower and far less risky, and the answer tells you whether the partner is thinking in your interest.
Brief well and insist on a clean handover
You will get better results by briefing well: the problem, who it is for, and what success looks like, rather than a list of features you have guessed at. From the outset, agree what handover includes: source code in your repositories, your own accounts and infrastructure, documentation, and no lock-in. A good partner builds as though you might take the work in-house one day, because that is what protects you.
