Founding engineer: what a non-technical founder needs to know before making the hire

A founder I’d been talking to for months called on a Tuesday afternoon. She’d just signed an offer with the engineer she’d been trying to hire since her seed round closed. Equity: 4%. Salary: $185K. Title: Founding Engineer. She wanted me to look at the offer letter before she sent it.

I read it twice. Then I called her back.

“You realize you’ve just hired your CTO,” I said.

“No, no. It’s a founding engineer. He’s going to build the product. I’m going to hire the CTO later.”

“Sure,” I said. “But the person you just gave 4% to is going to own every line of code in your company for the next eighteen months. He’ll set the stack. He’ll pick the database. He’ll decide what gets refactored and what gets papered over. If you bring in a CTO above him in nine months, what do you think happens?”

There was a pause. Then: “Oh.”

She didn’t send the offer. We spent the next two hours rewriting the role, the equity, and the conversation she was about to have. The engineer ended up joining. The title stayed. The structure under the title got fixed before it hardened into a problem.

That call is why this article exists.

What is a founding engineer?

A founding engineer is the first engineer a startup hires, brought on as an equity-bearing employee rather than as a contractor or fractional hire, to own the technical build of the product before there is a CTO or an engineering team.

That’s the textbook answer. It captures roughly half of what you’re actually buying.

The other half is the part recruiter blogs leave out. A founding engineer is the only person on your payroll who will know the whole codebase. They will be alone in the build for the first 12 to 24 months. They will absorb every product ambiguity you hand them, translate it into systems, and live with the consequences when you change your mind. They will set the technical defaults that the next ten engineers will inherit. And because they joined when the company was risky, they will hold a stake in the cap table that, if the company works, makes them rich in a way that future engineers won’t be.

That’s the hire. Not a developer. Not a contractor. Not even a senior IC at a bigger company. A founder-tier hire with a smaller equity slice and a narrower job description, but the same level of structural weight.

If you don’t know that, you’ll get the offer wrong, the title wrong, the equity wrong, and the relationship wrong. So before you write the job description, get clear on what you’re actually doing.

Founding engineer vs CTO: which one are you actually hiring?

This is where most non-technical founders get tripped up, and it’s the easiest mistake to fix if you catch it early.

A CTO is an executive. They set technical direction, manage other engineers, attend board meetings, run the architecture conversation with the rest of the leadership team, and own the company’s technical reputation in the market. The trade-off they bring is leadership for IC velocity. Most early CTOs spend less than half their week writing code.

A founding engineer is an individual contributor. They build. They take a half-formed product idea and ship something a paying customer can use. They are the technical pulse of the company, but they don’t run a team because there is no team yet.

The CTO question and the founding engineer question are not the same hire. The way you tell them apart is to ask, honestly: do I need someone in the boardroom right now, or do I need someone shipping code?

If the answer is “in the boardroom,” you’re looking for a CTO. The market for that hire is thin, slow, and expensive. Most early-stage non-technical founders can’t actually hire a real CTO at this stage, and trying for one usually produces a candidate who is overqualified for the IC work and underqualified for the exec role.

If the answer is “shipping code,” you want a founding engineer. The market is deeper, the salary is lower, and the person who says yes is someone whose comp will be heavily equity-weighted because the appeal of the role is ownership over the technical canvas.

A common pattern that goes badly: hire a founding engineer at founding-engineer comp, give them a CTO-shaped scope (“you’ll set the technical direction, run the engineering org, and own the architecture forever”), and then bring in a real CTO above them in a year. The founding engineer either becomes a quiet senior IC who feels demoted, or they leave with their equity and their context. We’ve seen this play out three times in the last eighteen months. Twice the founding engineer left.

Match the title to the comp, the comp to the scope, and the scope to where you actually are in the build.

Founding engineer vs co-founder: the line that matters

There’s a third line that gets blurred, and it matters more than the title page implies.

A co-founder owns the company. They sign the docs. They take on the legal and financial liability. They share the founder’s risk profile: no salary or low salary in the early days, vesting over four years from day one of the company’s existence, with rights and protections that show up in the cap table from the moment of incorporation.

A founding engineer is an employee. They join after the company exists. Their equity grant is structured as an option pool grant, vested from their start date, with a strike price set by a 409A valuation that already reflects some company value. They get a real salary from day one. They can quit without it being a founder-level event.

Founders sometimes try to split the difference. “He’s basically a co-founder, but joining late.” Three months in, the engineer is still on a standard employee grant, and the founder is wondering why he’s not as bought in as they expected.

If you want the relationship of a co-founder, structure it as a co-founder relationship. That means founder-level equity (closer to 10-25% rather than 1-5%), founder-level vesting, founder-level voice in the company. It also means giving up a meaningful share of your cap table.

If you can’t do that, what you actually want is a founding engineer. Be honest about it. Pay them well, give them ownership over the technical canvas, and don’t promise them what you can’t deliver.

The honest version of this conversation, had upfront, is the difference between a hire that lasts five years and a hire that turns into a cap-table dispute.

How much equity should a founding engineer get?

The market range, as of when this is being written, is broadly 0.5% to 2% for a founding engineer hired in the year after a seed round, vesting over four years with a one-year cliff. Inside that range, the actual number moves with a few specific levers.

Levers that push the equity up:

• The candidate has done it before. They’ve been a founding engineer at a startup that shipped, even if the company didn’t exit. Pattern matching matters.
• The candidate is taking a meaningful pay cut versus their last comp.
• The candidate is joining before the seed close, when the risk is materially higher.
• The candidate has a specific technical specialization the product needs and that you cannot get elsewhere.

Levers that push the equity down:

• The company already has a real product in market, real revenue, and real validation. The risk discount goes away.
• The salary is at or near market, so equity isn’t compensating for a comp cut.
• The candidate is joining post-Series A with a 409A that’s already moved.

Two things to avoid.

First, don’t give equity to win the candidate. We’ve seen non-technical founders raise the equity offer 50% in the closing call to get a yes. The candidate said yes; the founder paid for it in the next round when the cap table looked unbalanced and the investor diligence flagged it. If the candidate is the wrong fit at 1%, they’re the wrong fit at 1.5%. Either find a different lever (start date, salary, scope, title) or find a different candidate.

Second, don’t give equity without vesting. Single-trigger acceleration on a founding engineer’s grant is a footgun. So is anything with less than a four-year vest. The cliff matters more than the percentage. A two-year cliff on a 1% grant gives the founder a year of optionality. A no-cliff grant gives the engineer leverage on day 90.

When in doubt, look at Carta’s annual State of Equity report and benchmark against companies at your stage and your geography. The numbers move every year, and the public benchmarks are more accurate than what you’ll hear from your own network.

The three traps non-technical founders fall into when hiring a founding engineer

We’ve watched these in real time, in clients we still work with, and in founders who decided to do it on their own.

Trap one: hiring someone who is great at the technology and bad at the ambiguity.

A senior engineer from a 400-person company is often a worse founding engineer than a mid-level engineer from a 12-person company. The skill the founding engineer needs isn’t depth in a single technology stack. It’s a tolerance for vague requirements, the judgment to make a 70%-right call quickly and ship it, and the temperament to do their own product thinking when the founder is still figuring out what to build. Engineers who came up in well-specced environments often freeze when handed a half-formed idea and asked to make it real. The founder reads the freeze as “needs more direction” and starts writing tickets, which is the opposite of why they hired the engineer.

Screen for ambiguity tolerance the same way you’d screen for technical skill. Ask: tell me about a project where the requirements weren’t clear and you had to figure out what to build. If the answer is a polished after-the-fact narrative with no friction in it, they’re describing the work the way they want to remember it. If the answer is “we got the spec wrong twice, then I sat with the customer for two hours and we figured out what actually mattered,” that’s the founding engineer.

Trap two: hiring someone you can’t manage.

A founding engineer joined for autonomy. They want to ship without being told how. But autonomy isn’t the same as no relationship. A non-technical founder still has to be able to ask “is that the right call?” and get a real answer back, in language they can act on. If the engineer can’t explain technical trade-offs in business consequences, the founder is going to nod and approve and watch decisions get made that they can’t evaluate. That’s the start of the black-box problem that this brand has written about for years.

The screen here is a conversation, not a coding test. Spend an hour talking through a real decision the candidate had to make in their last job. Did they explain the trade-off in terms you could follow? Did they push back when you proposed something that didn’t make sense? Did they make you feel respected, or did they make you feel small? If the conversation felt good, the working relationship will probably feel good too.

Trap three: hiring someone who can’t grow into a manager, and discovering it in month nine.

Most founding engineers will eventually have to hire and manage the next two or three engineers. Not all of them want to. Some great founding engineers are deeply IC-oriented and will quietly resent every hour they’re forced to spend in a 1:1. That’s fine. But you have to know it on day one.

Have the conversation explicitly. “In twelve to eighteen months, the team is going to grow. Some founding engineers grow into the engineering manager role. Some stay IC and we hire a manager around them. Which version sounds like you?” If they don’t have a clear answer, they don’t know themselves well enough. That’s a flag.

The seven-day readiness test

Before you write the job description, run this test on yourself. It will tell you whether you’re ready to make this hire, or whether you should wait three months and keep working with an outside team for one more cycle.

Spend the next seven days answering, in writing, the following five questions. If you cannot, you are not ready to hire a founding engineer. The hire will fail not because the engineer is wrong, but because the company under them isn’t ready.

1. What does the product need to do, in plain language, six months from now? Not the vision deck. The shipped product. One page.
2. Who are the first three customers using it, and what are they paying you for? If the answer is “we’ll figure that out after we ship,” the founding engineer is going to figure it out for you. They will make the customer-design decisions whether you want them to or not.
3. What’s the budget for engineering for the next 18 months, including salary, equity, infrastructure, and a buffer for the next hire? If you can’t answer this within 20% accuracy, you’re going to run out of runway around month ten, and the conversation with the engineer about pay cuts or layoffs is going to be the worst one of your year.
4. What does month 12 look like if the hire works? What’s shipped, what’s revenue, what’s the team. If you can’t see it, the engineer can’t see it either, and the equity grant is just a number on paper.
5. What does month 12 look like if it doesn’t? What’s the exit conversation. Who keeps the code. Who owns the customer commitments. The hardest conversation in any founding-engineer hire is the unwind. Founders who can name it upfront usually don’t end up needing to have it. Founders who can’t, often do.

If you can answer all five clearly, hire. If you can’t, the gap is in the company, not in the candidate. Fix the gap first.

When not to hire a founding engineer (and what to do instead)

There are three situations where the right call is to wait.

You haven’t validated the product. Pre-validation, what you need is throughput on experiments, not ownership of a codebase. A capable outside team or a senior contractor will move faster than a founding engineer, because they don’t have to be onboarded into a vision that’s still changing weekly. Hire the founding engineer when you have something worth defending.

You can’t articulate what you want from the role. If you find yourself writing the job description and pasting in language from someone else’s posting, slow down. The cost of getting this hire wrong is high enough that fuzzy specs are an active risk. A fractional CTO for three months can help you write the spec, define the technical bar, and screen candidates. That’s a much cheaper way to discover that you actually don’t need this hire yet.

You’re hiring out of fear, not strategy. There’s a specific emotional pattern that pushes non-technical founders into a founding-engineer hire prematurely: a board member said you should have your own technical team, a peer just hired one, the outside team isn’t perfect and the founder is losing confidence. Fear-driven hires fail at a higher rate than strategy-driven ones. The fix is usually a conversation, not a job posting. Talk to two or three operators who hired their founding engineer at the right time and ask what they’d do differently. The answer is rarely “I should have done it sooner.”

If none of those three situations applies, and you can answer the five questions clearly, write the job description. Use the equity range above. Avoid the three traps. And spend more time on the conversation than on the technical screen, because the conversation is where the hire actually lives or dies.

FAQ

What is the difference between a founding engineer and the first developer hire?
A founding engineer is hired full-time, with equity, to own the technical build of the product. The first developer hire is usually a transactional engagement: a contractor or junior employee brought in to execute a defined scope. The founding engineer signs up for the company; the first developer signs up for a project.

Can a founding engineer become the CTO later?
Sometimes, but not by default. The skills overlap less than the titles suggest. A great founding engineer is a great IC; a great CTO is a great executive. Some people grow into both. Many don’t. If you want the founding engineer to be the CTO eventually, name it explicitly in the offer conversation, and build in real management-skill development between months 9 and 18. Don’t wait for it to happen on its own.

How long does it take to hire a founding engineer?
Plan for two to six months. The good ones are not on the market. They are in conversations through warm intros, referrals, and small networks. Cold inbound applications rarely produce the right hire. Budget the time, work the network, and don’t compress the schedule to compensate for a board commitment.

What’s the right title: founding engineer, founding software engineer, or something else?
For the work, it doesn’t matter. For the candidate, it does. “Founding engineer” carries more equity expectation than “senior engineer” or “lead engineer,” and candidates will price it that way. Pick the title that matches the comp and the scope, and don’t inflate the title to win the candidate without inflating the rest of the package to match.

Should I hire a founding engineer or work with a software partner instead?
It depends on where you are. A software partner moves faster pre-validation, and gives you optionality if the product idea changes. A founding engineer compounds. They get faster every month, and at the 18-month mark they know your business better than any outside team will. Most non-technical founders we work with do both at different stages of the company. The honest framing: a founding engineer is the right hire when you have something you’re sure you want to compound on. Before that, you’re paying a high price for compounding on the wrong base.