One sentence is a joke,
not a specification.
Every other AI app builder takes your one sentence and starts writing code. That works for a todo list. For anything a business actually runs, it produces something confident, demoable and quietly broken, and you find out in month four.
evibe interrogates first. Audit trails, approval thresholds, period close, record locking, segregation of duties, retention. The things a real system needs and a naive prompt never mentions, asked before a line of code exists.
Complex applications cannot be hand waved into existence. They need a reviewed specification and a data model. Once those are right, the code was never the hard part.
Sales order management
SampleAfter a forty minute working session.
Specification grade
Too much is undecided to build from.
66% decided, 69% of the questions worked through.
Version 4, in plain English
- +Added the concurrency rule on simultaneous order edits.
- +Changed customer deletion from blocked to closed status.
The questions your prompt left out
Claude has seen an enormous amount of enterprise software. It knows what a real sales order system needs. A consumer tool never asks any of this, because its users do not know to want it, and the omission does not show up until an auditor does.
After what event does an order lock, and is a correction an edit or a credit note?
Lifecycle and mutability
When a price changes in March, does February follow it or keep the old value?
Point in time correctness
Can the person who raised it also approve it?
Segregation of duties
Two people open the same record at once. Who wins, and does the other one find out?
Concurrency
What must be retained, for how long, and what happens to dependent records?
Deletion and retention
The approver is on leave and the credit check is down. What happens then?
Exception paths
How it works
- 1
Describe it badly
One sentence is a fine place to start. "A sales order system, we want to stop using the spreadsheet" is enough, and it is roughly what everybody types.
- 2
Get interrogated
Questions arrive in batches of three to five, with the reason they matter and what most businesses do. Tap an answer where the answer is bounded. "I do not know yet" is a real answer and lands in Open Questions instead of blocking you.
- 3
Leave with a document
Not a chat transcript. A specification with a data model, every business rule in plain English, and the gaps flagged where you can see them. Versioned, diffed in plain English, and it prints.
There is no question cap. The conversation runs until the detail is genuinely there, and evibe says when new questions have stopped changing the document rather than manufacturing more.
Enterprise grade. We mean the letter.
Your specification is marked the way a paper is marked, on the standard scale, and the mark is on screen the whole time. Sixteen requirement domains, weighted, because who may approve their own order matters more than the format of an order number.
Two numbers, and they are deliberately not the same. Coverage is how far through the questions you are. Rigor is how much is actually decided, and an open question counts half. Answer "I do not know" sixteen times and you are fully covered and failing, and the screen will say both.
A specification that pretends everything is settled is worse than one that flags its gaps. Ruling a domain out costs you nothing: deciding that period close does not apply to a room booking tool is work, not a hole.
Specification grade
Too much is undecided to build from.
66% decided, 69% of the questions worked through.
Two open questions, both written down, both naming what they block. That is what a good specification looks like at the end of a session.
What it works through
Not every domain applies to every application, and evibe judges which ones do rather than marching through a checklist. Asking about period close for a room booking tool is noise.
Today's process
What you do now, and where it breaks. The single most productive question, and the one no prompt ever answers.
Lifecycle and mutability
After what event does a record lock? Are corrections an edit, or an offsetting entry?
State transitions
Which statuses exist, which moves between them are legal, and who may make each one.
Audit and traceability
Who changed what, when, and whether the prior value has to survive.
Approvals
What needs sign off, at what threshold, by whom, and what happens to a rejection.
Roles and segregation of duties
The distinct roles, and anything one person must not do both halves of.
Point in time correctness
When a price, address or tax rate changes, do historical records follow it or keep the old value?
Deletion and retention
What can be deleted rather than deactivated, what must be kept, and for how long.
Concurrency
Two people open the same record at the same time. Who wins, and does the other one find out?
Exception paths
The credit check is down, the approver is on leave, the import file is malformed. Naive specifications describe only the happy path.
Numbering and identity
Human readable identifiers, whether they must be sequential, and whether gaps are allowed.
Workflow and hand-offs
Who does what next, where work waits, and who picks it up when nobody does.
Transaction boundaries
What must succeed or fail together. Half a posted order is worse than none, and nobody ever asks.
Currency and money
Rounding, precision, more than one currency, and which rate applied on the day.
Calendar and timezone
What a period is, and whose clock decides what date something happened on.
Integration and boundaries
What this reads from and writes to, and whether it is the system of record or a copy.
Migration and cutover
What comes across from the system you are replacing, in what shape, and on what day.
Notification and escalation
An approval threshold nobody is told about is a rule that never fires.
Reporting
What has to come out of it, who reads that, and how often.
Volume and performance
How many records, how many people at once, and what counts as too slow to use.
Scale and growth
What breaks at ten times the volume, and whether that is a problem for this year or the next one.
Usability and access
Who uses it, on what device, how often, and what they need when they cannot see the screen well.
The specification is the record, not the code
Code is derived and disposable. The document is what gets reviewed, versioned and argued over. Every material change writes a new version, and you can read the difference between any two of them in plain English rather than as a diff.
Every rule carries why it exists and whether you asked for it or accepted a suggestion. In six months the question you will actually have is "did I ask for this, or did I just nod", and nothing else in a document can answer it.
You never see implementation code. Not in the interface, not in an error message, not in the conversation.
A rule, as it is stored
An order cannot be edited once it is fulfilled. Corrections are made by raising a credit note against it.
The audit finding was that history had been edited. Editing a fulfilled order destroys the thing being audited.
Where this is today
evibe takes you to a specification good enough to hand to a developer. Generating the running application from it comes next, and it is deliberately not first: building the pipeline before the documents are trustworthy would only hide a bad document behind working code.
Start with the thing that is actually hard.
Enterprise grade. We mean the letter.