How to prototype an internal tool before building it for real
Internal tools fail less often from bad code than from building the wrong thing: a stock tracker nobody updates, an approvals screen with the wrong steps. A cheap way to avoid that is to prototype an internal tool before building it, with fake data, and watch the people who'd use it try their real tasks. Only then decide what to build, and on what.
What a prototype is for
A prototype answers questions a specification can't. Do the warehouse team look up stock by product code or by shelf? Does the manager approve expenses one at a time or in a batch on Friday? Which three columns does anyone actually read? You learn these by watching someone use a screen that behaves like the real thing. It doesn't need real data, real accounts or a server; it needs the right screens and the right steps.
Prepare
- Pick one process, such as booking the meeting room, logging a returned item, or approving holiday. Not the whole department's work.
- Write down the steps people take today, including the spreadsheet, the email and the sticky note.
- Choose three to five testers who do the job now. Include at least one sceptic.
- Make realistic fake data. Twenty rows that look like your real products, customers or requests, with no real names, prices or account numbers.
Build the prototype
- Describe the tool in a sentence or two and paste in the steps you wrote down. Anticode treats a tool like this as an app: the model writes the whole program as one HTML document.
- Answer the Architect's questions and check the plan lists the screens you expect.
- Give it your fake data. The app runs in a strict sandbox with no network at all, so anything that would need a server, such as a shared database or a login, is simulated with sample data and labelled "Demo data". That label is useful here: nobody mistakes the prototype for the real system.
- Iterate with change requests. "Add a filter by shelf", "make the approve button ask for a reason". Each change takes a sentence.
- Publish it to its anticode.dev address for testing. It's public to anyone with the address, which is another reason to keep real data out.
One behaviour to explain to testers: the app saves to their own browser. If two people use it, they each see their own copy of the data. That's fine for testing the steps and the screens, and a good prompt for the real question of who needs to see whose entries.
Run the test sessions
Sit with each tester for twenty minutes, in person or on a screen share. Give them a task, not a tour: "A customer has returned two jackets, one damaged. Log it." Then stay quiet and take notes on where they hesitate, what they look for that isn't there, and what they ignore. Ask afterwards what they'd still do in the spreadsheet. Fix the obvious problems between sessions, so the next tester sees an improved version.
Client review links in Anticode show a page without running its scripts, so they suit a layout check on a page rather than clicking through an interactive app. For a prototype, share the published address in the session itself.
Decide what happens next
| What you learned | Next step |
|---|---|
| Nobody would use it, or the spreadsheet is fine | Stop. The prototype saved you a build. |
| The idea works and the data model is clear | Export it as a Next.js project and give it to a developer to connect real data, sign-in and permissions |
| The idea works but needs systems you already have | Hand the prototype and your session notes to whoever builds on that platform, as a living specification |
The Next.js export covers app builds and gives a developer a standard project with TypeScript, Postgres through Prisma, customer and staff roles, an audit log and row-level security. It has no Anticode runtime, so the real tool is theirs to host and maintain. See developer handoff with the Next.js export for how that handover goes.
Limits
The prototype can't connect to your company systems, share data between users, sign people in, or keep anything private: it's a public page with demo data. Don't type in real customer or staff details while testing. Turning it into a working internal tool is development work outside Anticode, with the export as a starting point. For other early-stage builds see the internal tool builder and AI prototype to production.
Questions people ask
Can the prototype use our real data?
No. Apps run with no network, so they can't reach your systems, and a published prototype is public. Use realistic fake data.
Can several testers share the same data?
No. Each person's entries are saved in their own browser. That's enough to test screens and steps.
How long should prototyping take?
A day to build and a week of short sessions is typical for one process. If it drags on, the question you're testing is probably too broad.
Can a developer continue from the prototype?
Yes. Export it as a Next.js project; the developer connects the real database and sign-in.