Agents build what the ticket meant, the first time.
KaaS Spec installs spec driven development in your repo for product and engineering teams. An agent drafts each spec from the ticket, with acceptance checks written before any code.
Run by the founder, a former Head of Software Engineering.
Filed by the PM
Acme Inc
Add saved cards to checkout
The agent, the reviewer and QA will each fill in the rest differently.
Drafted by an agent, sharpened by the PM
Acme Inc
Add saved cards to checkout
Goal
Returning customers pay with a saved card without typing it again.
Pulled from shared context
Payments decision recordCurrent checkout flowCard data rule: store the provider’s token, never the number
Acceptance checks, written before the code
Saved cards show for returning customersA removed card never comes backThe card number never reaches our database, only the provider’s tokenCheckout without a saved card works as it does today
Out of scope
Saving cards from the account pageChanging the payment provider
Built against its checks
Acme Inc
Add saved cards to checkout
Acceptance checks
Saved cards show for returning customersA removed card never comes backThe card number never reaches our database, only the provider’s tokenCheckout without a saved card works as it does today
Who approves
The PM approves the spec. The engineering lead approves the change.
A one line ticket gets read three different ways.
The agent builds fast. It just builds its own reading of the ticket, and so does everyone after it.
From the ticket alone
The ticketAdd saved cards to checkout
- The agentStores the card number so it can show the last four digits.
- The reviewerReads the diff for style, because there is nothing to check it against.
- QATests that a saved card appears, and never tests removing one.
Each guess is reasonable on its own. Together they mean the work comes back, usually after review, sometimes after release.
From one approved spec
- The agent
- The reviewer
- QA
Approved spec
Add saved cards to checkout
The card number never reaches our database, only the provider’s tokenA removed card never comes backSaved cards show for returning customers
KaaS Spec gives all three readers one approved spec in the repo, with its checks, before the agent starts.
What changes when work starts from a spec
Each role gets something it can approve or build against.
Product managers approve a draft.
An agent reads the ticket and shared context and writes the first version, so the PM never starts from a blank page.
Engineers build from an approved spec and its checks.
The agent works from the spec in the repo, and the chat thread stops being the source of truth.
Engineering leads approve against agreed checks.
Each check was written as something a test can prove, before the code existed.
A bad agent run touches nothing shared.
Agents build from the approved spec in sandboxes in your cloud.
Every change starts from a spec your team approved.
The agent, the reviewer and QA all check the same list.
How KaaS Spec goes in
We set it up next to the people who will write and approve the specs.
Agree the spec format.
We write it with your PM and engineering lead: goal, context, acceptance checks, out of scope and who approves.
You hold the format in specs/.
Draft from a real ticket.
The spec drafting agent turns one ticket from your backlog into a draft, and your PM sharpens it.
You hold the first approved spec.
Build in a sandbox.
An agent builds against the spec’s checks in your cloud.
You hold a change that passed checks agreed before the code existed.
“You work with the person who does the work. No handoff, no juniors, no account manager.”
Paramanantham HarrisonFounder, KaaS.team
- Former Head of Software Engineering
- 14 years building production software
Questions teams ask before they book
What is spec driven development?
It means writing down what a change must do, and how you will know it works, before an agent writes any code. The spec is what the agent and the reviewer work from.
How is a spec different from a ticket or a prompt?
A ticket says what someone wants. A spec adds the goal, the context the agent needs, acceptance checks, what is out of scope and who approves. A prompt is gone after the session; the spec stays in the repo.
Does this slow the PM down?
Less than you would think. An agent drafts the first version from the ticket and shared context, and the PM edits a draft rather than writing from nothing.
Which coding agents does KaaS Spec work with?
The ones your engineers already use, including Claude Code. The spec format is plain files, so any agent that reads the repo can use it.
Where does it run?
The spec format lives in your repo and the agent sandboxes run in your cloud account. Nothing is hosted by us.
Does KaaS Spec need KaaS Context?
No, but they work well together. With Context installed, the drafted spec pulls in your recorded decisions and existing code instead of leaving them for the PM to find.
Who is KaaS Spec for?
Teams whose agent work comes back because the ticket meant something else, whose PMs and engineers argue about scope after the code exists, and who want specs in their repo.
Who is KaaS Spec not for?
Teams whose tickets are already written as specs with checks, teams where nobody on the product side will own approving specs, and teams that do not use coding agents yet.
What stays with us?
specs/, the spec format and every spec your team writes in it. The spec drafting agent, the command that turns a ticket into a first draft. Agent sandboxes, the isolated environments in your cloud where agents build from a spec.
How does it fit with the other KaaS solutions?
KaaS Spec is the Ticket stop of the five KaaS solutions. See how all five fit together.
What is fixed before we start
Fit check first. If we're not the right team, we'll say so on the call.
You get a written scope and a fixed quote before anything starts.
Everything we install stays in your cloud and your repo when we finish.
The Care Plan is optional, and stopping it changes nothing that already works.
Bring us the bottleneck.
A 30 minute call with the founder about where work is stuck.
- Spec
- Build
- Review
- Release
- Where work is stuck
- Spec, build, review or release: wherever changes wait longest.
- What exists today
- The AI tools your teams use and the rules around them, if any.
- What the next quarter needs
- The launch or deadline the work has to hit.
- 1
Call
We find where the work waits and whether we can help.
- 2
Fixed scope
You get a written scope and a fixed quote before anything starts.
- 3
Kickoff
Work starts with your product and engineering leads.
If we're not the right fit, we'll say so.
Pick a time
Open the calendar and choose any free slot. You get an invite with a video link.