Most first engineering hires are made for the wrong reason. Something needs building, budget exists, and hiring feels like the responsible way to spend it. But a permanent employee is not a way to buy a project. It is a standing commitment to a role, and the question that decides whether that commitment pays off is not how much work there is right now. It is whether the work keeps arriving after the first thing is finished.
This guide is for an owner or operator who cannot personally assess technical work.
The signal that justifies a permanent hire
The signal is continuous, ongoing change to a system that is core to how the business makes money. Not a build. Change: pricing rules that shift each quarter, customers who need a new integration to sign, reports that finance asks for and then asks to have adjusted, a workflow that has to bend every time you open a location or add a product line.
That kind of demand does not end, and it does not fit an engagement model well. Every outside arrangement carries a re-engagement cost: context reloading, scheduling, a statement of work for something that takes two days. When that overhead starts appearing every few weeks, an employee becomes the cheaper and faster option, and the value of someone carrying the domain in their head compounds.
The inverse is just as clear. If what you have is a defined build with an end (replace the spreadsheet system, get the portal live, migrate off the platform), that is a project, and hiring for it means you have made a permanent commitment to solve a temporary problem. When the build finishes you will either invent work to justify the role or lose the person who knows how everything fits together.
- Requests for changes to a core system arrive weekly rather than quarterly
- Someone in the business is already doing shadow technical work: writing scripts, maintaining an Access database, holding integrations together
- Downtime or a data problem costs real money the same day it happens
- Software is part of what you sell, not only part of how you operate
- You are consistently paying external hourly rates for work that is small, urgent, and repetitive
The mistake that costs the most
The single most expensive error in this decision is hiring one engineer and asking them to build an entire platform alone. It is common because it looks efficient (one salary, full control, no agency markup), and it fails for reasons that have nothing to do with the person's ability.
It creates a single point of failure. One person holds every architectural decision, every credential, every undocumented assumption about why a rule works the way it does. If they leave, get sick, or simply want a holiday, the system stops evolving and nobody left in the building can explain it. The business becomes dependent on an individual rather than on an asset it owns.
It also removes review. Engineers working in teams catch each other's mistakes constantly: a missed security check, a data model that will not survive the second country, a shortcut taken under deadline. A solo engineer has no one to catch anything, and a non-technical manager cannot supply that review no matter how engaged they are. The errors are invisible until they are structural, at which point fixing them means rebuilding rather than adjusting.
What a first hire can realistically own
A first engineer works well when something already exists for them to own. Their value is proximity: they sit near the operation, learn the domain, and turn requests into changes quickly because they do not have to be briefed each time. That is a genuinely different job from designing a system from nothing.
- Running and supporting an existing system, including incidents, monitoring, and dependency updates
- Incremental change: new fields, new rules, new reports, adjustments to workflows that already run
- Integrations with the platforms you keep, and the failure handling those integrations need
- Internal tooling and automation that removes manual work nobody has time to remove
- Being the informed counterpart to any vendor or partner you engage, and holding them to a standard
- Documentation and knowledge transfer, so the second hire is faster than the first was
Note what is missing from that list: greenfield architecture, data migration strategy, and security design for a system handling money or personal data. Those are senior, high-consequence decisions that are cheap to get right once and very expensive to revisit. They deserve more than one set of eyes regardless of how you staff the ongoing work.
The alternatives, and when each is better
There are four reasonable ways to get engineering capacity, and they are not competitors. Most businesses use two or three at once, and the right mix changes as the system matures.
| Situation | Hire, contract, or partner | Reasoning |
|---|---|---|
| A defined build with a clear end (replace a system, ship a first product) | Outside delivery partner | The work is temporary and needs a team, not a person. A partner brings review, coverage, and people who have done the same migration before. |
| A core system needs change continuously, and the change never stops arriving | Permanent hire | Re-engagement overhead exceeds the work itself. Domain knowledge held in-house pays back every week. |
| You need the platform now but intend to own it internally later | Partner first, hire during the build | The hire inherits a documented, reviewed system and is trained by the people who built it, instead of arriving to an empty repository. |
| You already have one engineer and they have no review, depth, or cover | Embedded senior engineers alongside them | Adds a second set of eyes and specific expertise without committing to headcount you may not need in a year. |
| You cannot judge technical decisions, vendors, or candidates yourself | Fractional technical leader | Buys judgement rather than capacity. A few days a month is usually enough to set direction, review proposals, and supervise whoever does the work. |
| The work is real but intermittent (a few days a month, indefinitely) | Contract engineer on retainer | Continuity of the same person without the fixed cost and management load of an employee. |
| Software is the product and the roadmap is permanent from day one | Permanent hire, with outside review of the foundations | Ownership belongs in-house, but the initial architecture and security decisions still need a second opinion before they harden. |
Evaluating candidates when you cannot read code
The honest constraint is that you cannot assess technical quality from an interview conversation, and confident presentation correlates poorly with engineering ability in either direction. Do not try to bridge that gap with intuition. Design the process so the evidence comes from somewhere other than your judgement of the code.
Ask for work samples with context
Repository links alone tell you little. Ask instead for a system they built, and then ask them to explain the decisions: what they chose not to build, what they got wrong and how they found out, what they would do differently. Weak candidates describe features. Strong ones describe trade-offs, constraints, and consequences. You can evaluate reasoning without evaluating syntax.
Run a paid trial project
Pay for a small, real piece of work over a few days: an integration, a report, a fix to something that annoys the operations team. This is the single highest-signal step available to a non-technical hirer, because it produces evidence you can judge directly. Did it work? Did they ask good questions? Did they tell you when the estimate moved, before it moved? Pay a fair rate for it, because unpaid trials filter out the candidates you most want.
Bring in an outside technical assessor
Have an experienced engineer with no stake in the outcome review the candidate's work and sit in on one interview. This costs a fraction of the hire and is the cheapest insurance available in the process. Use someone who is not also bidding to do the work; a partner evaluating whether you should hire instead of engaging them has an obvious conflict, and you should say so out loud when you ask.
Test the non-technical half of the job
A first hire spends much of their time talking to people who do not use technical language. Put them in a room with the operations lead and work through a real workflow problem. Whether they ask about the business before proposing a solution predicts success better than any technical measure.
What has to exist before they start
A first engineer with nothing to inherit and no one to report to spends their first months guessing. That is not a performance problem; it is a setup problem, and it is on the business to solve before the start date.
- 1
Name the person who decides. Someone must be able to settle domain questions (what the pricing rule actually is, which record wins) within two business days.
- 2
Write down the first ninety days as outcomes, not activities. Two or three specific things that will be measurably better, agreed before the offer.
- 3
Sort out access and ownership. Accounts, repositories, domains, and hosting must be owned by the company, with the engineer added as a user. Never the reverse.
- 4
Arrange technical supervision from somewhere. A fractional technical leader, an engaged advisor, or a partner engagement will do, as long as someone reviews the work and can tell you whether it is good.
- 5
Decide what they are not responsible for. Security architecture, migration strategy, and vendor selection should have named owners even if the engineer contributes to all three.
- 6
Plan for the second hire or the standing partner. A team of one is a temporary state; decide now what ends it, so the answer is not decided by a resignation letter.
If you cannot put those six things in place, the hire is premature. That is not a reason to do nothing. It is a reason to buy the work in a form that comes with its own supervision until the conditions exist.
Common questions
- How do I know whether I need an employee or a contractor?
- Look at whether the work is continuous or bounded. Ongoing change to a system the business runs on justifies an employee; a build with a defined end does not. If you are unsure, engage the work externally first. Converting a partner engagement into a hire is straightforward, while unwinding a hire that should not have been made is not.
- Can one engineer build our platform if we give them enough time?
- Sometimes, and we have seen it work. But it concentrates every architectural decision, credential, and undocumented assumption in one person, with nobody able to review any of it. If you take that route, budget for periodic outside review of the architecture, security, and data model, and require documentation as a condition of the role rather than a nice-to-have.
- Should the first hire be senior or junior?
- Senior, if they will be the only engineer. A junior engineer needs review and mentorship that a non-technical organization cannot supply, which is unfair to them and risky for you. Junior hires work well as a second or third engineer, where someone experienced can supervise the work day to day.
- How do we test technical skill without a technical interviewer?
- Use a short paid trial project on real work, and bring in an outside engineer with no stake in the outcome to review the result and sit in on one interview. Between those two steps you get direct evidence of the work and an informed second opinion, which is more than most technical interviews produce.
- Is it cheaper to hire than to engage a firm?
- The cost shapes differ more than the totals do. A hire is a lower ongoing rate but a fixed commitment that continues through slow periods, plus recruiting, equipment, benefits, and management time. A partner costs more per hour but scales down to zero and brings a team. For steady, continuous change an employee is usually cheaper over a year; for concentrated project work it usually is not.
- What if we hire and the work runs out?
- This is the most common outcome when a hire is made to deliver a project rather than to run a system. Before making an offer, write down what the role does in month twelve, once the initial build is finished. If that answer is thin, the work is a project and should be bought as one.