SatoriXR
Delivery got faster with AI-assisted development and the constraint moved to deciding. They hired a second product manager, not a third developer, and the narrative and roadmap became the queue the developers pull from.
Spec-driven development
Adopt spec-driven development with the team you have
The spec is written before the agent builds. Feature1 is where it gets written, from your product strategy down to acceptance criteria your coding agent reads over MCP.
Spec-driven development (SDD) is the practice of writing what a change must do before any code is generated, then having the agent build to that spec and a person verify against it. Most teams get the spec half right: a file in the repository that describes the feature. What is missing is where the feature came from. Feature1 holds that: the strategy, the roadmap, the features and the acceptance criteria, and serves them to Claude Code, Codex or Cursor as the spec.
The POC: your PM, your developer, read-only GitHub access, two features shipped spec-first in one to two weeks.
Sound familiar?
- Your developers use AI, but the business is not seeing the benefit.
- Features ship fast, and so do unintended changes.
- Each change fixes one thing and bends the shape of the product.
- Shipping got faster. No metric moved.
- You want spec-driven development without a course, a migration, or a new tool for the developers.
- The spec exists, but nobody can say which customer or which goal it serves.
What spec-driven development gets right, and what it leaves out
SDD as the tools describe it
- Write a specification, a plan and tasks before the agent writes code.
- Keep the spec in the repository, next to the code it describes.
- Let the agent build from the spec, then review against it.
- Tools: GitHub Spec Kit, OpenSpec, Kiro, and a growing set of community extensions.
The part a repository cannot hold
- Why this feature and not the twenty others in the backlog.
- Which customer it is for and which product capability it changes.
- What the product can already do, so the spec does not re-describe it.
- What happened after it shipped: adoption, errors, the next decision.
Feature1 is the layer above the repository. The strategy, the roadmap and the acceptance criteria live there, and the agent reads them over MCP. Your repository workflow stays as it is.
How a feature becomes a spec in Feature1
Direction
A one-page product strategy narrative: where you win, for whom, the strengths to build on. Written, so it can be checked against.
Product reality
Feature1 reads the repository, read-only, and keeps a picture of what the product can do today, capability by capability.
The gap, as a roadmap
The difference between the direction and the product, as initiatives with an objective and a measure each.
Features, stories, acceptance criteria
Each initiative is planned into features and user stories with acceptance criteria before anyone opens an editor. This is the spec.
The agent builds from it
Claude Code, Codex or Cursor reads the story and its criteria from Feature1 through MCP and builds what was meant, with far fewer product questions.
A person verifies, reality updates
Your developer reviews the pull request against the criteria. When it merges, the capability picture updates and the next decision starts from what is true now.
What it looked like in three teams
Quantem
A junior developer with almost no context built an MCP layer in one day from written acceptance criteria, and it passed end-to-end testing. Four to five days of context work against one day of building.
Jarshare
A Replit store with one unintegrated server file became a real product once the capabilities were written down and the next features were specified against them.
Paid proof of concept
Adopt SDD on two real features. $500.
A fixed-scope proof of concept with your own PM and developer. You see spec-driven development working on your product, with your coding agent, before you change anything else.
You give
- One product manager, or the founder who decides what gets built
- One developer with a coding agent (Claude Code, Codex or Cursor)
- GitHub access, read-only. Feature1 reads the repository and never writes to it
- An NDA, signed before anything is read
You get, in one to two weeks
- A one-page product strategy narrative
- A roadmap built on what the product can already do
- Two features shipped by your developer and their agent, from acceptance criteria held in Feature1 and read over MCP
- Your team working spec-first, without a course or a migration
$500Flat. Paid once the scope is agreed on the call.Book the POC callOr sign up and start on your own, free
Abdulrahman, founder of Feature1, runs the POC with your team. He does not write the code. Your developer does, with the agent, which is the point: the process has to work with the people you have.
Questions people ask
What is spec-driven development?
Writing what a change must do before any code is generated, having the coding agent build to that specification, and verifying the result against it. The spec becomes the source of truth for the build instead of a prompt.
Do we have to replace Spec Kit or our repository workflow?
No. Spec Kit and similar tools organise the spec, plan and tasks inside the repository. Feature1 sits above that: it is where the strategy, roadmap and acceptance criteria are decided and held, and it serves them to the agent over MCP. Keep the repository workflow you have.
Which coding agents does this work with?
Claude Code, Codex, Cursor and any MCP-compatible agent. They read features, stories and acceptance criteria from Feature1 through its MCP endpoint.
What does read-only GitHub access mean?
Feature1 reads the repository to understand what the product can do today. It never writes to it. Your developer and their agent write the code; the pull request is theirs.
What is in the $500 POC?
One to two weeks with your PM and one developer: a product strategy narrative, a roadmap built on what the product already does, and two features shipped from acceptance criteria held in Feature1. An NDA is signed before anything is read.
Is there a free way to start?
Yes. Sign up, no credit card, and write the first Product Strategy Narrative yourself. The POC is for teams that want it done with them, on their product, in a fixed window.
Write the spec where the decisions are.
Two features, your team, one to two weeks. Or sign up and write the first narrative yourself, free.