Build a returns and RMA app by describing it.
What has been authorised, what is still to arrive, and the reasons behind it all. 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.
Handle customer returns. A customer requests a return against an order, giving the product, the quantity and a reason like faulty or wrong item or changed their mind. We issue a return number, and the return goes from requested to authorised to received to refunded or replaced or rejected. Only a supervisor can reject one. Show me returns waiting to be received and the reasons people are returning things.
Built in 48 seconds, from that prompt alone.
What came back
Six connected collections
Returns, Return Reasons, Orders, Products and Customers, plus the activity log. A return points at a real order and a real product rather than repeating their details as text.
Reasons as data, not a comment
Faulty, wrong item and changed their mind became records, which is the only way the question that matters gets answered. Why are people returning this product?
A six-state lifecycle
Requested, authorised, received, refunded, replaced, rejected. Refunded and replaced are different outcomes with different costs, and the app keeps them apart.
Returns are where a tidy operation goes soft. The sale is in one system, the refund is in another, and the physical box is on a shelf that somebody will deal with. Ask why customers returned things last month and the honest answer is usually a guess.
What fixes it is a register with the reason treated as data rather than a note. Everything else follows from that.
The reason is the whole point
We listed three reasons in passing and it made Return Reasons a collection. That single decision turns the app from a count into an argument.
Faulty, wrong item and changed their mind are three completely different businesses. The first is a product problem, the second is a picking problem, the third is a listing problem. A register that files all three as “returned” cannot tell you which one you have, and that is the only thing you actually wanted to know.
What we had to fix
Two metrics read zero on the first build. No sample return was sitting authorised but unreceived, and none had been requested in the last seven days, so both panels the prompt asked for were empty.
One message fixed it. We described the state we wanted, the assistant proposed the changes, and we approved them. Afterwards the warehouse view showed three awaiting receipt.
The pattern is worth knowing. It is not only dates. Any panel that depends on records sitting in a particular state at a particular moment can come out empty on generated data, and it takes a sentence to fix.
Summary
A returns register is a lifecycle and a reason, and the reason is what makes it worth building rather than tolerating. This took 48 seconds from a paragraph, with reasons as data, orders and products as real lookups, and six states kept apart. Two metrics needed one correction. If you want refund amounts, split permissions for the warehouse, or return rates per product, 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 the refund amount and total it by reason.
- Let warehouse staff mark returns received but not refund them.
- Add a photo of the fault to each return request.
- Give me return rate by product for the last quarter.
Frequently asked.
Why keep reasons as their own collection?
Because the reason is the value. A returns register that only tells you how many came back is an accounting exercise. One that tells you eleven of them were the same fault on the same product is a product decision.
Does it connect to our webshop?
Not directly. Every app ships a REST API with an OpenAPI 3.0 spec and outbound webhooks, so a developer can push return requests in from a store. There are no prebuilt ecommerce integrations.
What did you have to fix?
Two dashboard metrics read zero on the first build, because no sample return was both authorised and unreceived, and none had been requested in the last week. One message fixed both. Worth expecting on anything where a panel depends on records being in a particular state at a particular time.
Can the customer see the status of their return?
No. This is an internal register. Customer-facing status means external access, which is a bigger decision than it sounds and worth thinking through on its own rather than bolting on.
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