Your first engineer has been with you for a year. They ship, they hold the system in their head, and last Friday they asked for a raise. You have no pay bands, no review cycle, and a runway number you check every week. The temptation is to either say yes to whatever number they name, because losing them would hurt, or to stall, because you have no framework and the cash is tight.
Both are mistakes. The short answer: treat the request as the start of a compensation review you should have scheduled anyway, answer within two weeks, and make the answer a mix of cash, equity and scope that you can explain and repeat for the next five engineers. A raise you cannot explain becomes the precedent every later hire negotiates against.
Why this conversation is harder than it looks
At a big company, a raise request lands in a system. There is a band for the level, a budget for the cycle, and a manager who can say "here is where you sit and here is what moves you." At a seed-stage startup there is none of that. There is you, one engineer, and a number.
That creates three specific risks.
The first is precedent. Whatever you give your first engineer becomes the unofficial top of the range. When you hire engineer number three and they ask what the senior people earn, the answer is this number. If it was set in a moment of panic, you have anchored your whole team's pay to a moment of panic.
The second is the mismatch between what they asked for and what they need. Engineers rarely ask for a raise only because of money. Often the request carries something else: they saw a market offer, their role has grown and the pay has not, a life event changed their costs, or they feel their equity is worth less than it did at hiring. If you answer the money question and miss the underlying one, you will have the same conversation in six months.
The third is runway. A 15 percent raise on a single salary sounds small. Multiply it through payroll taxes and benefits, then by the precedent it sets for the next hires, and it can move your runway by weeks. That is not a reason to say no. It is a reason to know the number before you say yes.
What to do in the first week
Do not answer in the room. Thank them, say you take it seriously, and commit to a date, ideally within ten working days. Then do three things.
First, ask the open question: what changed? You are not cross-examining, you are finding out whether this is about market rate, scope, a competing offer, or personal circumstances. Each needs a different answer. A competing offer needs speed. A scope mismatch needs a title or role conversation. A cost-of-living issue may be solved by cash timing rather than a permanent increase.
Second, get a real market number. Pull two or three salary benchmarks for the role, level and location, and compare like for like: scope, not title. A "senior engineer" at a ten-person startup who owns the whole backend is often doing more than a senior engineer at a large company, and less than a staff engineer there. If their current pay sits clearly below the market midpoint for what they actually do, you already know part of your answer.
Third, run the runway math. Model the raise fully loaded, then model it again assuming your next two engineering hires will expect a similar level. If the second number breaks your plan, you need to lean on equity or timing rather than base salary.
The four levers you actually have
Cash is only one of them, and at seed stage it is usually the most expensive.
Base salary. Use it to close a clear market gap. If someone is paid well below what the role is worth today, fix it, even if it hurts. Underpaying your most important technical person is a retention risk you will pay for later, and getting compensation right from the start is cheaper than repairing it.
Equity refresh. Most early engineers' equity was set at hiring, at a valuation and a risk level that no longer exist. A refresh grant re-ups their stake and vests forward, so it rewards staying. This is common practice: Pave cites Carta data showing about 20 percent of employees get a refresh by year one and nearly half by year two, with refreshes typically around 30 percent of a new-hire grant for the same role. For a first engineer who has carried the company, that is a reasonable floor, not a ceiling.
Scope and title. If the request is really "my job got bigger and nobody noticed," name the bigger job. Make them the owner of an area, give them the hiring decision for the next engineer, or put them in the room for roadmap trade-offs. Be careful with titles, though: a title you hand out now is hard to take back when the company grows past it.
Timing. If cash is tight now but a round is close, you can commit to a specific increase at a specific trigger, such as the close of the next raise. Put it in writing. A vague "we will revisit after the round" sounds like a stall and usually is one.
What a good answer sounds like
A good answer is specific, explained, and repeatable. For example: "We benchmarked your role against three sources. You are about 10 percent under the midpoint for the scope you carry, so we are moving base salary up to close that gap now. We are also adding a refresh grant that vests over four years, because your original grant was set when we were a much riskier company. And starting this quarter you own the hiring loop for the next backend engineer."
That answer does three things. It shows you took the request seriously and did the work. It ties every component to a reason, which means you can apply the same reasoning to the next engineer. And it addresses growth, which is what usually keeps an early engineer around more than money does, as covered in why first engineers leave around month 18.
The mistakes that cost the most
Saying yes to the exact number with no reasoning. You have now set a price without a rule, and you will negotiate against it forever.
Matching a competing offer dollar for dollar only after they resign. Counteroffers made under duress often buy months, not years, because the underlying reason for looking has not changed.
Stalling. A request left unanswered for six weeks tells your best engineer exactly how much the company values them. Even a "no, and here is why, and here is what would change it" is better than silence.
Using a title as a substitute for pay when the gap is real. Engineers notice.
When to get outside help
If you are a non-technical founder, the hardest part is knowing what the role is actually worth, because you cannot easily judge the scope your engineer carries. An outside senior technical person can assess the role in a few hours: what level the work really is, what the market pays for it, and what you would have to pay to replace it. That turns an emotional negotiation into a calibrated one. It is one of the things a fractional CTO engagement covers, and if you want to talk through a live situation, you can book a call.
Frequently asked questions
How much of a raise should I give my first engineer after a year?
There is no standard percentage. Benchmark the role by scope, not title, against two or three salary sources for your location. If they are below market for what they actually do, close the gap. If they are at market, consider an equity refresh or expanded ownership instead of a large cash increase.
Should I give an equity refresh instead of a raise?
Often both, in different proportions. Equity refreshes are common, and they reward staying because they vest forward. But equity does not pay rent. If base pay is clearly below market, fix that first and use a refresh on top.
What if we cannot afford a raise right now?
Say so honestly and offer a written, specific commitment tied to a trigger, such as closing your next round, plus whatever equity or scope you can offer today. A clear plan with a date is far more credible than "we will revisit later."
Should I set up pay bands now?
Once you have three or more engineers, simple bands by level save you from negotiating every salary from scratch. With one or two, a written rationale for each decision is enough, as long as you apply it consistently.