Freelancer, Agency, or In-House? Choosing How to Build Your Software
An honest comparison of the four ways to build software in Kenya — freelancer, local agency, offshore firm, in-house team — what each is genuinely good at, and the questions that separate a real partner from a plausible one.
Choosing who builds your software is a bigger decision than choosing what to build, because the wrong build can be rewritten and the wrong relationship usually cannot be rescued.
There are four realistic options and none is correct in general. Each is correct for a particular situation, and the mistake is almost always picking on day-one price rather than on what the arrangement looks like a year in — when the original developer has moved on and something has broken in production.
| Freelancer | Local agency | Offshore firm | In-house team | |
|---|---|---|---|---|
| Upfront cost | Lowest | Moderate | Often low | Highest |
| Continuity if one person leaves | None | Team absorbs it | Varies widely | Team absorbs it |
| Timezone and context | Usually aligned | Aligned | Frequently not | Aligned |
| Understands local rails (M-Pesa, KRA) | Sometimes | Usually | Rarely | You must hire for it |
| Accountable to a contract | Weakly | Yes | Yes, but enforcing it is hard | Employment, not contract |
| Good for a short, well-defined build | Yes | Yes | Yes | Overkill |
| Good for a long-lived core system | No | Yes | Risky | Yes |
| Ramp-up time | Days | Weeks | Weeks | Months |
| Who owns the knowledge afterwards | They do | Shared, if you insist | They do | You do |
The failure mode that should shape your decision
Software projects in this market rarely fail during the build. They fail afterwards, and they fail in a specific, boring, repeated way: the person who understood the system is no longer available, nobody else can safely change it, and the organisation is left with an asset it cannot maintain and dare not touch.
This is why the single most useful question is not "what will this cost?" but "what happens in month fourteen when something breaks and the person who wrote it is gone?" Ask each candidate that question directly. The quality of the answer will separate them faster than any portfolio.
When a freelancer is genuinely the right answer
For a small, well-defined, bounded piece of work — a landing page, a specific integration, a prototype to test an idea before committing — a good freelancer is often the best value available, and hiring an agency instead is simply paying for overhead you do not need.
The risk is structural rather than a matter of talent: a freelancer is one person, and one person can get ill, take another contract, emigrate, or simply stop replying. That is survivable on a two-week build. On the core system your business runs on, it is an unhedged dependency on a single human being, and it will eventually be called.
What offshore actually costs
Offshore quotes can look decisively cheaper, and sometimes the work is genuinely good. But the headline rate omits the costs that arrive later: the timezone gap that turns a same-day clarification into a two-day round trip, the context gap where a team that has never used M-Pesa builds a payment flow that is technically correct and practically unusable, and the enforcement gap where your contract is theoretically binding and realistically unenforceable across jurisdictions.
The hidden multiplier is communication overhead. Every ambiguity in a specification costs a full day rather than five minutes, and specifications are made of ambiguity. Teams do not discover this while negotiating; they discover it in week six.
For commodity work with an unambiguous specification, offshore can work well. For anything requiring judgement about your business, local context, or Kenyan payment and tax rails, the saving tends to be recovered by the market — with interest.
The questions that actually separate vendors
Portfolios are curated and references are pre-selected, so neither will tell you much. These questions will, because they are difficult to answer well without actually being good.
- Who owns the intellectual property and the source code when we are finished? Get it in writing, before you sign.
- Where does the code live, and do we have access to that repository from day one?
- What happens if we want to leave and take the system to another team?
- Show me a project that went wrong and tell me what you did. Everyone has one; only the honest will tell you.
- Who specifically will do the work — the people in this room, or someone I have not met?
- How do we see progress before the end? A vendor that cannot show working software until delivery is asking you to trust rather than verify.
- What happens after launch, and what does that cost?
The clause that matters most, and is most often missing
Source code ownership and access. We are regularly approached by organisations that paid in full for a system they cannot obtain the code for, cannot deploy without the original vendor, and cannot move elsewhere. The leverage that creates is total, and it was created at signature by a clause nobody read.
Insist on this: the code lives in a repository you own or have full access to, from the first commit rather than at handover. Documentation and deployment runbooks are deliverables, not favours. Intellectual property transfers to you on payment, stated explicitly.
A vendor confident in the value of their work will agree to all of this without hesitation, because they expect you to stay for reasons other than that you cannot leave. A vendor who resists has told you something important, and you should believe them.
Key takeaways
- Projects fail after the build, not during it — choose for month fourteen, not day one.
- Freelancers are excellent for bounded work and a single point of failure for core systems.
- Offshore's headline saving is often recovered by timezone, context and communication overhead.
- Ask who owns the code, where it lives, and what leaving looks like — before you sign.
- A vendor who resists giving you repository access has told you something. Believe them.
Frequently asked questions
How do I know if a quote is too good to be true?
Look at what the quote assumes rather than what it charges. A number produced without anyone asking about your integrations, your data, your users or your existing systems is not a quote, it is a hook — and the scope conversation you did not have upfront will be had later, through change requests, at a price you no longer have leverage over. A credible vendor asks uncomfortable questions before quoting.
Should I hire in-house developers instead?
In-house is the right answer when software is core to how you compete and you will be changing it continuously for years — that is when owning the knowledge internally compounds. It is usually the wrong answer for a single project with a defined end, because you take on permanent salary, recruitment and management overhead to solve a temporary problem, and you must be able to attract and retain engineers, which is its own discipline. Many organisations sensibly do both: an agency builds the first version, and an in-house team takes it over once the direction is proven.
What should be in the contract?
At minimum: explicit intellectual property transfer to you on payment; your access to the source repository from day one, not at handover; documentation and deployment runbooks as named deliverables; a defined scope with an agreed process for changing it; and clear post-launch support terms including what it costs. If a vendor pushes back on any of these, that is information about what your relationship will look like when things get difficult.
Does local knowledge of M-Pesa and KRA integrations really matter?
If your system touches payments, invoicing or tax in Kenya, yes — significantly. These integrations have real-world behaviours, edge cases and operational quirks that are not in the documentation and are learned by having shipped them before. A team encountering them for the first time on your project will learn on your budget and your timeline, and the gap usually shows up as a flow that is technically correct and practically unusable.