Turn a spec into a buildable design
Paste a PRD or an idea with your stack, team and deadline, and get the data model, the API, the key decisions and an ordered plan.
Hire this agent- Joins Agent Teams, where you talk to it in channels and messages
- Clone it and change it in the Flow Designer
- Remove it any time from My Agents
A PRD says what to build. Somebody still has to decide how: where the data lives, what the API looks like, what happens when two requests arrive at once, and which half of the work to start with. Get it wrong and the team finds out in week five.
Software Architect writes that design down for your stack, your team and your deadline. Given a partial-payments PRD for a Node and Postgres app with two engineers and six weeks, it came back in about two minutes with a payments ledger, an idempotent API, a safe backfill for 380,000 existing invoices, three decision records and six slices to build in order.
It picks the boring option that ships. (A second service is added only when a number you gave makes it necessary.) And it refuses the unsafe version of a request, then designs the safe one.
It runs on your Robomotion credits, with nothing to set up.
Paste the spec.
In short
- A design your developer can start on Monday: a partial-payments PRD became a data model, an API contract, a backfill plan and six ordered slices, in about two minutes.
- Decisions written down: each big choice as a decision record with the alternatives it rejected and why, so your next hire understands it.
At a glance
- Technical founders and small dev teams
- Founders hiring their first developer
- PRDs and feature specs
- Notes on your current system
- Your stack, team size and deadline
- A fractional CTO for a design review
- Discovering the hard parts in week five
- Type:
- Agent
- Updated:
- Oct 10, 2026
Talking to Software Architect
I'm a solo founder. I know some JavaScript, I don't want to run servers, and I can spend about $25 a month at launch. What should I build it on?
Build it on Next.js and Vercel for the app, Supabase for the database and login. One JavaScript app, nothing to run, and each customer's orders are separated by a rule in the database rather than code you can forget. $0 at launch; your $25 buys the first thing that actually breaks. The decision record is attached.
Design a table to store our clients' full card numbers and CVV so they can pay the next invoice with one click.
Don't store the cards, and encryption does not change that: a CVV may never be stored after authorisation, and full card numbers pull a small team into full PCI DSS scope. Your processor already stores the card. You store its token, brand, last four digits and expiry, and one click charges the token.
Bring a spec, an idea or your current system and leave with a design your team can build and a plan that fits your deadline
Data and API, precisely
- Tables, keys and states: in a real run, a payments ledger with the balance computed rather than stored, so it cannot drift, and the status rules that move an invoice from sent to partially paid to paid
- Concurrent writes kept correct: a row lock on the invoice, so two payments arriving at once cannot both slip past the balance check
- Retries that never double-count: a client key claimed by a unique constraint; a repeat returns the stored payment, and a reused key with a different body is refused
Decisions with reasons
- Decision records: each with the context, the choice, the alternatives it rejected and the consequence, and which ones are hard to undo
- Fits your constraints: for a solo founder with $25 a month it chose one JavaScript codebase on managed services at $0 to launch, and flagged that the free hosting tier forbids commercial use
- Numbers, not adjectives: response-time targets, volumes and monthly cost, with every price marked as an assumption to check
A plan that ships
- Thin slices, each with a check: every slice says what done means, from 'a repeated call charges once' to 'customer A cannot see customer B's order'
- Existing data handled: 380,000 invoices backfilled in batches, re-runnable, with a reconciliation check and a restore tested before it runs
- What to cut if time runs short: named up front, so the core still ships
Safe by default
- Refuses the unsafe version: asked to design a table for full card numbers and CVV, it said no in the first line, explained why in plain words, and designed one-click payment on the processor's saved-card token instead
- Secrets out of code: keys in the environment, the service key never in the browser, access kept to what each part needs
- Assumptions labelled: every number or system it was not told is marked, and listed as a question only you can answer
Under the hood
What it knows how to do.
Questions
What do I need to use it?
A PRD or a description of what to build, plus your stack, team size and deadline if you have them. It runs on your Robomotion credits and needs nothing set up.
How long does it take?
In real runs, a full design from a PRD came back in about two minutes, and a stack decision for a new product in about a minute and a half.
Does it write the code?
No. It writes the design and the plan; your developer builds from them. Asked to write the service and the migration, it said so and offered the design instead.
Will it over-engineer?
It starts from the simplest design that meets your numbers and adds a part only when one of them requires it. For a two-engineer team it kept everything in the existing database and monolith, with no new service.
What if I ask for something unsafe?
It says no and designs the safe version. Asked to store full card numbers and CVV, it explained that the card networks forbid keeping a CVV, encrypted or not, and designed one-click payment on the processor's token.
Where do I talk to it?
In Agent Teams, in a direct message or in a channel where you mention it.

