When to hire engineers instead of us

This question gets asked of us regularly and it deserves a straight answer, including the version of the answer where you should not hire us.

The usual framing is size: small projects go outside, big ones come in-house. That framing is wrong often enough to be expensive. The variable that actually decides it is how often the system changes once it is live.

Change rate, not project size¶

Some systems stabilize. A quoting tool, an inspection app, a scheduling system for a business whose scheduling does not fundamentally change: these get built, they get corrected for six months while reality argues with the design, and then they run. They need patching, monitoring and a few changes a year. Employing an engineer for that is employing somebody to be bored, which is the same as employing somebody who will leave.

Other systems never stop. A pricing engine in a business where pricing is the strategy, a marketplace, anything where the software is how the company competes rather than how it administers itself. There the change requests do not tail off, because every change generates the next one. That is a team, and it should be your team.

So ask what the system is expected to be doing in year three and who will be asking for changes to it. If the honest answer is roughly what it does at launch, you are buying a capital asset with a maintenance line. If the honest answer is that you cannot know because it depends what the market does, you are staffing a function.

The second question: is this software you sell?¶

A reliable line runs between software that supports the business and software that is the business, or is the reason a customer picks you over the next firm. The first can live outside indefinitely, and plenty of profitable companies run entirely on systems built by somebody else. The second comes in-house eventually, and the only real question is whether that happens deliberately or during a crisis.

If you are on the second side of that line and not ready to hire yet, the right move is not to pretend otherwise. It is to build in a way that can be handed over, and to say so out loud at the start so it shapes the decisions rather than being discovered at the end.

One engineer is not a team¶

Hiring a single engineer is the most common expensive mistake in the in-house direction, and it is made by capable people for sensible reasons.

• Nobody reviews their work, so the only quality control is their own discipline on their worst week.
• There is no cover. A holiday is a freeze and an illness is an outage.
• There is no second opinion, so an early architectural decision made alone is the one you live in for a decade.
• Everything they know is in one head, and their resignation is a total loss of it. This is the risk people notice, and it is not even the largest one.
• They are usually managed by somebody who cannot evaluate the work, which is uncomfortable for both parties and tends to end the relationship.

Two engineers is a different proposition entirely and more than twice as good. If the budget supports one, that is useful information about which side of the earlier question you are on.

The hybrid that works, and the one that does not¶

The failing hybrid is a firm building the system while your first hire watches, on the theory that they will absorb it and take over. Watching is not transfer. The new engineer spends six months in a role with no ownership, learns the parts they happened to be shown, and inherits the rest as a surprise.

The version that works has a date on it. The handover is scope in the engagement rather than goodwill at the end of it: your engineer owns named parts of the system from an agreed point, our people review their work rather than the reverse, and there is a written date after which they are on call and we are the ones being called for advice. It costs more than a handover that is a week of walkthroughs, and it is the difference between a team that can carry the thing and a team that has watched somebody else carry it.

What we would say on the call¶

If your system is going to change every week forever and it is the reason your customers choose you, hire. We would rather tell you that at the start than be the firm you are trying to unwind from in three years, and the arrangement where we build the first version and hand it to a team you are hiring in parallel is one we would take happily.

If it is going to stabilize, the math usually favors a firm, and the thing to negotiate hard is not the rate. It is how easily you could stop.