Six ways to engage. One bar for seniority.

How to choose

Match the model to the problem, not the pitch.

Most software development services are sold the same way — a stack page, a team photo, a rate card. None of that tells you which engagement model fits your problem, and the model decides more of the outcome than the logo on the proposal. The grid above covers what we build. This is how we’d choose between the ways of engaging us — or anyone — if we were sitting on your side of the table.

When a scoped project beats a retainer

A scoped project wins when the destination is known: a defined product to ship, a migration with a hard deadline, an integration with written acceptance criteria. You get a fixed team, a spec, and an end date — and when the work ends, the spend ends. A retainer earns its keep in the opposite case: continuous but variable work, steady product iteration, or an internal team that needs senior reinforcement more weeks than not.

The trap is scoping ambiguity as if it were certainty. If you can’t describe done in a page, a fixed scope will either bloat with change orders or ship the wrong thing very precisely. Buy discovery first — a short consulting engagement that turns the unknowns into a spec — then scope the build against it.

When a dedicated team beats hiring

Hire when the capability is core to your business and permanent — you want people who compound inside your walls for years, and you can absorb the months each senior search takes. A dedicated team wins on the other axes: it arrives in weeks with a tech lead already in place, it scales down without severance or morale damage, and it’s the honest answer when the roadmap is real for the next year but you can’t promise it beyond that.

One caution: never accept a dedicated team as anonymous capacity. You should know every engineer by name, interview them if you want to, and see them in your standups. Anything less is a black box with a monthly invoice.

What to look for in any development partner

Whichever model fits, the same tests separate a development partner from a body shop. Ask who exactly will do the work — names and CVs, not a bench description — and whether the people on the sales calls are the people who will write the code. Ask what happens when the engagement ends: if the answer isn’t documentation, a handover plan, and a codebase your own hires can run, you’re renting dependency.

Then ask how they say no. A partner who has never pushed back on a client’s technical decision won’t start with yours, and that pushback is most of what you’re paying senior engineers for. Finally, check the timezone overlap against your actual calendar — hours you can’t use for a working session don’t count.

Still unsure? That’s a signal in itself: start small. A scoped discovery or a short consulting engagement costs little, puts the answer in writing, and makes every decision after it cheaper.