I made an AI tool that tells you exactly what an engineer will get wrong about your ticket before they build it
Hey IH — just launched Specc today.
The problem: every time a founder or PM translates a customer call into a ticket, something gets lost. An engineer makes a silent assumption, and two weeks later, you've built the wrong thing.
Specc runs three AI agents in sequence:
Ingestion — turns messy transcripts, support threads, or Slack dumps into a structured developer-ready ticket
Ambiguity detection — flags every assumption that would cause an engineer to build the wrong thing before the sprint starts
Outcome tracking — after you ship, it tells you whether what you built actually solved the customer's problem
Tested it on a real support thread where a customer mentioned £180k of renewal at risk. The agent caught that the team had descoped the one feature the customer needed for renewal before anyone noticed.
Would love feedback from anyone who's shipped the wrong thing because a ticket was too vague.
speccapp.com
Nice idea. I like that it focuses on the gap between customer language and developer assumptions. That problem happens a lot in product work.
I’m also building tools for creators and website owners, and one thing I keep noticing is that a clear workflow often matters more than adding more AI features. The ambiguity detection part sounds especially useful.
The ticket translation problem is real and the cost is brutal. I have lost more weeks at Henson Group to "we built exactly what the ticket said" than I want to count. The actual problem is rarely the engineer being careless. It is that the ticket writer is missing context the engineer needs and does not know to ask for.
Two product thoughts after reading this:
The ambiguity detection is the magic. Ingestion of transcripts into tickets is being commoditized fast (every PM tool will have this in 6 months). Outcome tracking is good but lags by weeks. The middle layer, flagging assumptions before sprint start, is where the actual cost reduction lives. Lead with that in your messaging, not "ingest transcripts."
The buyer is the head of product or VP engineering, not the founder. Founders feel this pain but rarely pay for tools to solve it. They blame execution. VPs who got burned twice on the same kind of miscommunication are who pull out the credit card. Talk to people who have authorized engineering rework write offs. They will sell themselves on Specc.
One question: what does retention look like when a team uses Specc for a release where they happen to have a great spec writer? Tools that catch "dumb mistakes" often get cancelled the month after the user has a good sprint. The pricing and value framing has to account for that.
Two things jumped out at me:
Your question on retention is the one that’s haunting me now. I get why the ‘good sprint’ cancellation concern is valid. The only thought I have is that the value has to be tied to the dataset. Every time you run something, it adds to your catalogue of historical misses from your team, so even if you have a good sprint, you’re still training the system. I don’t know how sticky that is, though.
What would make you feel comfortable that a tool like this wouldn’t churn after 3 successful sprints in a row?
Yep, this is the part that usually breaks. The handoff from call notes to a ticket is where all the little assumptions get lost, and the engineer ends up rebuilding the wrong shape of the problem. I’ve found it helps to keep the raw wording from the customer call right next to the structured ticket, not buried in a summary. That’s one reason I built DictaFlow, to get the rough thought down fast before it gets cleaned up and flattened.
This is a real problem.
The expensive mistakes usually aren’t engineering mistakes, they’re assumption mistakes that get baked in early and nobody notices until much later.
The bit I’d question is whether teams trust AI enough at that stage to challenge human assumptions, especially if the PM already thinks the ticket is clear.
Feels like adoption is as much a workflow / trust problem as a technical one.
You have solved the hardest part of the problem. Usually, the PM authoring an ambiguous ticket doesn't realise it's ambiguous. That's what makes it perilous. We try to make asking these questions about ambiguity feel more like a checklist and less like someone challenging the PM's decision. The language doesn't say 'your ticket is bad', it says 'here are five questions your engineer will silently ask themselves when they read your ticket if you don't answer them upfront.' Very semantics, but that changes it from threat to tool. Early days still, but that's our adoption wedge so far
Tried the product a bit and I think the most interesting challenge here is actually the first emotional reaction after signup.
The dashboard looks clean and structured, but the core value of the product is very high stakes:
“you’re about to build the wrong thing.”
Right now, the empty state feels a bit too calm for that.
I almost wonder if the first session should immediately show:
Because the value really clicks when you feel the risk, not just when you read the workflow.
Curious whether you’ve tested more example-driven onboarding yet.
The product is clearly tackling a big, real problem. If you don't mind sharing, I'm genuinely curious: what was the most memorable wrong assumption an engineer made about a ticket that eventually led you to start building Spec?
This is precisely the feedback that morphs the product — thank you for taking the time to write.
You nailed it on why people don’t activate. The empty state is way too zen for what Specc is actually telling you, "you're about to build the wrong thing". I’m resolving this today — new users will instead start on a real transcript pre-populated, so the first thing they see is the product actually working vs a blank input staring back at them waiting for you to imagine value.
On the origin story — I was in the middle of a client call with Oxford University for a recruiting tool I was building myself. I was taking notes with pen and paper, trying my best to write down everything they were telling me... For the call wrap, I had 2 pages of scribbles that I had to translate into something the computer could understand and build.
Half of what I wrote made sense in the meeting, but none of it made sense to me 2 hours later when I sat down to build. What I ended up building was technically correct but completely wrong. Not because we screwed anything up — because the message got lost in translation from what Oxford told me > what I scribbled down > what I actually built, and there was no second set of eyes to validate.
This is where Specc was born. I realised this wasn’t a communication problem. There was a translation layer missing. Really appreciate you giving it a shot and sharing your thoughts. If you’ve experienced similar frustration, I invite you to share your story or feedback about what you’re building. Would love to know what you're building and whether you've felt this same pain in your own workflow
Thank you for sharing that — your Oxford story is exactly the kind of moment that separates 'technically correct' from 'actually useful.' And the fact that you're already resolving the empty state today says a lot about how fast you move. This translation layer you described — between what's said, what's written down, and what gets built — is something I see across a lot of early-stage products, not just in ticket tools. It's that gap where assumptions creep in and nobody validates them before it's too late.
I actually specialize in helping founders find and close those gaps — specifically in onboarding and first-session flows — before they burn through early users who don't come back.
If you'd find it useful, I can take a closer look at the Spec flow once the new changes are live and record a 15-minute video breaking down where a new user still hesitates and what might increase activation. This is a paid audit ($150), but it sounds like you're at exactly the stage where getting that external clarity could save you months of guessing.
Either way — really glad to see how fast you turned feedback into action. Let me know if this sounds useful — happy to jump on it once the new onboarding is live.
This is stronger than “AI for tickets.”
The real product is preventing requirement drift before it becomes wasted engineering time.
That’s a much more serious category than ticket cleanup.
Specc is clear, but it still feels slightly lightweight for the problem you’re solving. If this expands into pre-build validation, sprint risk, and customer-outcome tracking, the name may start feeling too narrow.
A sharper infrastructure-style name like Davoq.com or Exirra.com would carry that direction better.