Hiring a Developer as a Non-Technical Founder: 7 Steps

Hiring a developer as a non-technical founder works when you keep the decisions that are yours and borrow technical judgment for the rest. You own the problem, the priorities, the budget and every account. The tech stack, the estimate and the code quality get checked by an independent developer, once before you sign and again during the build.

I'm a freelance developer myself, so I have a stake in who you hire. I'll also be clear about when someone like me is the wrong choice.

The short answer: what you decide and what you borrow

The rule of thumb: anything about your business, you decide. Anything that requires reading code, you have someone else assess. The full process from first idea to signed contract is in my guide to hiring a developer. This post covers what changes when you can't read the code yourself.

Your job is product owner, not CTO

Non-technical founders tend to fall into one of two traps. Some hand everything over with a "you're the expert". Others try to steer technical details they can't judge, like a framework a friend swore by. In the first case you discover the problems after they're built in. In the second you pay for a decision nobody can defend.

The role that works is product owner. You decide what gets built, in what order and when it's good enough. The developer decides how, but has to explain the consequences in time, money and risk. Four decisions stay with you:

1. The problem and the users: who will use this, and what should get easier for them?
2. The priorities: what goes into the first version, and what can wait?
3. The budget: how much will you spend before you stop and reassess?
4. The sign-off: does what was delivered actually solve the problem?

None of these require code, but they do require time. My rule of thumb is a few hours a week, more in the first weeks. If nobody on your side has that time, the project will struggle no matter who you hire.

Your best tool: an independent second opinion

The biggest disadvantage of not being technical is that you can't tell a realistic estimate from a hopeful one, or clean code from code that will be expensive to build on. The fix is to buy judgment from someone with nothing to gain from the answer. Next to the cost of the build, it's rarely a big line item.

Who to ask

• A developer in your network: free or cheap, and fine for a quick sanity check of a quote. The review is rarely thorough, though, and they may know the candidate.
• A freelance developer you pay for a few hours: independent and able to read both estimates and code. Agree up front that they won't bid on the work, so the review isn't colored by wanting the job.
• A fractional CTO, meaning a part-time technical lead: worth it when you need ongoing technical leadership, for example with several developers. More expensive, but it covers strategy and hiring too.
• A formal code review: a thorough look at an existing codebase with a written report, typically before launch or when taking over a project. I've listed the situations where an external code review pays off.

When it pays off most

1. Before you sign. Is the estimate realistic? Is the stack common enough that another developer could take over? What's missing from the proposal?
2. At the first milestone. After a few weeks of development, another developer can check whether the code is in your repository, whether there are automated tests and whether the structure is easy to follow.
3. Before launch. Security, backups, monitoring and a plan for updates once you're live.

If you only have budget for one review, the first milestone is usually the best moment. There's real code to look at, and changing course is still cheap.

What to send and what to ask

Send the brief and the proposal, and later read access to the repository and the staging site. If the proposal is marked confidential, check with the developer before forwarding it. Then ask specific questions:

• Is the estimate realistic for what's described, and what isn't included?
• Is the stack common enough that someone else could take over?
• What are the three biggest risks, and how would you test them first?
• If you had to take over this project tomorrow, what would worry you?

Ask for the answer in writing: one page, prioritized, in plain English. You need to know what's serious, what's a matter of taste and what to do now.

When the two developers disagree

It happens, and it isn't a vote. Disagreements about taste, like which framework someone prefers, matter little as long as the choice is mainstream. Disagreements about security, data ownership or whether someone else can take over the code matter a lot. Ask both to explain the disagreement in consequences: what does it cost, how long does it take and what's the risk if we don't do it? If your developer gets defensive about a fair review, that's useful information too.

The seven steps, adjusted for founders who don't code

Each step is adapted to the fact that you can't review the code yourself.

1. Describe the business, not the technology

Write a short brief in your own words: who the users are, what they do today, what frustrates them and what they need to be able to do in version one. Leave the technology out unless there's a real business reason, like an existing system the product has to fit into. When developers propose the stack themselves, you get to compare how they think.

Describe situations rather than feature lists. "A customer calls to move their booking, and today we look it up in a spreadsheet and email them by hand" tells a developer far more than "booking module with edit functionality". My project brief template needs no jargon at all.

2. Set up the accounts before anyone writes code

Owning your accounts from the start is much easier than getting them handed over later. Create these in your company's name, and invite the developer as a user when the work begins:

• A shared email address for technical accounts on your own domain, such as tech@. Not your personal inbox, and not the developer's.
• An organization on GitHub or GitLab for the code. GitHub organizations are free to create, and you decide who can access what.
• A hosting account paid with the company card.
• The domain, registered to your company.
• A password manager with sharing, such as 1Password or Bitwarden, with a shared vault for the project's logins.

If you can't set this up yourself, ask the developer to help, but inside your accounts and ideally with you at the keyboard. When the engagement ends, you remove one user instead of asking for your own product back.

3. Test whether they can explain their choices

You can't judge a developer's code, but you can judge whether they can explain themselves. For you that skill matters most, because you'll base decisions on those explanations for months. On the first call, ask every candidate for three things:

1. Walk me through how you'd build the first version, in language I can follow.
2. Tell me one thing you'd advise me not to build, and why.
3. What's the biggest risk in my project?

Listen for answers about your business, for trade-offs framed as time, money and risk, and for questions coming back at you. Jargon that never gets translated, or "that's technical, you don't need to worry about it", is a warning sign. Ask for a short written summary after the call too. Half a page shows how they'll communicate for the rest of the project. You can also check past work without reading code, as I explain in how to evaluate a developer when you're not technical.

4. Get the proposal reviewed before you sign

Send the brief and the proposal to an independent developer, as described above. It usually takes only a few hours, and it catches unrealistic estimates and missing items before you're committed.

5. Start small, and pay for it

For larger projects I start with a paid, fixed-price discovery phase. It clarifies the scope and the biggest risks, and you come out of it with a plan and an estimate. The output is also a document you can have reviewed before real money goes into the build. Make sure it's yours, even if someone else ends up building the product. Other ways to test a working relationship are covered in my post on paid trial projects.

6. Put acceptance criteria in the contract

Acceptance criteria are short descriptions of when something counts as done, written so you can test them yourself. For example: "When a customer pays, they get an email receipt within a minute." They give you a way to say "not done yet" without arguing about technical details.

Put them in the contract next to the basics: the intellectual property in the code transfers to you, the accounts are in your name and there's a handover plan if you part ways. If the developer will access personal data and GDPR applies to you, Article 28 requires a contract between you as controller and the developer as processor, usually called a DPA. This isn't legal advice. My freelance developer contract checklist covers the 14 clauses to include.

7. Track progress without reading code

Anyone can write a status email. Working software is something you can test. Build your oversight around what you can see and click:

• A staging site: a copy of the product where you try new things before your customers see them.
• A demo every week or two, where you do the clicking instead of watching the developer do it.
• One shared task board, in Trello, Linear, Notion or GitHub Projects, where every task carries its acceptance criteria.
• A three-line weekly update: what's done, what's next and what's waiting on you.

If your developer is in a different time zone, fix one weekly call in your shared hours and keep everything else in writing. If you haven't seen anything working for a month, ask why.

The jargon you'll hear, translated

You don't need the jargon to hire well, but it helps to know why these words matter.

If you hear a word that isn't on the list, ask. Explaining it is part of the job.

When a freelancer is the wrong hire

A freelance developer (a contractor, in UK terms) is a good fit for a well-defined project or for ongoing development of a product that's already running. For a non-technical founder, it isn't always the right call:

• When the software is your entire business and technical decisions need making every week for years. Then you need a technical co-founder or a CTO, full-time or fractional.
• When several developers need to work together. Someone has to lead them, and that's a different job from writing the code.
• When off-the-shelf software or a no-code tool can test the idea first. If you haven't shown that anyone will use or pay for the product, start there.
• When nobody on your side has time to be product owner. An agency with a project manager can carry some of the load, but the decisions are still yours.

I mainly work with Laravel, PHP and modern JavaScript such as React and Next.js. If your project needs something entirely different, a specialist in that stack is the better hire.

Next steps: are you ready to hire?

If your product is already live and you need a developer who keeps it up to date, builds on it and explains what's going on, see how I handle maintenance and ongoing development. You talk directly to the person who writes the code, and you get a reply within one business day.

Frequently asked questions

Can I use ChatGPT to review a developer's proposal?+

You can use an AI assistant to understand terms and prepare questions, but not to decide whether a proposal is good. It knows nothing about your project beyond the text you paste in, and it can sound confident while being wrong. Use it to get ready for the call with the developer or for an independent review. Don't paste in a confidential proposal without permission.

How much does an independent review of a proposal cost?+

Usually a few hours of a senior developer's time at their normal rate, if all they review is the brief and the proposal. Reviewing an existing codebase takes longer and depends on its size. Ask for a fixed price or a cap on hours up front, and agree on what you get back, such as a single prioritized page of findings and recommendations.

How do I know if my developer is billing too many hours?+

Ask for time tracked per task so you can compare it against the estimate. Overruns happen in every project, but you should hear about them before they happen, not on the invoice. A monthly cap on hours gives you a natural point to pause and review. If the doubt persists, have another developer look at a few of the biggest tasks and judge whether the time spent was reasonable.

Can I hire a developer in another country if I'm not technical?+

Yes, but distance adds coordination you'll have to handle yourself. Check overlapping working hours, the working language and which country's law governs the contract. Within the EU, GDPR gives everyone the same baseline for personal data. A developer on Central European Time shares nearly the whole working day with UK and EU offices, but only a couple of hours with the US East Coast.