Full-stack prototype
When the prototype needs a database
Most presale demos are a front end pretending. This one had to survive a login, an upload and a restart — so I built the backend too.
- State survives a restart, which mocked demos do not
- Real persistenceState survives a restart, which mocked demos do not
- The prototype produces a document, not a preview image
- Generated outputThe prototype produces a document, not a preview image
- Session handling in the demo, because access is the first question asked
- Auth on the doorSession handling in the demo, because access is the first question asked
The client
A document-heavy operation evaluating contract and document management with AI extraction — the kind of buyer who asks what happens to the file after the demo closes the tab.
The engagement
A full-stack prototype with persistence and authentication, built where a front-end mock would have collapsed under the first real question.
A working demo of this build exists.
It is not public yet — ask for access, and where the NDA allows I will send a link or walk you through it on a call.
The problem
A front-end-only prototype is cheap and right most of the time. It becomes wrong the moment the buyer's real question is about the boring half — where does the document live, who sees it, does it survive, and what comes out at the end. At that point the demo either has a backend or it has an apology.
What I did
I chose the expensive option deliberately and only where it earned itself. Authentication, persistence and generation went in because those were the three questions this audience would ask; everything else stayed as simple as it could be. Ingestion covers the formats that actually arrive in a document operation, including spreadsheets, because a pipeline that handles only clean text is a pipeline that handles nothing. Validation sits at the boundary with a typed schema so malformed input fails visibly rather than corrupting a record quietly. And the output is a generated document rather than a rendering, because the deliverable of a document system is a document — the demo should end where the user's job ends.
What was built
A prototype with a real server behind it: authenticated sessions, file upload with a raised body limit for real documents, parsing across the common office formats, model-based analysis, document generation as output, a relational database behind a typed schema, and schema-driven validation at the boundary.
On the table at the end
- Full-stack prototype with authentication and persistence
- Ingestion across common office formats including spreadsheets
- Model-based analysis and generated document output
- Database schema with seed data and a push-and-seed workflow
What it changed
Answered the questions a mocked prototype cannot: where the document goes, who can see it, what survives a restart, and what the system produces at the end — a generated document, not a screenshot.
How it ran
- 01
Decide what has to be real
Authentication, persistence and generation built properly; everything else kept as thin as it could be.
- 02
Ingest the formats that arrive
Documents, text files and spreadsheets, because real document operations are not uniformly clean text.
- 03
Validate at the boundary
A typed schema at the edge so bad input fails loudly instead of writing a quietly corrupt record.
- 04
Finish with a document
Generated output rather than a preview, so the demo ends where the user's actual task ends.
- 05
Make it reproducible
Schema push and seed as one command, so anyone can stand the demo up without the person who built it.
Other work
All case studies →- Telecommunications
Every clause gets a human verdict
Contract review is the most demoed AI use case in the enterprise and the least trusted. I built the version where the model proposes a redline and a lawyer accepts, edits or rejects each one.
- Delivery operations
A knowledge pipeline that pages someone
Every organisation has a knowledge base nobody reads. I built the version that reads itself, notices a slipping deadline or a budget breach, and messages a person — and exposes the same data to the assistant in the editor.
- E-commerce
Reading the money path first
A small commerce platform was days from taking real payments. I reviewed the trust boundaries before the features and found an order that could mark itself paid.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.