Engagement Models
Three ways to engage
Different problems want different commercial structures. Below is the honest comparison — including where each model is a bad fit. If you're not sure which applies, a 30-minute scoping call is usually enough to point you at the right one.
Fixed-price delivery
A defined scope, a defined price, a defined deadline.
- Typical team
- 4–8 specialists assembled for the engagement
- Time to start
- 2–4 weeks from signed SOW
- Price shape
- Discovery invoiced time-and-materials; delivery invoiced against fixed milestones.
Best for
- Projects with a crisp, stable scope and clear acceptance criteria
- MVPs with a fixed launch window
- Procurement processes that require firm capex commitments
Where it breaks down
- Scope changes cost more than in T&M — intentionally, because the model's value is predictability
- Not appropriate when requirements are exploratory or likely to shift
How it works
- 1We run a paid discovery (1–2 weeks) to de-risk scope, estimate, and produce the delivery plan
- 2We commit to a fixed price and a fixed delivery window
- 3Change requests are handled through a lightweight change-order process — priced and scheduled before work starts
Time & materials
Pay for what we actually build, as we build it.
- Typical team
- 2–6 engineers scaled up or down each sprint
- Time to start
- 1–2 weeks from signed MSA + SOW
- Price shape
- Blended or role-based hourly rate. Monthly invoice with an itemized statement of work.
Best for
- Ongoing product development with evolving priorities
- Teams iterating toward product-market fit
- R&D or prototyping where specs aren't yet concrete
Where it breaks down
- Less predictable than fixed-price — you take on scope risk in exchange for flexibility
- Requires an engaged product owner on your side to prioritize continuously
How it works
- 1Weekly or bi-weekly sprints with transparent tracking of engineer hours
- 2You set priorities; we deliver against the agreed sprint goal
- 3Monthly invoice reflects actual work delivered, with a detailed breakdown
AI Pod
A pre-formed, AI-augmented team that ships to production from sprint one.
- Typical team
- 4–7 specialists per pod, plus a custom agentic layer (orchestration, RAG, internal tooling)
- Time to start
- Pod operational by end of week 1; first production delivery in week 2
- Price shape
- Outcome-based on most engagements (no token counting, no surprise bills). Fixed-scope, fixed-price for well-bounded work. Low-risk entry points: 2-week LLM Integration Sprint, 4-week Documentation Pod, 90-day QA Bot Pod, one-shot Architecture Review.
Best for
- Outcomes that need a full team — architect, lead, PM, devs, QA — not a single contractor
- AI or agentic workflows where the eval harness, observability, and guardrails matter as much as the model
- Engagements where you'd rather pay for outcomes than for tokens or seat-hours
- Modernization or new-build work that has to ship in weeks, not months
Where it breaks down
- Pods are project teams, not call centers — if you need a permanent SLA managed service, this isn't it
- If you only need one engineer to fill one specific gap, staff augmentation is a better fit
- Outcome-based pricing requires a metric we can both instrument; ill-defined goals don't qualify
How it works
- 1Day 1 discovery call; days 2–4 scope and pod-shape analysis; days 5–7 pod assembled and onboarded
- 2First production delivery in week 2 — narrow vertical slice with full instrumentation
- 3Quarterly cycles with named outcome metrics; scale up, scale down, or wind down between cycles
- 4Exit includes 100% IP transfer: code, agent configurations, prompts, RAG knowledge bases, runbooks
Dedicated team
A long-term extension of your engineering org.
- Typical team
- 2–15 engineers; squads can scale to larger
- Time to start
- 3–6 weeks for a matched first engineer; faster for subsequent additions
- Price shape
- Monthly rate per engineer, by seniority. Quarterly minimums; notice period for changes.
Best for
- Clients building a product over multiple quarters who need continuity
- Enterprises filling structural capacity gaps without the overhead of direct hiring
- Organizations that want engineers embedded into their processes, not a black-box vendor
Where it breaks down
- Requires your side to have engineering management in place — we're not a managed service provider in this model
- Not the cheapest option if you only need a short sprint of work
How it works
- 1You interview and accept each engineer, the same way you'd hire an employee
- 2They work your hours, in your tools (Jira, Slack, Git, etc.), attend your standups, report to your managers
- 3We handle employment, payroll, benefits, laptops, HR, retention — you get output