From Fractional CTO to Micro-SaaS: How 15 Unbilled Hours Inspired an AI Shield (And What the Data Says About V2)
Hey everyone,
I’ve spent the last several years acting as a fractional CTO and technical consultant for early-stage startups and boutique software agencies. My job was never just about mapping system architecture or optimizing query performance. Thats because a massive part of it was protecting developer velocity and preventing burn-out.
But over the last year, I noticed a recurring, exhausting bottleneck that was actively draining our margins: unpaid scope creep. That means risks, lots of them.
You all know the exact drill. You’re on a weekly sync call with a client, and they casually drop a line like: “Oh, this looks great, but can we just add a quick login page...and social logins too maybe?” or “Can we add one more simple analytics page?”
It sounds small to the client, and project managers usually nod along to keep the relationship friendly. But behind the scenes, that "quick minor tweak" completely derails your sprint planning. Suddenly, your senior developers are staying up until midnight writing custom auth setups, managing token expirations, and dealing with unexpected edge cases - and all for zero billable hours.
--The Breaking Point--
A few months ago, I watched one of my dev teams absorb roughly 15 unbilled hours across a single two-week sprint just trying to accommodate a cascade of these "casual requests" that were never in the original Statement of Work (SOW).
For a lean shop, the administrative friction of manually downloading a Zoom recording, transcribing it, comparing it line-by-line against a PDF contract, and drafting a formal impact statement for a 2-hour addition feels too heavy. The overhead kills the motivation, so teams let it slide.
To fix this, I automated the boundary lines. Under my independent project banner, I built a raw V1 app:
- Drop the raw sync call transcript and the signed SOW baseline into a backend text-processing pipeline.
- The system diffs the text, flags scope anomalies, extracts open client-side dependencies, and automatically generates an objective, polite change-order follow-up email.
I pushed the barebones V1 live to get some early feedback. Also ran a raw workflow pulse check on a small cohort of active operators to see if the problem was unique to my teams. The data was glaring:
100% of respondents are actively running client-facing services (Agencies, Consulting, Dev Shops).
83.3% explicitly state that managing manual operational workflows and tracking deliverables is a recurring friction point.
66.7% report losing critical hours every single week purely to administrative drag and unlogged, unbilled client work.
It was clear - they don't want another bloated dashboard to manage. because they are already fatigued by tool fragmentation. The primary friction isn't processing the data, it's the manual step of having to remember to copy-paste data into a tool after an exhausting client call.
--The Engineering Roadmap for V2--
Because the UI is currently a barebones, unpolished V1 (I've attached a raw screenshot of the results output layout), the survey insights mean I'm skipping cosmetic updates to focus entirely on infrastructure and integration architecture for V2:
Moving away from manual transcript uploads. I'm looking at setting up direct webhook receivers or native integrations (Slack/Notion/Zapier) so a call log is automatically parsed the second a meeting ends.
Tuning the underlying prompt structures to better differentiate between a client giving constructive feedback on an existing feature vs. sneaking in a completely brand-new feature request.
I'm keeping the core V1 workspace completely free right now because I'm focused heavily on refining the parsing accuracy and understanding data workflows across different agency niches before thinking about a monetization layer.
For the SaaS builders and agency operators here: How are you currently protecting your teams from silent scope creep risk? Do you manually log every change order, or have you built an internal automation stack to handle the paperwork?
The V2 roadmap is the right call, the parsing accuracy and trigger automation are where this lives or dies. A few things from building similar pipelines for client projects that might save you cycles.
For the webhook receivers, the cleanest shape I've found is a thin ingress service that normalizes the payload before it hits your diff engine. Zoom, Fathom, Otter, Granola, Fireflies, Read.ai all hand you transcripts in subtly different schemas with different speaker labels and timestamp formats. If your diff logic has to handle that variance, you'll spend more time on adapter code than on the actual SOW comparison. A normalize-then-route layer keeps the core logic clean and lets you add new sources in a day instead of a week.
For the prompt tuning around "constructive feedback vs new feature request", that distinction is brutal to nail with a single classifier prompt because the same sentence can be either depending on what's in the SOW. The pattern that worked for me on a similar client diff job was a two-pass approach. First pass extracts every actionable item from the transcript with no judgment about whether it's in scope. Second pass takes each item and checks it against the SOW with the SOW chunks loaded as context. Lets you tune the two halves independently and your false positive rate drops a lot because you stop asking the model to do two reasoning steps at once.
The other thing worth thinking about early is how the SOW gets parsed. If you're letting clients drop in a signed PDF, the diff is only as good as the structure you extract from that PDF. Most SOWs are written in inconsistent prose with deliverables buried in paragraphs. Forcing some structure at ingestion (or letting the agency annotate sections once) saves you from the model hallucinating scope items that aren't actually there. Built something similar last year and the SOW-to-structured-spec step was the unlock, not the comparison step.
How are you handling the case where the client request is in scope but the implementation effort is way higher than the SOW assumed? That's the trickier flag than pure scope creep imo.
This is incredibly gold-tier feedback, man. Saving me a massive amount of cycles here.
Spot on regarding the thin normalization layer for ingestion. I was looking at the differences between Fathom and Otter payloads earlier, and you're 100% right; trying to write adapter logic directly inside the comparison engine would quickly become an absolute maintenance nightmare. A strict normalize-then-route schema is definitely the play for the V2 ingress pipeline.
Your two-pass approach for prompt tuning makes perfect sense, too. Isolating raw entity extraction from semantic boundary evaluation completely offloads the cognitive weight from a single prompt. It’s exactly how I’m structuring the multi-agent orchestration—using a lightweight model to strictly output clean JSON events of actionable items first, then passing that array to a heavier reasoning layer alongside the SOW chunks.
You also hit the nail on the head regarding the contract vault. Comparison is relatively easy; turning loose, inconsistent SOW prose into a reliable, structured vector baseline without hallucination is the real structural hurdle. Forcing a structured spec confirmation on ingestion is a stellar safeguard.
As for your question on effort inflation within open-ended scope items, yeah that’s the ultimate edge case. The plan for the evaluation layer is to flag these as a 'Complexity/Effort Variance Risk' rather than pure scope creep, tracking the implied scale of the conversational request against the initial parameters.
Really appreciate you dropping these battle-tested insights!
I think the biggest shift here is that you're treating scope creep as a workflow problem rather than a documentation problem. Most teams already know how to write change orders—they just don't do it because the effort comes at exactly the moment everyone's mentally done with the meeting. Removing that step entirely feels like a much stronger lever than making the paperwork itself easier.
Spot on. You actually articulated the core thesis better than I did.
That 'mentally done with the meeting' window is exactly where the leak happens. So if a tool forces an operator to log into a separate dashboard, upload a file, and configure settings right after a intense 60-minute alignment call, it has already lost the battle against human friction. The compliance rate is 0.
That’s exactly why the survey data pushed me away from building a prettier UI and straight into thinking about async headless ingress for V2. The ideal workflow shouldn't require an action, i.e. the system should just intercept the transcript via a webhook the second the call terminates, run the diff in the background, and drop the draft where the team already lives (like a Slack notification or a pending email draft).
Appreciate the validation on this. It completely confirms that automating the trigger is infinitely more important than simplifying the document creation itself
That's exactly what I was curious about.
Reading your reply, I think there's one strategic business decision sitting underneath that shift which I don't think is obvious yet, but I don't think I can do the reasoning behind it justice in a thread.
I'd be interested to unpack it properly if you think it's worth exploring.
What's the best email to reach you?
Hey man, sure no worries. You can reach me at [email protected] :)
Just sent it over by email.
Looking forward to hearing your thoughts once you've had a chance to read it.