Software development engagement models

A fixed-price engagement starts before any code does. We work from a detailed specification, usually the output of a discovery phase. From it we agree the feature list, the team and the delivery date, then quote a single price for all of it.

That price has to hold for the life of the project, which cuts both ways. It carries a risk buffer, so it is rarely the cheapest number on paper. In exchange, if the build takes longer than we estimated, the overrun is ours to absorb: the figure you sign is the figure you pay.

Payment is tied to delivery milestones, and most contracts open with a prepayment. Anything outside the agreed scope goes through a written change request that states the new price and the new deadline before that work begins.

Time and material bills for the hours actually worked, at an agreed rate per role, invoiced monthly with a report showing where the time went. A developer logs between 80 and 160 hours a month, depending on whether you book them part-time or full-time. The invoice follows the project’s real pace, not a forecast made months earlier.

The obvious worry is an open-ended bill. In place of a guaranteed total you get month-by-month control. The burn rate is visible as it happens, and you agree the scope of every sprint. You can slow the team down, scale it up, or stop at the end of any billing period.

It also means work can start before the specification is finished. That helps when the fastest way to learn what to build is to put something in front of real users.

A dedicated team is a flat monthly payment for a group of specialists — engineering, QA, design, whatever the roadmap calls for — working only on your product. You direct their priorities as you would an in-house team; we carry recruitment, retention, replacement and the administration behind them.

Over a long engagement it is usually the most economical of the four, for a structural reason. The commitment is continuous, so we are not pricing in the risk of idle time between projects. That puts the effective monthly rate below the equivalent time-and-material arrangement. The team’s product knowledge compounds too, instead of resetting every time a contract ends.

The trade-off is the commitment itself. Below roughly six months the ramp-up rarely pays for itself, and the model assumes someone on your side can direct a team week to week.

Team augmentation means hiring specialists with the exact skills a role needs and placing them inside the team you already have. You assign their tasks, run their stand-ups and review their work as you would for an in-house hire; we carry recruitment, contracts, payroll and cover if someone leaves.

The difference from a dedicated team is scope, not people. A dedicated team is a standing unit sized to a roadmap and shaped by us. Augmentation is one named skill filling one named seat, inside a process that already works: a mobile engineer for a platform you don’t cover, a QA lead ahead of a release.

That makes it the quickest of the four to arrange and the easiest to unwind. Budget for onboarding, though: however senior the specialist, nobody is productive in an unfamiliar codebase on day one.