Your product is never finished. Knowing how best to evolve and adapt to changing customer needs is a skillset that is hard to hire, develop and cultivate. Yet lacking that skillset results in over-complicated solutions and repeated refactors.

Spexd is built to turn your agents into your Principals. Giving everyone in your team the ability to trade off within business decisions, interrogate requirements and develop imaginative solutions to your hardest problems.

Put your teams even closer to the business challenges, constraints and prior decisions with Spexd.

Join the waitlistSee it work ↓

One changed requirement reaches three designs in four codebases.

Priya talks to the fraud team, who have asked if we can shorten the refund window from 30 days to 14. Before anyone builds, Spexd judges every agreed design under REQ-21 and says, in a sentence, what the change does to each one.

She stages the change in a proposal, so production keeps running on the agreed version. The owner of each design updates it there and drafts the tasks it needs, someone else agrees both, and coding agents pick up the tasks once the proposal merges.

↑ A requirement change staged in PROP-3. Spexd says what the change does to each design it reaches and flags the one it conflicts with for a person to decide; every design and its tasks are agreed inside the proposal, and agents build only once it has merged.

Spexd reviews every pull request against the agreed design.

Spexd reviews your pull requests, highlights where they fall short of the agreed design, suggests a fix and links back to the requirement, the design and the decision behind them.

Your reviewers stop rebuilding the context before they can judge a change, and a gap is caught while the branch is still open, whichever agent or engineer wrote it.

↑ Spexd's review on a pull request a coding agent opened. The gaps name the criterion they miss, the fix is ready to apply, and the check clears on the next push.

Spexd keeps reviewing after the change ships.

Spexd judges every acceptance criterion and every design against the code each repository has deployed, and says what it read to reach each verdict.

When anything in the tree changes, from a requirement to a task an agent drafted, Spexd reviews it against its parent and leaves the feedback where its author will see it.

↑ REQ-21 after PROP-3 shipped. One criterion holds, one has no test, one is contradicted by a limit nobody wrote down and one was never built, one design has drifted, and a new task was caught before anyone built it.

Your agents check a change against the decisions behind it.

Any coding agent connected to Spexd over MCP reads the specification before it writes a line. When a request would break a regulation, a requirement or a decision your team already took, it says which one, links to it, and offers a way through.

Ana asks Claude Code: Store the customer's full card number on the order so refunds can go back in one click. The agent replies: I'd hold off. Storing full card numbers conflicts with REQ-9, card numbers never reach our systems, which is how you keep orders-api out of PCI DSS scope. You don't need them for refunds. Checkout already keeps the processor's payment token on the order (DES-14), and the processor refunds against that token. One-click refunds can call it directly. Want me to open a proposal that adds one-click refunds as a requirement, with the change to DES-14 it needs?

↑ Three requests to three different coding agents with Spexd connected. One is refused on a regulation, one needs a small change to a requirement, and one finds a route that keeps a regulation and two earlier decisions intact.

Ensure your decisions survive agents, acceleration and rapid change.

Join our waitlist to regain control of product and engineering change.

Built by Principal Engineers to support Principal teams.