In house developer vs software agency, and what each costs

You have decided you need software built. The next question is usually framed as a budget question: is it cheaper to hire a developer or to pay an agency. That framing produces the wrong answer reliably, because the two options are not two prices for the same thing. They are two different arrangements of risk, and the one that suits you depends mostly on what happens after the first version ships.

Worth saying up front that we are an agency, so read the rest with that in mind. We turn work away for the reasons in the second half of this note, and we would rather you hire than engage us badly.

One hire is one point of failure

A single in-house developer gives you something an agency cannot: someone whose whole attention is your business, who sits in your meetings, and who accumulates context that never has to be written down. That last part is the benefit and the trap in the same sentence. Context that never gets written down leaves when they do.

With one developer, your bus factor is one. Holiday, illness, a better offer, a disagreement with a manager, any of these stop your software work completely rather than slowing it. Teams of two are not much better, because the second person is usually hired later and inherits nothing but the code.

The mitigation is documentation and it is the first thing to get dropped when one person is the whole function. If you hire, treat writing things down as part of the job description rather than as overhead, and give it time in the week.

Most developers do not work where you think they do

It is worth checking your instinct about what a normal setup looks like. Stack Overflow's 2025 developer survey asked about company size, and of the 28,488 people who answered, 3.9 percent said they work alone, 17.2 percent at companies with fewer than 20 employees, and 20.8 percent at companies of 20 to 99. The survey also states that 57 percent of employed respondents work for companies with fewer than 500 people. On the employment question, answered by 48,178 people, 13.9 percent described themselves as an independent contractor, freelancer or self-employed. The published breakdown is worth reading directly.

Two things follow. Small-company development is the normal case, not a compromise, so you are not doing something unusual by running a team of one or two. And a meaningful share of the market is contracting rather than employed, which means the people you would most like to hire may not want a salary from you at all.

The cost comparison, done honestly

We cannot give you local rates. We do not have a defensible dataset for developer salaries in Cairo, Riyadh or Dubai, and the figures circulating on recruitment blogs are self-reported and unverifiable. What we can do is show you which line items each option has, because that is where the comparison usually goes wrong.

The row that catches people is the last one. An agency that keeps the knowledge has you locked in regardless of what the contract says about ownership, which is why the handover terms matter more than the licence clause. We have set out what to insist on in who owns the source code when you hire a developer, and the short version is that owning the repository is not the same as being able to use it.

When hiring is clearly right

There is steady, continuous change. If someone will be adjusting the system most weeks for the next two years, you are buying a lot of small pieces of work, and small pieces of work are where agency overhead hurts most. A retainer that exists to cover half days is poor value for both sides.

The software is the product. If what you sell is the thing being built, the engineering capability is the business and renting it is a strategic mistake, however convenient it is in year one.

The domain takes months to learn. Some businesses have rules that cannot be written down quickly, usually because they are not written down anywhere at all. Paying an outsider to learn them repeatedly is worse than paying an insider to hold them.

When hiring is the expensive mistake

You have one project. A single defined build, then occasional maintenance, does not justify a salary. You will either keep paying for idle time or invent work to fill it, and invented work becomes system you have to maintain. The ongoing cost of that is the part people underestimate, and we have gone through it in what maintenance actually costs after launch.

You cannot evaluate the work. If nobody in your company can tell good code from bad, hiring one developer means you have no way to know whether it is going well until something breaks. An agency does not solve that either, but it at least gives you a contract, a scope and more than one person who has seen the code. The questions that help are in how to choose a software development company.

You need several skills at once. A first build often wants backend, frontend, some infrastructure and a little design. One person who claims all four is either unusual or optimistic, and hiring four people for a three month build is not an option.

You need to start now. Hiring takes two to four months before anyone writes a line. If the deadline is sooner than that, the decision is already made, and the question becomes how to avoid locking yourself in while you move fast.

The arrangement that usually works

The common sensible answer is sequential rather than either or. An agency builds the first version, because speed and breadth matter most at the start and the work is defined. You hire once there is something to maintain and a clear, continuous stream of change, which is usually six to twelve months in. The agency's job in the last month is handover, and it should be in the contract from the beginning rather than negotiated at the end.

This has an obvious failure mode. The handover never happens, because there is always one more feature. Give it a date and a definition of done: a new developer can set the project up from the repository alone, run it, and ship a small change without asking the vendor anything.

The same decision gets made on the sales side of a business and the arithmetic rhymes, so if you have been through it there, you already know the shape of the argument. BDG Labs compared what the money actually buys with an outsourced SDR against an in-house one, and the conclusion generalises: outsourcing buys speed and a floor on risk, hiring buys compounding knowledge and a ceiling on it.

The honest limits

This note cannot tell you which is cheaper for you, because the deciding variable is how much change your system will need per month after launch, and almost nobody knows that in advance. Our rough test: if you cannot name six months of work you would give a developer on day one, you are not ready to hire one.

We have also skipped the option that is sometimes the right one, which is not building custom software at all. That is a separate question with its own order of operations, set out in custom software versus off the shelf, and it is worth settling before this one.