How to hire a developer for a startup: a non-technical founder’s playbook
A practical, opinionated guide for non-technical founders. Covers when not to hire, how to brief, how to interview without faking technical depth, what to pay, and how to avoid the four most common ways the relationship breaks.
The short version, for founders who landed here in a hurry: before you hire a developer for your startup, write a one-page brief, decide whether you actually need a hire or a delivery partner, and run a paid trial week. Three of those four steps cost no money and most founders skip all three. That’s why most of these hires go badly.
The longer version is below. We’ve been on the other side of this conversation with dozens of non-technical founders over the last few years, and the patterns are consistent enough that it’s worth writing them down.
Decide first: hire, contract, or partner
Most founders frame the question as who do I hire? The better question is what kind of relationship do I actually need? Three options exist, and they don’t substitute for each other.
The first option is a full-time hire — usually a senior engineer or a tech lead, sometimes a CTO. This makes sense when you have steady, predictable engineering workload, the budget to support a salary plus equity for at least eighteen months, and the bandwidth to manage someone whose work you can’t directly evaluate.
The second option is a contractor — freelance or fractional. This makes sense for narrow, time-boxed work — a Stripe integration, a data migration, a specific feature — where the spec is clear and the relationship can end clean. It’s a poor fit for “build my startup” work, because contractors optimize for finishing, and the founder needs someone who optimizes for being correct about what gets built.
The third option is a delivery partner — a small senior team that scopes, builds, and ships under one accountability. This makes sense for non-technical founders who don’t have a clear technical co-founder, who want to ship a real product within four to nine months, and who don’t yet have enough sustained engineering work to keep an in-house team productive. The model trades a higher per-month cost for a much lower per-feature cost and removes the management overhead of a hire.
There’s a fourth option founders sometimes try, which is the “very junior developer working hard.” We mention it only to discourage it. A junior developer needs senior review to grow. A non-technical founder can’t provide that review. The result is technical debt that compounds invisibly, and the founder finds out twelve months in.
If you’re not sure which option fits, the test is: if a senior engineer joined tomorrow, what would I assign them in their first month? If you can answer in one paragraph, you need a hire or a contractor. If you can’t, you need a partner — because what you’re missing isn’t a pair of hands. It’s clarity about what to build.
How much should you pay
The price ranges below are 2026 numbers for North American and Brazilian markets. They will drift; the relative shapes will not.
For a senior full-time software engineer in the US (mid-career, four to eight years of experience, full-stack, can ship without supervision), expect US$ 160,000–220,000 base plus equity. For a senior in Brazil with comparable experience, expect R$ 18,000–35,000 per month CLT, or roughly R$ 25,000–45,000 monthly as PJ. A first CTO hire — the rare seed-stage one — usually adds 10–25% on cash and 10–25% in equity over a senior engineer.
For freelance contractors, hourly rates range from US$ 60–180 in the US and R$ 150–400 in Brazil for senior people. Below those bands, you’re either paying for junior talent or paying for someone who’s senior but not on the engagements you’d want them on. Outside-Brazil offshore developers ranged widely; the engineers worth working with at US$ 25–40/hour exist but are hard to find without a strong referral network, and the failure rate of cold marketplace hires at that price point is high.
For a delivery partner, a typical first-version build runs US$ 80,000–250,000 over four to nine months, depending on scope. A team of two to four senior engineers plus design support is the usual shape. The economic comparison founders should run is not “partner cost vs. developer salary” — it’s “what does it cost me to ship the same product, with the same quality, by the same date, with the team I can actually hire?” When you run the math honestly, the partner is often the cheaper option for the first eighteen months.
Write the brief before you write the job post
The single biggest reason these hires fail is that the founder hires before they’ve decided what they’re hiring for. A brief is the cheapest insurance policy you’ll buy this year. Spend a weekend on it.
A useful brief, on one page, contains:
The customer in one sentence — who they are, what they’re currently doing instead, why they’d switch. The product in one paragraph — what it does, in language a non-technical reader could repeat. The minimum scope for a first ship — three to five capabilities, no more, ranked by which one would prove the thesis fastest. The integrations and constraints — what other systems it has to talk to, what regulations apply (LGPD, HIPAA, SOC 2), what platforms (web, iOS, Android). The success metric — one metric, with a threshold, by a date. The non-goals — three things you are deliberately not building yet, so you don’t have to defend the choice in every sprint.
If you can’t fill in any one of those fields, the gap isn’t an engineering gap. It’s a product or commercial gap. Hiring a developer to fill a product gap is the most expensive way to discover that fact.
How to interview a developer when you can’t read the code
The technical interview problem for non-technical founders is real, and most published advice is unhelpful. You can’t run a coding screen. You can’t evaluate a system design. The candidate could fake their way through both, and you wouldn’t know.
What you can do is run three checks that don’t require technical depth, and they’re surprisingly diagnostic together.
The brief reading. Send the candidate your one-page brief in advance. In the first interview, ask them to walk you through how they’d approach the first ninety days. The signal you’re looking for is not “they have the right answer.” There usually isn’t a right answer at this stage. The signal is: do they ask sharper questions about the brief than you’ve heard before? A senior engineer reading a brief for the first time should surface assumptions you didn’t know you were making. A junior or generic developer will skip the assumptions and tell you what to build. The asking is the skill.
The reference check that isn’t pro forma. Pick two of their referrals — ideally a former manager and a former peer — and have a real twenty-minute conversation, not a five-minute checklist. The single best question to ask: if you were starting a company tomorrow and could hire one engineer from the team, would they be on the shortlist? Watch the pause before the answer. The pause matters more than the answer.
The paid trial week. This is the highest-signal step in the entire process and the one most founders refuse to run, because it feels like a strange power move. Pay the candidate their pro-rata weekly rate to do one piece of real work — a small, contained task from the actual brief, ideally one with a slight ambiguity built in. At the end of the week, you have either delivered work, a thoughtful question about the ambiguity, or a missed deadline. Any of those three answers is more useful than another two-hour interview.
If you can’t run a trial — because the candidate is currently employed full-time elsewhere — the substitute is to ask them to walk you through the most recent piece of code they wrote that they’re proud of, screen-share, in plain language, for a non-technical audience. The senior ones will love this. The junior ones will struggle. That’s the screen.
The four ways the relationship breaks
We’ve watched a lot of these relationships die. The failure modes cluster.
Scope drift. The founder’s understanding of the product changes weekly. The engineer keeps building what the founder asked for last sprint. By month three, they’re shipping the wrong thing, or arguing about whether they’re shipping the wrong thing. The fix is to write down a specific frozen scope for each two-week iteration and insist that changes wait for the next iteration. Founders who can’t hold that line are signaling they need a delivery partner with a product manager in the loop, not a developer alone.
Communication mismatch. The engineer talks in implementation. The founder hears the implementation as commitment and is surprised when reality bends. The fix is a weekly written status note — what shipped, what’s blocked, what changed in the plan — with explicit risks. If the engineer can’t write it, that’s a signal. If the founder can’t read it, that’s a different signal.
Technical debt invisibility. The engineer ships fast, the founder is happy, the codebase quietly rots. Eighteen months in, every change takes three times as long as it used to, and nobody can explain why. The only prophylactic is hiring someone who actually cares about this and who can occasionally veto a quick win in favor of the durable choice — and trusting them when they do. If you can’t trust them on that question, the relationship is fundamentally broken.
The bus problem. You have one developer. They quit, get sick, or take a long vacation. The codebase is undocumented; the deployment process lives in their head; the third-party API keys are in a .env file on their laptop. The damage from the bus problem is asymmetric and severe. The fix is to insist, from week one, that the codebase has a README that a stranger could follow, a deployment runbook, and a credentials vault that isn’t on one machine. If your developer pushes back on these three, that is by itself a hire-failure signal.
A short list of red flags worth taking seriously
A candidate who answers your brief by promising the full scope in less than half the time you expected. A candidate who has never built or maintained the kind of system you’re asking them to build. A candidate who refuses a paid trial because “they don’t do tests.” A candidate whose references all worked with them more than three years ago. A candidate whose portfolio is impressive but whose role on each project is vague when you press. A candidate who wants to start with a long architecture document instead of a small shippable slice.
None of these are automatic disqualifications. All of them are worth at least one direct, uncomfortable question before you proceed.
What the hire should look like by month three
If the relationship is working, the first three months produce four things, in roughly this order. Week two: a written architecture sketch you can read in fifteen minutes. Week four: the first piece of real, in-production functionality, even if narrow. Week six: a working deployment process the founder has personally watched run end-to-end. Week ten: a small piece of feedback from a real customer that changed something in the next sprint.
If three of those four haven’t happened by week twelve, the diagnosis is rarely “the engineer is bad.” It’s usually that the founder hired before the brief was clear, hired the wrong shape (a contractor where they needed a partner, a senior where they needed a CTO, a junior anywhere), or hasn’t installed the rhythms — written briefs, frozen scopes, weekly status — that turn raw talent into shipped product.
The good news is that diagnosis points at fixable things. The bad news is that none of them get fixed by hiring more people.
The simplest version of the rule
Hire the developer when you know what you’d assign them. Until then, write the brief, talk to ten more customers, and pay a senior partner to scope the first version. The founders we’ve watched do this in that order, in that sequence, almost never end up regretting the hire they eventually make. The ones who skip the brief and rush to the hire almost always do.