When Project Pricing Fits a Fractional CTO
Project pricing fits when technical scope has a defined deliverable and a clean end state. Architecture review. Platform migration. Technical due diligence for M&A. Stack rebuild from PHP to a modern framework. ERP or data warehouse migration. Each has an output, a deadline, and a way to know it is done.
Most retainer CTO engagements should have started as projects. Companies that hire a fractional CTO on a retainer often discover six months in that the actual scope was a migration or an architecture review. The retainer was an expensive way to deliver a finite project.
Typical Project Pricing
| Project Type | Typical Fee | Duration |
|---|---|---|
| Architecture review and recommendations | $15,000-$40,000 | 4-8 weeks |
| Platform migration (e.g., legacy to modern stack) | $40,000-$120,000+ | 12-24 weeks |
| Technical due diligence (buy-side) | $20,000-$60,000 | 4-8 weeks |
| Technical due diligence (sell-side) | $30,000-$80,000 | 6-12 weeks |
| Engineering org design | $20,000-$50,000 | 4-10 weeks |
| Security audit and remediation plan | $25,000-$75,000 | 6-12 weeks |
| Cloud migration or cost optimization | $30,000-$100,000 | 8-16 weeks |
| SOC 2 readiness | $25,000-$60,000 | 10-20 weeks |
Fees vary with codebase size, team count, and how much the operator delivers vs how much they direct. A platform migration where the fractional CTO designs the architecture and reviews work runs lower than one where they personally write significant code. The hands-on premium is real.
Pros of Project Pricing
- Outcome alignment. The fee maps to a deliverable. Both sides care about the same thing.
- Forced scoping. Technical project scopes are notoriously vague. A fixed fee forces the conversation about what done means.
- Predictable budget. The project shows up as a single line item. Easier to approve, easier to track.
- Senior talent willing to engage. Many strong fractional CTOs prefer projects to retainers because the scope is bounded and the engagement does not drift into ongoing leadership work.
Cons
- Higher loaded rate. Project pricing typically lands at $400 to $700 per hour effective, vs $250 to $500 on a retainer. The CTO is pricing scope drift risk into the upfront fee.
- Change orders are friction. Mid-project scope shifts trigger renegotiation. Technical scope changes are the most common because the work surfaces problems no one knew about.
- Limited continuity. When the project ends, the engagement ends. If ongoing technical leadership is needed, the project model is the wrong fit.
- Handoff risk. Project deliverables that no one inside the company can operate end up shelved. Build handoff into scope.
How to Scope a Clean Project
Strong fractional CTO project contracts include four artifacts in the scope definition.
1. Concrete deliverables. "Architecture review" is not a deliverable. "Written architecture review covering data model, service boundaries, deploy pipeline, observability stack, and security posture, plus a 3-page recommendations memo with prioritized action items" is.
2. Decision rights. Specify who owns final calls on technology choices, vendor decisions, and architectural direction. Technical projects stall when decision rights are not clear, especially in companies with strong founder-engineer instincts.
3. Stakeholder map. Name engineering leadership, security, finance, and any external stakeholders (auditors, partners) who must approve, must be consulted, and must be informed.
4. Completion criteria. What does done look like? "Migration completed and production traffic on new stack for 30 days without rollback" is concrete. "Migration ready" is not.
Comparison to Retainer
| Need | Best Model | Why |
|---|---|---|
| Ongoing technical leadership | Retainer | Scope is open-ended |
| Defined deliverable, finite scope | Project | Fee maps to outcome |
| Strategic advisory only | Hourly or advisor retainer | Volume is unpredictable |
| Pre-revenue startup | Hybrid (cash + equity) | Cash constrained |
For retainer model context, see fractional CTO retainer and fractional executive engagement comparison.
Contract Terms That Matter
Milestone payments. Standard structure for projects past $25,000: 25 percent at kickoff, 25 percent at first milestone, 25 percent at second milestone, 25 percent at completion. Lump-sum-on-completion is rare and creates cash flow risk for the operator.
Change order protocol. Define the threshold. A common rule: any scope expansion requiring more than 5 percent additional hours triggers a written change order. Technical projects are particularly prone to scope creep because exploration surfaces unknown unknowns.
Code and IP ownership. Standard practice favors the company on outputs (code, architecture diagrams, documentation) and the operator on process IP (frameworks, methodologies, templates). Open-source contributions need explicit treatment.
Project-to-retainer conversion. If both sides anticipate ongoing engagement after project completion, write a conversion clause. "Project may convert to monthly retainer at $X for Y hours upon mutual agreement." This avoids friction at exactly the wrong moment.
Knowledge transfer. Build 2-4 weeks of overlap with internal engineering team into scope. Most technical projects fail at the handoff. Documentation, runbooks, and internal training should be in the deliverable list.
When Not to Use Project Pricing
Avoid project pricing when scope cannot be defined upfront. Greenfield product builds, novel system designs, and exploratory technical work all live with too much ambiguity for a fixed fee. Hourly or retainer with regular re-baselining works better.
Avoid it when the engagement is genuinely ongoing technical leadership. If the company needs a CTO for the next 12 months, dressing up retained leadership as a project produces friction.
For broader cost context, see fractional CTO cost and fractional CTO responsibilities.
Common Project Failures
Three patterns explain most failed fractional CTO project engagements.
Hidden technical debt surfaces in week 6. The CTO scoped the project against the system as documented. Six weeks in, the actual codebase reveals undocumented coupling, missing tests, or fragile dependencies that double the work. The fix: build a 1-2 week discovery phase into scope where the operator can verify the system before locking final fees. Treat upfront fees as an estimate that converts to fixed after discovery.
Engineering team resists the recommendations. The CTO delivers a strong architecture review or migration plan. The internal engineering team disagrees with the approach. The deliverable becomes a slide deck no one acts on. The fix: include the engineering team in the scoping phase and the milestone reviews. Buy-in cannot be added at the end.
Scope drift dressed as "while you're in there." Mid-project, the CEO or VPE asks the CTO to "also look at" observability, security posture, and the data warehouse. Each ask is small. Together they triple the scope. The fix: written change order protocol triggered at any 5 percent scope expansion. No exceptions.
FAQs
How much does a fractional CTO charge for an architecture review?
A typical architecture review runs $15,000 to $40,000 over 4 to 8 weeks. The fee includes a written assessment of the data model, service boundaries, deploy pipeline, observability stack, and security posture, plus prioritized recommendations. Larger codebases and more complex systems push toward the high end.
What does fractional CTO project pricing typically cover?
Common projects: architecture review, platform migration, technical due diligence (buy-side or sell-side), engineering org design, security audit, cloud migration, and SOC 2 readiness. Each has a defined deliverable, a deadline, and explicit completion criteria.
Is project pricing more expensive than a retainer?
The effective hourly rate is typically 30 to 50 percent higher under project pricing because the CTO absorbs scope drift risk. The total cost is often lower because the engagement ends when the project completes. Total cost depends on whether ongoing technical leadership is needed afterward.
How do milestone payments work for technical projects?
Standard structure for projects past $25,000: 25 percent at kickoff, 25 percent at first milestone, 25 percent at second milestone, 25 percent at completion. For projects under $25,000, 50/50 split (kickoff and completion) is common. Avoid full-payment-on-completion because of the cash flow risk to the operator.
What about handoff after the project completes?
Technical project handoff is the most common failure point. Build 2-4 weeks of overlap with the internal engineering team into scope. Documentation, runbooks, and internal training should be in the deliverable list. Without explicit handoff, deliverables get shelved and the project value evaporates.
How do I handle scope changes mid-project?
The contract should require a written change order for any scope shift requiring more than 5 percent additional hours. Technical projects are particularly prone to scope creep because exploration surfaces unknown unknowns. Insist on clean change order language upfront and re-baseline at every milestone.