The Embedded Team Cost Ledger: Ten Years of Retainers, Headcount Curves, and the Months We Billed Zero

What an embedded engineering engagement actually costs, month by month

An embedded team is priced as a monthly retainer tied to a committed engineer count, not per feature. Across our GlycanAge and Plodovi engagements, monthly invoices moved roughly between a one-engineer floor and a four-engineer peak, rising and falling with build phases rather than staying flat for years.

The structure is simple enough to state in one sentence: you reserve N engineers for the month, you pay for N engineers, and whether those engineers spent the month shipping a lab integration or fixing a production incident is your allocation decision, not a billing event. At Jaspero's published rate bands, a single committed senior engineer lands in the low-to-mid four figures per month at part-time allocation and the five-figure range at full allocation. Multiply by the FTE count in a given month and you have the invoice.

What founders underestimate is how much the number moves. A six-year engagement is not seventy-two identical invoices. In the GlycanAge relationship the spread between the smallest and largest monthly invoice was more than a factor of four, driven almost entirely by how many people were reserved that month. If you are budgeting an embedded team as a flat line in a spreadsheet, you are modelling the wrong shape.

The headcount curve: 1 engineer at kickoff, 4 at peak, 1.5 in maintenance years

The FTE curve on both long engagements followed the same shape: one engineer during discovery and the first system, a climb to three or four during the heavy multi-system build, then a deliberate settle to between one and two engineers for the maintenance and iteration years. The curve is a bell, not a ramp.

GlycanAge started in 2019 with a single engineer building the first customer-facing system. Headcount climbed as the surface area grew, peaking at four during the period when the laboratory management system, warehouse and kit logistics, and the partner dashboard were being built in parallel against a live operation. Once those systems were in production and the release cadence shifted from new-system delivery to iteration, we stepped down to roughly one and a half engineers, one full-time plus a shared allocation for reviews, upgrades, and incident cover.

Plodovi followed a compressed version of the same curve over four years. One engineer on the marketplace website, a rise to three when the retailer portal, shopper app, and delivery logistics were being built against each other, then a settle to a lower steady state once the six systems were integrated and the work became seasonal load handling, BI dashboard changes, and retailer onboarding features. The peak in both cases coincided with parallel system builds, which is the single most reliable predictor of when an embedded team needs more people.

• • Phase 1, discovery and first system: 1 engineer, often part allocation
• • Phase 2, parallel system build: 3 to 4 engineers, the most expensive stretch by far
• • Phase 3, integration and hardening: 2 to 3 engineers, tapering
• • Phase 4, maintenance and iteration: 1 to 1.5 engineers, stable for years
• • Phase 5, post-handover support: fractional, often measured in days per month

Retainer months versus time-and-materials months, and when we switched

Retainer buys continuity and reserved capacity; time and materials buys flexibility at the cost of queue priority. Both long engagements ran on retainer through build and maintenance phases and switched to time and materials only in transitional periods, typically after an in-house hire or during a low-demand stretch.

The practical difference is who carries the risk of a quiet month. On retainer, we carry the obligation to have people available and the client carries the cost even if the backlog thins out. On T&M, the client carries no cost in a quiet month but also has no claim on our calendar, which means a sudden urgent request competes with whatever else is booked. In a regulated product like GlycanAge, where a lab integration failure is not a ticket that can wait a week, retainer was the right structure for almost the entire engagement.

We moved Plodovi to time and materials for a stretch after the platform stabilised and the client's own operational priorities shifted toward commercial work rather than product changes. The switch was mutual, written down, and included an explicit re-entry clause: if monthly hours crossed an agreed threshold for two consecutive months, we would revert to a retainer band. That clause exists precisely because T&M months that quietly grow into full-time work are bad for both sides. The client loses cost predictability and we lose the ability to staff properly.

The four months we invoiced zero, and what a paused month costs in continuity

Across ten combined engagement-years there were four months where we invoiced nothing. Two were client-initiated pauses during funding and cash-flow gaps, one was a seasonal trough at Plodovi where there was genuinely no work worth billing for, and one was ours: a month we wrote off after a scope failure we caused.

The two funding-gap pauses were handled the same way both times. We agreed in writing that the retainer was suspended, not terminated, that we would keep production monitoring and critical incident response in place at no charge, and that the engineers previously reserved would be reassigned and might not all come back. That last clause matters and founders routinely miss it. A paused month is not a freeze frame. Context leaves with the person, and re-onboarding a replacement engineer into a ten-system health-tech estate costs real weeks.

The seasonal zero at Plodovi was uncomplicated: a month with no planned work, no incidents, and no reason to invoice a retainer nobody would consume. We flagged it ahead of time rather than billing and then explaining. The self-imposed zero came from a scope failure where we had estimated a piece of work against assumptions we should have verified during discovery, and the rework was our cost to absorb. Writing off a month is expensive, but the alternative, arguing about whose misunderstanding it was, costs more in a relationship you expect to still be in three years later.

• • Client cash-flow pause: retainer suspended in writing, monitoring and critical incident cover continued unbilled, no guarantee of the same engineers returning
• • Seasonal trough: flagged in advance, no retainer charged for a month with no planned work
• • Self-imposed write-off: rework caused by our own estimation failure, absorbed rather than invoiced
• • The continuity cost of any pause: re-onboarding an engineer into a multi-system estate is measured in weeks, not days

Ramp-down without ending the relationship: notice periods, floors, and handovers to in-house hires

Ramp-down is negotiated as a reduction in committed FTE, not a termination. Both engagements used a 30-day written notice for headcount changes, a minimum retained allocation so the relationship never dropped to zero, and named-system handover documents at each point the client hired in-house.

The mechanism we use is a floor plus a notice period. The client can reduce committed headcount at any renewal point with 30 days written notice, but not below an agreed floor, usually somewhere around half an engineer, which covers dependency upgrades, security patches, review of the in-house team's pull requests, and an incident escalation path. Keeping that floor is what preserves institutional memory. The alternative, a clean stop followed by an emergency call nine months later, means paying for re-onboarding instead of retention.

Both clients eventually hired in-house, and both times the handover was scoped to named systems rather than "the codebase". At GlycanAge, the customer-facing surface moved first while we kept the lab and logistics systems, because those carried the compliance and traceability rules that took longest to transfer. At Plodovi, the marketplace front end went in-house while the delivery logistics and BI pipeline stayed with us. In both cases the handover package was concrete: repository access and ownership transfer, architecture and data-flow documentation, a runbook for the specific system, two to four weeks of paired work, and a defined support window after cutover. Notice periods were actually used, not waived, and the relationship continued on the reduced band.

• • 30-day written notice for any change in committed headcount, in both directions
• • A minimum retained allocation so the engagement never hits zero and memory is not lost
• • Handover scoped system by system, never as an all-at-once codebase transfer
• • Repository ownership, runbook, architecture docs, paired weeks, and a post-cutover support window as the standard handover package
• • Compliance-heavy systems handed over last, customer-facing systems first

How to budget an embedded team before you sign

Budget the curve, not the average. Model three bands: a build peak of three to four engineers for the months where multiple systems are being built in parallel, a hardening band of two, and a maintenance floor of one to one and a half. Then add a contingency line for the months the curve is wrong.

The most useful planning exercise we run with founders is counting parallel systems, not features. Every system that has its own users, its own permissions model, and its own deployment target adds meaningfully to required headcount while it is being built, and adds a smaller but permanent amount to the maintenance floor once it is live. Six systems at Plodovi and ten-plus at GlycanAge is why those maintenance floors sat where they did. A single-product SaaS with one admin panel has a much lower floor.

The second thing worth pricing before signing is the exit. Ask what the notice period is, whether there is a floor, who owns the repositories from day one, and what a system handover actually includes. If an agency cannot answer those without checking with someone, the economics of the engagement are not the thing you should be worrying about. We wrote our own answers down in the client handbook for exactly that reason, and the numbers in this post come from engagements where those terms were tested in both directions.

The engagement behind most of these numbers is documented in our GlycanAge case study, covering the 10+ interconnected systems built and maintained across six years.