A funded healthtech startup was 3 months into building their product when they realized something was wrong. Features that should take 1 week were taking 3. The development agency they hired was not meeting milestones. A fractional CTO assessment revealed the root cause — and saved the company from a $200K rewrite.
The Situation
Company: Healthtech startup (patient data management) Stage: Seed-funded, $800K raised, 14 months of runway remaining Product: Web application for clinics to manage patient records and billing Development: External agency, 4 developers, 3 months into build Problem: Delivery velocity declining sprint over sprint
The founders (non-technical) noticed the pattern:
- Sprint 1-2: Agency delivered features on time
- Sprint 3-4: Features started taking 50% longer than estimated
- Sprint 5-6: Every feature required "foundational work" before implementation
- Sprint 7: Two features estimated at 1 week each took 3 weeks combined
The agency's explanation: "The product is getting more complex. This is normal." The founders were not sure if that was true.
The Assessment
We conducted a 2-week fractional CTO assessment. The scope:
- Full codebase review
- Architecture analysis
- Development process evaluation
- Technical risk assessment
- Remediation plan
What We Found
Problem 1: No separation of concerns
The entire application — API endpoints, business logic, database queries, validation, and error handling — was written in single files. One API endpoint file was 2,400 lines long. Adding a new feature meant understanding 2,400 lines of interleaved code, finding the right place to insert new logic, and hoping the change did not break something else.
Impact: Every new feature required reading and understanding large amounts of unrelated code. This is why features took progressively longer — the codebase became harder to navigate with every addition.
Problem 2: No database migrations
Database schema changes were made directly on the staging database. There was no version-controlled migration history. This meant:
- The production database schema might differ from staging (and nobody could verify)
- New developers could not set up a local database from scratch
- Rolling back a schema change was impossible
Impact: Database-related features required manual coordination and carried high risk of production incidents.
Problem 3: No automated testing
Zero tests. No unit tests, no integration tests, no end-to-end tests. Every code change required manual testing of the entire application because there was no way to verify that existing features still worked after a change.
Impact: Developers were afraid to refactor because they could not verify they had not broken anything. This led to adding code on top of bad code rather than fixing the underlying structure.
Problem 4: Hardcoded configuration
API keys, database credentials, and business logic constants were hardcoded throughout the codebase. Changing a billing rate required finding and updating 7 different files.
Impact: Configuration changes were risky and time-consuming. Moving between environments (local, staging, production) was manual.
The Verdict
The architecture was not salvageable as-is, but it did not need a complete rewrite. The core data model was sound. The business logic was correct (just poorly organized). The problem was structural, not functional.
Rewrite option: Start over with clean architecture. Cost: $180K-$220K. Timeline: 4-5 months. Risk: High (starting from zero while competitors advance).
Remediation option: Incrementally refactor the existing codebase while continuing feature delivery. Cost: $30K-$40K over 6 weeks. Timeline: 6 weeks (with reduced feature velocity). Risk: Low (working software throughout).
We recommended remediation.
The Remediation Plan
Week 1-2: Foundation
Database migrations:
- Installed migration framework (Prisma)
- Reverse-engineered existing schema into migration files
- Verified staging and production schemas matched
- All future schema changes through version-controlled migrations
Environment configuration:
- Extracted all hardcoded values into environment variables
- Created .env.example with all required variables
- Documented each configuration value's purpose
CI/CD pipeline:
- Set up automated build and test pipeline
- Added linting and formatting rules
- Automated deployment to staging
Time spent: 40 developer-hours Feature work this sprint: Reduced by 40% (still shipping, just less)
Week 3-4: Structural Refactoring
Service layer extraction:
- Moved business logic from API endpoint files into dedicated service modules
- Created clear interfaces between API layer and business logic
- Each service handles one domain (patients, billing, scheduling)
Database query layer:
- Extracted database queries from business logic into repository modules
- Added connection pooling and query optimization
- Created reusable query patterns
Time spent: 60 developer-hours Feature work this sprint: Reduced by 30%
Week 5-6: Testing and Stabilization
Automated testing:
- Added integration tests for all critical user flows (registration, patient creation, billing)
- Added unit tests for business logic services
- Set up pre-merge test gate (no code merges without passing tests)
- Test coverage on critical paths: 65%
Code review process:
- Established mandatory code review for all changes
- Created coding standards document
- Set review turnaround SLA (8 hours)
Time spent: 50 developer-hours Feature work this sprint: Reduced by 20% (nearly back to normal)
The Results
Immediate Impact (Week 7+)
| Metric | Before Remediation | After Remediation | Change |
|---|---|---|---|
| Average feature delivery time | 2.5 weeks | 1.2 weeks | -52% |
| Bug rate per sprint | 8-12 | 2-3 | -75% |
| Developer confidence (self-reported) | "Afraid to change things" | "Confident in making changes" | Qualitative |
| Time to add a new API endpoint | 2-3 days | 4-6 hours | -80% |
Business Impact
- Runway preserved: $200K not spent on a rewrite = 3.5 additional months of runway
- Feature delivery accelerated: Product roadmap back on track within 8 weeks
- Investor confidence: Technical assessment report became part of the next fundraising package
- Team morale: Developers went from frustrated to productive
Cost Comparison
| Approach | Cost | Timeline | Risk |
|---|---|---|---|
| Full rewrite | $200K+ | 4-5 months | High (starting over) |
| Incremental remediation | $35K | 6 weeks | Low (working product throughout) |
| Do nothing | $0 now, $300K+ later | Eventual forced rewrite | Very high |
Key Lessons
1. Early Detection Saves Money
The founders noticed velocity declining at month 3. If they had waited until month 6 (common), the codebase would have been twice as large and remediation would have been more expensive. Early assessment = cheaper fix.
2. Not Every Problem Requires a Rewrite
The agency's code was not wrong — it was poorly organized. The business logic was correct. The data model was sound. What was missing was structure. Refactoring is almost always cheaper than rewriting.
3. Non-Technical Founders Need Technical Representation
The founders could not evaluate whether "the product is getting more complex, this is normal" was true. A fractional CTO gave them the technical judgment to distinguish normal complexity from architectural failure.
4. Process Prevents Recurrence
Adding tests, code review, and CI/CD was not just about the current fix — it was about preventing the same problems from recurring. Process investment has compounding returns.
5. The Agency Was Not Malicious
The agency developers were competent individually. What was missing was architectural leadership — someone with the experience to set up the project structure correctly from the start. This is the exact gap a fractional CTO fills.