How to choose between building yourself, freelancers, an agency, volunteers or a technical co-founder.

Once you know what to build, the next question is who builds it. There is no single right answer, but there is a wrong one: handing the whole product to outsiders with nobody on the founding team able to judge, maintain or direct the result.

Why it matters

Your build route decides how fast you can change direction, how much you spend before revenue, who owns the code and how hard it will be to hire later. Changing route mid-build is expensive, so it is worth choosing deliberately.

The options compared

Step by step

1. Be honest about your own skills. Can you read code, review a pull request, judge an estimate? If not, your first priority is a technical co-founder, a technical adviser or a fractional CTO who can own decisions.
2. Size the first build. Use your MVP scope to estimate weeks of effort. Small, contained builds suit doing it yourself or freelancers; ongoing, core products need someone in it for the long term.
3. Set your budget and runway. Work out how much you can spend before revenue. The hiring and team cost planner and runway calculator help compare routes.
4. Mix routes where it helps. A common pattern is a technical founder or lead owning architecture, with freelancers or volunteers adding capacity, and specialists brought in for design or security.
5. Protect ownership from day one. Make sure the company owns the code repository, cloud accounts, domain and app store accounts, not a contractor. Get written IP assignment from everyone who contributes code or designs, including co-founders. Agree founder equity and roles in writing.
6. Run a short trial. Before committing to an agency or freelancer for months, start with a two-week paid piece of work and judge the quality, communication and code.

Briefing outside help

A good brief states the problem and user, the one job the MVP must do, what is out of scope, the preferred technology or existing systems, how you will release and test, who owns the code and accounts, and how progress will be shown each week. Ask for code to be committed to your repository daily, not delivered at the end.

Worked example

Hamid, a non-technical tech founder in Sheffield, had two paid pilots for a stock-forecasting tool for independent bike shops. An agency quoted four months for the full specification. Instead, he recruited a technical adviser for a few hours a week, cut the scope to one forecasting report, and built the first version with two freelancers, with the adviser reviewing every pull request. The code lived in the company’s own repository from the first day. Version one shipped in seven weeks. Six months later, with revenue coming in, the adviser joined as technical co-founder.

Common mistakes

• Outsourcing everything with nobody technical on the founding team to own it.
• Letting a contractor hold the accounts, so you cannot deploy or change suppliers without them.
• Choosing on price alone. Cheap builds that need rewriting are expensive.
• Fixed-price contracts on a vague specification, which lock in the wrong product.
• Giving away large equity stakes to a developer for a few months of effort without vesting.

What to measure

• Cost and weeks to first release against estimate.
• Share of accounts, repositories and IP owned by the company.
• How often code is delivered and reviewed.
• Time for a new contributor to make their first change.