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?
Really relatable problem.
Scope creep always starts small, but it quietly messes with sprint plans and margins over time. Curious how you're handling the messy cases where intent and wording don’t match up.
That’s the ultimate edge case. A client saying 'we can think about this later' vs. 'let's make sure this is ready for Tuesday' represents a massive shift in real intent.
In the V2 architecture, I’m solving this by splitting the logic into a sequential two-pass pipeline. Pass 1 strictly extracts the raw request events (primed for phrases like 'while you're in there'). Pass 2 passes those clean arrays alongside the explicit contract markdown blocks to evaluate the semantic boundary. It isolates the real intent from the conversational noise remarkably well.
Making scope visible in real time is what changes behavior. People adapt quickly when ambiguity has an immediate cost.
Exactly. When ambiguity is free, clients optimize for ambiguity. The second you introduce an automated, highly transparent delta report right after a call showing them the exact structural variance against their contract baseline, the psychological dynamic shifts completely. It moves the conversation from an awkward personal confrontation to a clean, data-backed commercial reality
This is the core of the problem. Process discipline always fails because manual logging feels like an extra chore at the exact moment you're already mentally drained from a client call.
I’ve been building Trackly around this exact behavioral bottleneck. What we've seen is that if you don't automate the data ingress completely in the background, the compliance rate drops to zero. People would rather lose billable hours than deal with the friction of tracking them.
Shaun's approach of capturing it at the transcript level is smart, but I'm curious how you guys see the balance between background automation (like passive tracking) versus forcing team discipline?
Love what you're building with Trackly!! Manual logging is a dead end because human friction scales faster than operational discipline. If tracking a 15-minute 'favor' takes 10 minutes of mental admin, people will choose revenue leakage every single time.
For me, background automation wins completely. The goal for V2 is a zero-UI defensive middleware, so it connects directly to their existing Fathom or Otter webhooks, runs the contract evaluation entirely in the background, and drops a completed change-order draft into Slack/Notion without the team changing a single habit.
The 15 unbilled hours stat is brutal but familiar. What stands out is the insight that fighting scope creep through process discipline alone never works because the human cost of logging scope changes exceeds the pain of just doing the extra work. Automating the detection at the transcript level removes that friction decision entirely. The really interesting question is how clients react when they start getting auto-generated change order emails right after calls. Do they push back faster, or do they learn to scope better upfront because the cost of vagueness becomes immediately visible?
100% - you've hit the exact behavioral bottleneck I’m trying to solve. Most agency process discipline fails because human friction scales faster than operational intent. If it takes 10 minutes of manual workflow tracking to document a 15-minute 'small favor,' the developer or PM will just eat the cost every single time. Removing that 'friction decision' entirely at the data ingress layer is the core thesis of the V2 build.
Your question about the client psychology loop is exactly the thesis I’m testing right now with my early cohort.
From what I’m seeing, it acts as a soft behavioral forcing function. When vagueness is free that's ok - clients optimize for vagueness. But when a casual 'while you're in there' instantly generates a highly specific delta report against the initial contract baseline, it changes the dynamic and just makes the commercial reality of a request visible in real-time.
Just sent you a connection request on LinkedIn - would love to jump on a quick chat and share some of the early raw data loops we're seeing on this as the beta rolls out!
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.