Build a purchase approval app by describing it.
Who asked for what, who has to approve it, and how much got signed off this month. Here's the prompt and the app it produced.
Ask for it in one go
This is the exact prompt we used. Copy it, change the words that don't match your business, and paste it in.
We need purchase requests. Someone raises a request with a description, a supplier, an amount and a cost centre. It goes from submitted to approved or rejected. Only managers can approve or reject. Show me everything still waiting for approval, and the total approved this month.
Built in 46 seconds, from that prompt alone.
What came back
Money totalled, not just counted
Pending value and approved-this-month value are sums rather than record counts, which is the difference between a queue and something a finance person will look at.
Approval as a permission
Submitted, approved and rejected, with approving restricted to managers. Somebody who is not a manager does not see the button, and the rule holds through the API.
A queue that shows what is stuck
Waiting for approval is the first table on the page, because it is the only thing anyone opens this app to look at.
Purchase approvals are usually email. Somebody asks, a manager replies “fine”, and the only record is in two inboxes. It works until finance asks what was committed last month, or somebody approves something they should not have, and there is nothing to point at.
The app that fixes it is genuinely small. A request, an amount, a status, and a rule about who is allowed to move it. The value is not the form. It is that the answer to “what did we approve” stops being a search through email.
It totalled the money without being asked
The prompt asks to see what is waiting and the total approved this month. What came back put value next to volume: four requests pending, worth 12,085, and 24,700 approved this month. That is a small thing and it is the difference between a queue for the person raising requests and a dashboard for the person paying for them.
Nothing needed fixing here
Worth saying plainly, because three of the other apps we built this way did need a correction. Nothing on this dashboard is measured against today’s date, so the sample data could not land in the wrong place. Counts and sums are always right regardless of when the data was generated.
The pattern is clear enough to plan around. If your app has expiry dates, renewal dates or due dates in it, budget one follow-up message to move the sample data into the present. If it counts and totals, it will come out right first time.
Summary
A purchase request app is a form, a status and a permission, which is why it is so often left as email. This one took 46 seconds from a paragraph, arrived with money totalled as well as counted, and needed no corrections at all. If you want budgets per cost centre, quotes attached, or requesters restricted to their own records, those are the next three sentences.
Then change it by asking
The assistant stays with the app after it is built. It proposes each change and a person approves it, so nothing moves on its own.
- Add a budget per cost centre and show how much of it is committed.
- Requesters should only see their own requests.
- Let people attach a quote to the request.
- Give me approved spend by supplier for the last quarter.
Frequently asked.
Can we require a second approval over a certain amount?
Yes, by asking for it. Conditional rules are part of the platform, so a request over a threshold can require another step. We left it out of the prompt deliberately to keep the example to one paragraph.
Does this connect to our accounting system?
Not directly. Every app ships a REST API with an OpenAPI 3.0 spec and outbound webhooks, so a developer can push approved requests into your finance system. There are no prebuilt accounting integrations.
This one needed no corrections. Why?
Because nothing on the dashboard is measured against today's date. The panels count records and sum amounts. The use cases that need a follow-up message are the ones with expiry or due dates in them, where sample data can land in the past.
Can requesters see each other's requests?
By default everyone with access sees the register. Ask for it to be restricted and each person sees only their own, enforced at the data layer rather than hidden in the interface.
What does it cost?
Snill is free to start for solo operators, with a Pro plan for teams. Your data and the app's full model are yours to export at any time, as CSV or JSON.
Describe it and see
Free to start. The app is generated in about a minute, and you keep changing it in plain language.
Start free