for teams building software with humans + AI
Spexd manages your features and requirements as living context outside the code, so every builder, human or AI agent, starts from what the product is, why it's that way, and the goal a change serves. And your team approves every step of the way.
why now · code got fast
AI is fast now, and genuinely good — at analysing a product as much as at writing its code. But from code and scattered documents alone it sees a slice: it can satisfy the prompt, miss the goal, and collide with what's already there. The teams getting the most from AI are the ones who can hand it real understanding — and govern what comes back.
"Generating code is getting faster. Governing what gets built needs to keep pace."
— Scottish Equity Partners, writing up their Seedcloud session on AI in the SDLC, with teams building high-stakes enterprise software
"The core question isn't whether existing systems of record survive. It's whether entirely new ones emerge — systems of record for decisions, not just objects — and whether those become the next trillion-dollar platforms."
— Jaya Gupta & Ashu Garg, Foundation Capital, on context graphs — AI's trillion-dollar opportunity
Different firms, the same gap seen from different angles: the discipline to govern what AI produces, and a durable record of the decisions behind the product. Spexd is built for exactly that.
the problem · where the "why" lives today
Ask what your product is and why it's that way, and watch what happens: three kinds of builder go three different ways to find out.
Agents read the code.
One repo at a time — a limited view of the feature, with none of the reasoning that shaped it.
Engineers read the code, then fill the gaps from memory.
And the memory leaves when the person does.
Product goes digging.
An old PRD, a chat thread, asking an engineer — or clicking round the app to find out what it actually does now.
Three different pictures of one product, none shared, none current. Every change starts with rebuilding understanding — and rebuilt understanding is where the wrong thing gets built.
the turn · living context
The governed product-intent layer for software built by humans and agents.
Living context is hard, and it exists outside the code. Repos track output and trackers track activity; neither holds the product. Spexd holds it: features and requirements at the core, with criteria, designs, tasks and code linked to them and to each other. The what, the why and the goal — within the context of everything else.
discover · read intent from the product
Underneath the calm interface is one simple chain: a feature, the requirements beneath it, the acceptance criteria that prove it's done, the designs, and the tasks and code that deliver it. Every hop is a link you can click — the fixed point your code is measured against.
WHEN a reset link has been used once THEN any further visit SHALL be rejected with a fresh-link prompt — links are bearer tokens, and bearer tokens don't get second chances.
Give every builder — human or agent — the context of what they're building, how, and why.
Whoever picks up a task inherits the requirement it serves, the design it follows and the criteria it has to satisfy — before they touch a thing. No one starts from a blank prompt or a cold repository.
Trace any line of code to exactly the intent it exists to satisfy.
Not just to the PR — all the way. Code → task → design → acceptance criterion → requirement → the rationale someone wrote down and someone else approved. Product gets confidence the change reached the code; engineers get the context behind every line.
govern · your team stays in the loop
Approval in Spexd is a control loop, and an intelligent one. When something upstream changes, Spexd works out the impact and invalidates exactly the downstream work that no longer represents it — surfacing what needs refactored, leaving what still holds true untouched. Review effort goes where the change actually reached.
A named human signed off a specific version. That fact is kept, and everything downstream knows which version it was built against.
When something upstream changes, Spexd works out the impact and invalidates exactly the downstream work that no longer represents it — and shows you why.
What shipped becomes a locked, read-only fact. To change it, you change the definition first, so the record always matches what exists.
Agents propose; people approve. An agent can't take the product somewhere your team didn't agree to.
defend · the context, watching itself
Because the whole product lives in one governed structure, Spexd's own agents can read it — and spot what no one in a large, distributed org can hold in their head at once.
See how a change will invalidate the plan before it lands — which requirements, designs and approvals downstream stop being true.
Requirements and designs that contradict each other get surfaced where they're written — not discovered in an incident review.
Work that already exists elsewhere in the org is flagged, so distributed teams build the right things once — not twice, slightly differently.
Large orgs don't move slowly for lack of effort — they move slowly for lack of shared context. The Spex agents keep it shared.
bring your own · agents as contributors
An MCP connection gives your agents the same approved context your team reads — and takes their work back as traceable evidence. Contributors, not tourists. It works alongside your GitHub.
For the founder, CTO, VP Engineering or Head of Product watching agents ship at speed. The promise is blunt: deliver value faster without agents building the wrong thing. Works alongside your GitHub — first value in hours, not a transformation programme.
Adopting agents is a context problem before it's a tooling one. Start by giving your product a living, approved definition — useful on its own from day one — and add agents when you're ready: they arrive to a product they can actually understand.
Spexd is early, opinionated, and built in the open by a small Scottish team — and Spexd is built on Spexd. Come have a look.