T

Afterwards the founder asks why the notification service was built as a separate deployable, and gets a perfectly good answer: it was in the ticket. Someone had written that ticket eleven weeks earlier, in week one, before anyone understood the system. Nobody revisited it, because revisiting it was not in anyone's scope. The work is fine. The direction was set by a document written when the team knew least, and no one had the standing to reopen it.

Deciding how to choose an engineering partner as a startup comes down to one question that rarely appears in any proposal: who holds judgement. Staff augmentation puts it with you. Project delivery puts it in the statement of work. An embedded senior engineer puts it with the person doing the work. All three are legitimate purchases, they cost roughly similar amounts across a year, and they fail in completely different ways. Picking the wrong one is not usually a quality problem, and it looks exactly like the demo above.

What are the three ways to buy engineering?

Staff augmentation is the one most often bought by accident. It is straightforward to compare on price, which makes it easy to get approved, and its failure mode is quiet. You are renting hands and continuing to supply direction, so output quality tracks the quality of your specification. A founder who could write a precise specification would generally not be hiring, and Brooks made the underlying point in The Mythical Man-Month in 1975: adding people to a late project makes it later, because coordination and onboarding cost more than the marginal output for some time. Three months is a normal payback period on a new contractor, which is most of a two-quarter engagement.

Project delivery works genuinely well on a bounded piece with a testable definition of done. A payments integration, a data migration, a specific compliance build. It goes wrong on anything exploratory, because the incentive on both sides becomes the letter of the scope document. The second failure is quieter and arrives later: the knowledge leaves when the team does, so a year on nobody in your company can confidently modify what was delivered.

The embedded model is what Team Topologies, published by Skelton and Pais in 2019, calls an enabling team. One or two senior people work inside your team with authority to make decisions and to change how things are done, and the deliverable includes the capability left behind. The failure mode is specific and worth naming, since it is the one I have caused: without an explicit mandate from the founder, an embedded engineer becomes a well-paid commentator whose recommendations get politely noted. This model needs the founder to say out loud, in front of the team, what this person is allowed to decide.

What are the warning signs, including the flattering ones?

The dangerous signals are the ones that feel good in the meeting.

A partner who agrees with your architecture in the first conversation has not read it. Agreement is the cheapest thing anyone can sell you, it costs nothing to produce, and it is indistinguishable from competence until about month three. The people worth hiring will disagree with something specific in the first hour, and will be able to say why in terms of a trade-off rather than a preference.

A proposal containing no questions is a template. Count them. A serious proposal for work of any complexity contains a list of things the author does not yet know and needs to find out, along with what changes depending on the answers. A document that is entirely assertion was written before the call.

Estimating without opening the code is the third. Anyone producing a number for a codebase they have not seen is estimating an average codebase, and yours is not average in exactly the ways that will cost money.

Then there is availability. A full senior team able to start on Monday is information about demand for them. It is not disqualifying, since gaps between engagements are normal and honest, and asking directly is reasonable.

Finally, notice whether anyone tells you what they will not do. A partner with no stated boundaries has not thought about where they add value, and will accept work they should decline.

What should I ask for before signing anything?

A paid diagnostic. Two weeks, fixed fee, with a written deliverable you keep regardless of whether the relationship continues.

The output should be an assessment of the system as it is, a prioritised list of risks with rough costs against each, and a recommendation that is genuinely allowed to be "do not do this project". That last part is what makes it worth paying for. The shape of the artefact is close to a technical debt audit, and if you never work with the firm again you still own a map of your own system, which is worth the fee on its own.

It is also the only cheap sample of the actual people. Proposals are written by whoever writes proposals. Two weeks of work tells you who really shows up, how clearly they write, what they notice that you did not mention, and whether they ask better questions in week two than in week one. Nothing in a pitch process gives you that.

A partner unwilling to sell a bounded diagnostic is telling you something about their economics. Some firms need the large contract for the numbers to work, which is a legitimate business model and a bad fit for a founder who is not yet sure what they need.

Why is day rate the wrong comparison?

Because you are not buying hours, and rate comparison quietly assumes you are.

Run the arithmetic on a real decision. Two engineers at €450 a day for six months is about 130 working days each, which comes to €117,000, and it delivers whatever direction was set in week one. One senior engineer at €900 a day for three months is roughly 65 days and €58,500, and the output is frequently a smaller system, because a good part of the work is deciding what not to build. The expensive engagement is the cheap one when the direction is wrong, and none of that shows up in a rate card comparison.

What you are actually comparing is decisions per euro. That is uncomfortable because it cannot be evaluated in advance from a proposal, which is precisely the argument for the paid diagnostic: it converts an unmeasurable claim into a two-week sample you can read. If you are not technical and worried you cannot judge the output, there are ways to assess engineering work without being an engineer that hold up better than a gut read of the final call.

Two contract details matter more than the rate. Own your intellectual property explicitly and in writing, including work by any subcontractor they use, since the alternative surfaces years later during diligence. And require that code lands in your repository, in your cloud account, from day one. A partner developing in their own environment and delivering at the end has structured the engagement so that leaving is expensive, whether or not anyone intended that.

The question almost nobody asks in a first meeting is what the end looks like. Every one of these three models should have exit criteria written down before it starts, and they differ by model. Staff augmentation ends when the backlog it was hired for is cleared, which means somebody has to define that backlog rather than letting it refill. Project delivery ends at acceptance, so the acceptance test needs to exist in the contract rather than being negotiated once everyone is tired. An embedded engagement ends when your own team can do the thing without help, which is the only one of the three where the deliverable is a change in someone else's capability, and therefore the only one where success is measurable by the partner's absence.

Ask directly how they will know when you no longer need them. The answer distinguishes a partner from a supplier faster than any reference call, because a supplier has never thought about it and a good partner has an opinion ready.

The general vendor-selection questions worth asking sit alongside these in how to choose a software development company, which covers the procurement side of the same decision.

Where does SpectreDev sit in this comparison?

We sell the third model, and occasionally the second. Embedded senior engineering attached to a named problem, plus bounded diagnostics of the kind described above. We do not sell staff augmentation.

Which makes this article not neutral, and the bias runs in a predictable direction: the model we sell is the one that comes out best in a comparison written by us. So here is the counterweight, stated as plainly as I can. If your backlog is well specified, your definition of done is clear, and you have a strong technical lead internally who is simply short of hands, staff augmentation is cheaper and better and we are the wrong call. That situation is common. It is roughly a third of the enquiries we get, and the honest answer to most of them is a smaller purchase than the one being discussed.

When should I hire in-house instead?

Several situations, and a founder reading this already suspects which one applies.

Work that is permanent and central to the product belongs to employees. If the logic in question is what makes your product different, and it will keep changing for as long as the company exists, that knowledge needs to live with someone who is not on a contract. No transfer process fully substitutes for the person who has been in it for three years.

A missing technical leader is a hiring problem wearing a procurement costume. If nobody internally can set direction, own the roadmap and say no to things, that is a CTO or a head of engineering, and buying consultancy hours postpones the hire while making it harder, because a candidate joining an estate built by three different vendors inherits an archaeology project.

Culture and process problems do not respond to external engineering either. A team that ships slowly because of unclear ownership, a broken planning cadence or unresolved conflict will keep doing that with better code review.

Underneath all three is the one that defeats every model equally. If nobody in the company can say what "done" looks like, no engagement structure fixes it, and every purchase makes the situation more expensive. That is worth resolving first, alone, cheaply, before signing anything with anyone.

There is also a version of this problem where the constraint is not the team at all, and the work you keep failing to schedule is enterprise readiness rather than product, which comes with its own budget and sequence.

Questions founders ask after a disappointing vendor call

What is the difference between staff augmentation and an agency? Staff augmentation places individuals inside your team under your direction, so you keep responsibility for what gets built. An agency or delivery partner takes an outcome and owns the plan for reaching it, which means you are buying a result rather than capacity.

How much does an engineering partner cost? Senior contract engineering in Europe commonly runs between €450 and €1,000 a day depending on the model and seniority, with embedded engagements at the higher end and far fewer days. Compare total cost to a working outcome rather than rate, since the cheaper rate frequently buys more days.

Should I hire in-house or use an engineering partner? Hire for anything permanent and central to the product, and buy for problems that are urgent, bounded, or need a level of experience you cannot yet attract as an employee. The timing argument matters as much as the work itself, since a good senior hire takes three to five months to land and start contributing, and some problems will not wait that long. Using a partner to hold the line while you run a proper hiring process is a legitimate answer, provided both sides know that is the plan.

How do I evaluate an engineering partner before signing a large contract? Buy two weeks first. A paid diagnostic with a written deliverable tells you how they think, how they write and what they notice, and you keep the document either way.

What should be in the contract with an engineering partner? Explicit IP assignment covering subcontractors, code in your repository and your cloud account from day one, a named individual rather than a role, and a notice period you can actually live with. The environment clause is the one most often missed and the most expensive to fix later.

The demo will go well again next month, and the month after that. Velocity is the easiest thing for a partner to deliver and the least informative signal you receive, which is why the question worth asking at the next one is not what got finished, but which decisions were made and by whom.