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
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
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.