In-house vs Outsource Advisor

Founders ask it as one decision about the whole roadmap, and it is not. Some of that roadmap is your product differentiation and should never leave the building. Some is a Stripe integration that four hundred people have done before and there is no advantage in doing it yourself. Answering both the same way is how this goes wrong in either direction.

The useful version is to split the work and answer per piece. That is uncomfortable because it takes longer, and it is why most of the advice online is a generic pros and cons table that helps nobody decide anything.

The second thing people underweight is time. A UK engineering hire is typically eight to twelve weeks from posting the role to someone starting, plus notice, which is often another one to three months. If your deadline is in ten weeks, hiring is not on the list of options, whatever its merits.

Almost every expensive outsourcing story starts the same way: someone got quotes against a brief that was two paragraphs long, picked the cheapest, and discovered over the following months that everything they had not written down was a change request at the worst possible rate.

So write the roadmap first. The features, the user journeys, what is in the first release and, more importantly, what is explicitly not. It does not need to be a specification document. It needs to be specific enough that two agencies quoting on it would quote for the same thing, which is a test most briefs fail.

Then get the designs done, and do not let design and development run in parallel. Building against screens that do not exist yet produces rework, and rework is the most expensive category of work there is. Either pay a UI designer to produce the screens first, or do it yourself: AI design tools like Claude Design or ChatGPT will take you from concepts to wireframes to high-fidelity screens you are happy with, and that is a perfectly respectable way to arrive at a developer with something to build.

Those two steps cost you a couple of weeks and they routinely save a third of the build.

This is the single biggest saving available to an early-stage founder and most still do not take it. If you have an idea and no product, build the MVP yourself using AI tools, put it in front of real users, and only then pay a developer to turn it into something that can be depended on.

You get two things out of that. You spend a fraction of the money finding out whether anyone wants it, which is the question that actually matters at that stage. And when you do hire someone, they are productionising something with users and evidence behind it rather than guessing at a specification with you.

Be honest with yourself about what you have made, though. An AI-built MVP is a validation artefact, not a product. It will not have real authentication, a data model that survives contact with growth, tests, a deployment process, monitoring, or any security work. Productionising it is real engineering and it takes three to four weeks minimum for anything non-trivial, even with AI helping. Budget for that rather than being surprised by it.

Use £5,000 to £15,000 per developer per month as your planning range. UK and Western European developers sit at the top of it, other regions lower, and you get what you pay for more often than the cheap end admits. A single good developer for three months is therefore £15,000 to £45,000, and that is before design, testing, infrastructure or anything else.

The timing anchor matters as much as the money. Even with AI assistance, taking something from prototype to production takes three to four weeks at an absolute minimum. Any plan that assumes a fortnight is wrong, and any supplier who agrees to a fortnight is either not going to do it or not going to do it properly.

Then there is the part almost nobody budgets: the monthly bill after launch. Hosting, database, third-party services, monitoring, model API costs if there is AI in the product, domains and certificates, and some form of ongoing maintenance. It is rarely enormous, and it is permanent, and founders are consistently surprised by it because every quote they received was for the build.

Whoever builds this will handle your users’ data, and you have to ask for that to be done properly because a good half of suppliers will not volunteer it. Secure storage and transport, sensible access control, security testing before you launch, and specifically testing that one customer cannot see another customer’s data. That last one is the failure that ends companies, and it is entirely testable.

UK GDPR applies from your first user, not from your first enterprise deal. You need a lawful basis for what you collect, an answer to a subject access request, a way to delete someone properly, a retention policy, and a plan for what happens in a breach. Retrofitting deletion into a schema that was never designed for it is genuinely hard, which is why it belongs in the original brief.

If you sell to businesses, your buyers will eventually ask for ISO 27001 or SOC 2. Both take months of preparation and cost real money in audit fees, tooling and internal time. Neither is something you start when a procurement team asks. Put them in the budget and the timeline early, because the alternative is a deal stalling while you scramble.

When a budget is tight, testing and infrastructure are always what gets dropped, and they are always what costs more later. Neither has to be expensive; both have to be somebody’s job.

On testing: if you cannot afford a tester, you do it. That is a legitimate choice and it is what most early founders do, but be clear-eyed about it. It means writing down the journeys that must work, going through all of them before every release, and doing it properly rather than clicking the happy path. Budget a few hours per release for that and put it in your own diary.

If you can afford a tester, they are cheaper than developer time spent finding the same bugs, and much cheaper than a customer finding them. Even a part-time one changes the quality of what ships.

On DevOps: environments, deployment, backups with a restore you have actually tested, monitoring and alerting, and secrets kept somewhere other than a chat thread. None of it produces a demo. All of it is the difference between a product and a prototype, and if nobody is named as responsible it will not happen.

In-house wins on anything permanent, anything core, and anything that needs context. An employee accumulates knowledge about your product, your customers and your decisions, and that compounds. The costs are that it is slow to start, expensive to get wrong, and you carry it whether or not there is work.

Freelancers win on bounded specialist work. A one-off data migration, a mobile build you will not repeat, a security review. You get a specific skill for a specific time and you stop paying when it ends. They do not accumulate context, and they are the wrong answer for anything you need ongoing.

Agencies win on speed and on capacity. A team can usually start in two to four weeks with the management layer included, which matters when you have no technical lead. The cost is real money per month, and the real risk is not the money, it is knowledge leaving when the engagement ends.

And sometimes the answer is that you should not build it yet. A roadmap item nobody has validated does not become a better idea by being outsourced faster.

The outsourcing risk that actually bites is not cost or quality. It is that when the engagement ends, the understanding of how your product works leaves with it, and your own team inherits a codebase they did not write and cannot confidently change. This is extremely common and it is always discovered months later, when someone needs to make a small change and cannot.

The second is the incentive gap. An agency paid by the day is not paid to tell you a feature is unnecessary. A good one does anyway; plenty do not, and you will not find out from the weekly update.

In-house has its own risks, and founders underweight them because hiring feels safe. A first engineering hire made badly sets the technical direction and the hiring bar for everyone after them. A single developer with no oversight is a single point of failure that gets more expensive every month. And you carry the salary whether or not there is a roadmap.

Freelancers carry availability risk. The good ones are booked, they leave when a better contract appears, and there is no bench behind them if they are ill.

Most of the risk is contractual and procedural, and most of it is avoidable if you decide these things before you sign rather than after.

Own the repository, the cloud accounts, the domains and the credentials from day one, in your company name. This sounds obvious and is the single most common thing founders get wrong, and it is the one that turns a disagreement into a hostage situation.

Insist on seeing working software weekly, in an environment you can click. Not a status document. If the first demo is in week six, you have already lost the ability to correct course cheaply.

Write the handover into the contract at the start: documentation, a runbook, and a period where your own people work alongside theirs. Nobody negotiates a good handover at the end of an engagement they are leaving.

And have somebody technical on your side reviewing the work, even a few hours a month. Without that you are buying something you cannot evaluate, which is the position that makes every other risk worse.

Metamindz is an agency. We are publishing a tool that advises people on whether to use an agency. That is a conflict of interest and you should read the output knowing it.

The tool is built to say in-house or freelance where that is the better answer, and it often is, because advice that always pointed at us would be worth nothing and you would work that out within one use. The prompt behind it says so explicitly.

Check it against that. If the output recommends an agency for your core product indefinitely, it is wrong and you should disregard it. Where we genuinely are the right answer, it is for a bounded piece of work with a handover date, and that is how we run engagements.