The problem is not lack of talent. The problem is that work does not arrive in full-time-job-shaped boxes. A typical month at a growth-stage SaaS company might need 3 DUs of React frontend work, 5 DUs of AI integration, 2 DUs of UI/UX polish, 4 DUs of integration engineering with a downstream system, 3 DUs of QA automation, and 2 DUs of dbt analytics work. That's 19 DUs of cognitive output across six different skill specialisms. Hiring a full-time engineer for each of those needs creates 5+ FTEs you cannot keep busy enough to justify; hiring one generalist creates 3-4 skill gaps where the work goes to half-effort or stalls.
This is the fractional execution problem. It's the structural mismatch between modern work — fragmented across many specialisms, variable in volume month-over-month, accelerating in pace — and traditional staffing models that assume work fits into full-time roles. The mismatch costs companies enormous amounts in postponed work, half-shipped features, and idle full-time capacity in the wrong specialisms. Outcome-based delivery via Delivery Units is the structural fix.
Why modern work is fragmented across skills
The skill specialization in modern software has expanded dramatically. Twenty years ago, a "web developer" did the whole stack. Today, shipping a customer-facing feature might require:
- A frontend specialist with React + TypeScript depth
- A designer for the UX flows
- A backend specialist for the API
- A data engineer for any analytics or instrumentation
- An AI engineer if there's an LLM-powered feature
- A platform engineer for infrastructure work
- A QA engineer for the test suite
- An accessibility specialist for compliance
- An SEO specialist if the feature is customer-facing on the marketing surface
Not every feature needs all nine specialisms. But over a year of shipping, a product team will need every one of them — in different proportions, at different times, for different durations. The total volume of any single specialism may not reach a full-time job; the variance from quarter to quarter makes hiring at full-time scale even harder.
Why hiring full-time creates waste
The natural response — "we need more engineers, let's hire" — runs into three structural problems:
- Specialism mismatch. The hire's specialism rarely matches the actual fractional needs. You hire a senior backend engineer for the long pipeline of API work and discover most of next quarter's work is frontend modernization. The engineer either stretches outside their specialism (slower, lower quality) or sits underutilized.
- Variance absorption. Quarter-to-quarter variance in work volume is real. Hiring for peak demand means trough-quarter idle time the company pays for. Hiring for steady-state means peak quarters get pushed back, customer commitments slip, and morale erodes.
- Wrong-end-of-the-curve specialists. Some specialisms only need 5-10 DUs of work per quarter (rare-stack expertise, accessibility audits, SEO consultation). No one hires a full-time accessibility engineer for 5 DUs/quarter; the work either gets squeezed out of scope or done badly by a non-specialist.
The cumulative effect: companies postpone or skip important work because the staffing math doesn't justify hiring. Backlogs accumulate. Quality decays.
Why vendors hate small fractional work
Traditional vendors — staff augmentation firms, dedicated team providers, consulting firms — are not built for fractional execution. Three reasons:
- Sales economics don't support small engagements. A staff aug firm needs to invest in the customer relationship; if the engagement is 5 DUs of work, the sales investment doesn't pay back. Most vendors enforce minimum engagement sizes ($50K, $100K, $250K) that rule out small fractional work.
- Operational economics don't support multi-specialism within one engagement. A vendor's project manager handles one engagement at a time; spinning up across six specialisms for fractional work means six PM-equivalent overheads on a single small engagement. The vendor either bundles unwanted scope or refuses the work.
- Pricing models punish small work. Hourly billing has minimum-day or minimum-week thresholds; fixed-bid has minimum project sizes; dedicated team has minimum-engineer commitments. Each model has a floor below which the engagement isn't economic for the vendor.
The result: small fractional work either falls to freelance marketplaces (with the coordination overhead landing on the customer) or doesn't get done.
Why freelancers create coordination overhead
Freelance marketplaces (Upwork, Toptal, Braintrust, Turing) are the closest available answer for fractional work. The customer can hire a freelancer for the 5 DUs of frontend, another for the 3 DUs of design, another for the 2 DUs of dbt. In theory, this assembles fractional capacity at marketplace economics.
In practice, the customer absorbs all the coordination cost:
- Six freelancer relationships to source, vet, and manage
- Six engagement onboardings into the codebase, conventions, and tooling
- Six standalone scope conversations with no shared context
- Cross-discipline handoffs (frontend → backend → QA → designer) all happening across freelancer boundaries with no one accountable for the integration
- Hourly billing on each engagement, with the bench-tax and ramp-tax accumulating per relationship
What started as "we'll save money with freelancers" becomes 30+ hours/month of in-house engineering management on six small engagements. The marketplace economics are real for single-freelancer work; they break for fractional multi-specialism execution.
How Delivery Units solve fractional execution
Delivery Unit pricing flips the unit. Instead of paying for engineer-time per specialism, the customer pays per shipped DU regardless of which specialism produced it. Three structural properties make this work for fractional execution:
- One contract, multi-specialism pod. AiDOOS commissions a Virtual Delivery Center with the right composition for the work. The pod has 1-2 specialists in each needed specialism — the customer doesn't run six freelancer relationships, just one platform engagement.
- DU pricing absorbs specialism variance. Within a credit pack, the customer can consume DUs across any specialism the pod can deliver. 5 DUs of frontend this month + 3 DUs of design next month + 2 DUs of dbt the month after — same DU pack, no per-specialism contracting.
- Embedded delivery management absorbs coordination. The pod's Delivery Manager handles the cross-specialism coordination, scope clarification, and milestone gating. The customer's engineering manager spends 1-2 hours/week on the engagement instead of 30+ hours/month managing freelancers.
The customer's experience: "I have 60 DUs available; I'll consume them across whatever specialisms my work needs this quarter." The composition of those DUs is the platform's problem, not the customer's.
How VDC Packs solve unpredictable demand
Beyond specialism variance, fractional execution has volume variance. Some quarters need 80 DUs of work; some need 30. Traditional vendors handle this badly — fixed-bid contracts price for peak demand, dedicated teams charge regardless of volume. AiDOOS DU credit packs handle volume variance natively:
- Starter pack (10 DUs / 90 days) — for testing the model with a small slice of work
- Small pack (60 DUs / 6 months) — covers most growth-stage SaaS quarter-by-quarter needs
- Scale pack (300 DUs / 12 months) — for sustained multi-specialism delivery
- Enterprise pack (custom commitment, custom validity) — for predictable annual programs
Unused DUs roll forward when topped up, or refund at the rate paid if the customer's needs change. This converts the structural mismatch (variable demand, variable specialisms) into a flexible execution capacity the customer can deploy as needed.
Worked example — fractional execution at a growth-stage SaaS
Mid-Series-B SaaS company. Quarterly engineering needs:
- Q1: 12 DUs frontend, 8 DUs backend, 4 DUs design, 3 DUs dbt analytics, 5 DUs AI integration = 32 DUs
- Q2: 8 DUs frontend, 12 DUs SaaS implementation, 6 DUs design, 4 DUs accessibility, 5 DUs QA = 35 DUs
- Q3: 10 DUs AI integration, 8 DUs MLOps, 5 DUs frontend, 4 DUs design, 5 DUs platform = 32 DUs
- Q4: 15 DUs feature acceleration, 6 DUs SEO content engineering, 4 DUs design, 3 DUs QA = 28 DUs
Total: 127 DUs across 11 different specialisms over 12 months. Traditional staffing math:
- Hire 11 specialists full-time (~$1.5M/year loaded) — 90% idle in the wrong-quarter specialisms
- Hire 3 generalists full-time (~$450K/year loaded) — significant gaps in specialist work, slower velocity
- Mix of freelancers across 11 marketplace relationships — 30+ hours/month coordination overhead
AiDOOS math:
- Scale tier (300 DUs / $40,000 / 12-month validity) — covers 127 DUs of consumption with 173 DUs unused
- Refund unused 173 DUs at the rate paid — net cost ≈ $17,000 for the 127 DUs consumed
- Or: top up before expiry to roll the 173 DUs forward into year 2
- Customer-side coordination: 6-8 hours/month with the embedded Delivery Manager
The traditional staffing options range from $450K-$1.5M loaded; AiDOOS lands at ~$17-40K/year true cost for the same shipped output. The economics are not subtle. They reflect the structural advantage of paying for shipped DUs across any specialism rather than paying for full-time engineers in specific specialisms.
FAQ
Does this work for sustained heavy-volume engagements?
Yes — Scale tier ($40K / 300 DUs / 12-month validity) and Enterprise tier (custom DU commitments at $120-$140/DU) handle high-volume sustained work. The fractional-execution thesis applies to companies whose volume varies enough that fixed-headcount math doesn't fit; sustained-volume engagements get the volume-discount tier rates.
Can I scope each piece of work separately, or do I commit upfront to a pack?
Either. Project flow lets the customer scope each engagement individually with DU sizing per scope; pack flow pre-purchases DUs that consume across multiple engagements. Same rate card across both flows at the same DU count — no on-demand premium.
What about specialisms AiDOOS doesn't have on the bench?
AiDOOS's talent pool is 100k+ globally with breadth across major specialisms. For genuinely rare specialisms, the platform sources per-engagement; some niche specialisms may require longer setup time or carry higher DU consumption. Common multi-specialism needs (frontend, backend, data, AI, design, QA, DevOps) are bench-resident.
Doesn't this just shift the coordination problem to AiDOOS?
Yes — and that's the point. AiDOOS is structured to absorb cross-specialism coordination at the platform layer. The embedded Delivery Manager handles cross-pod handoffs, milestone gating, and scope clarification. The customer pays once (in DUs) for the shipped output; the platform pays internally for the coordination overhead.
How does this compare to a fractional CTO or fractional engineering manager service?
Fractional CTO/EM services provide leadership; they don't provide the underlying engineering execution. AiDOOS provides the execution capacity (the pod) plus the embedded delivery management. For companies that want both, they pair cleanly — the fractional CTO advises on architecture and strategy; the AiDOOS pod ships the work.
Where to start
If your engineering work is fragmented across multiple specialisms with variable volume, the fractional execution problem is real and AiDOOS is built to solve it. Schedule a call to walk through your typical quarter's work and get a tier recommendation.
For the broader operating model, see Outcome-Based Delivery, Delivery Units, and Staff Augmentation Alternative. For terminology, see the AiDOOS glossary.