Making a prototype to test an idea

You have an idea: a simpler goods request form for warehouse staff, a training sign-up page, or a small spreadsheet that works out duty rosters. In the past, showing such an idea meant writing a long document or waiting for the IT team. Now AI can make you a prototype: a clickable page, a mock form or a small spreadsheet, often in an afternoon.

A good prototype starts from one question, not a feature list. For example: "Can warehouse staff fill in this form without explanation?" or "Does this sign-up sequence make sense to participants?". That question decides what needs to be built and, more importantly, what does not. To answer the first, you need a convincing form; you do not need data storage, user accounts or reports.

It works in stages like a long document. Ask for the simplest version first: one page, one file, with made-up sample data. Open it, try it yourself, then ask for changes one at a time ("move the submit button to the bottom", "add a carton unit option"). Then show it to three to five people who will use it, ask them to try without your explanation, and note where they get stuck. Those notes are the real output of the prototype, not the file.

One rule is not negotiable: a prototype uses sample data. Made-up names, codes and figures. A prototype is built fast and without proper safeguards; if real data goes in, it can end up stored somewhere unclear, sent to the model, or visible to anyone who opens the file.

A successful prototype often triggers the request: "Great, can we use it from Monday?". This is where many problems start. A prototype that looks finished is not necessarily ready for people. A ready app needs things you do not see on screen:

• Access and accounts: who may sign in, and who may see whose data.
• Storage and backup: where data is kept, how it is backed up, and whether it can be restored when broken.
• Security and data protection: secret keys are not baked into the code, and personal data is processed in line with the PDP Law.
• Testing and a real build: not just "it opens on my laptop", but built and tested the same way it will run in use.
• An owner: someone who fixes it when it breaks, six months from now.

So the answer is: a prototype is used to decide, then handed over to someone who can build it properly, or thrown away. If you want to learn to build apps all the way to ready-for-use, that is Level 3 of InfraLoka Academy.

The part most often skipped is testing with people. A prototype only you have tried proves only that you, its maker, know how to use it. Treat this test as a small evaluation: prepare the same two or three tasks for each person ("request five cartons of tape for the back warehouse"), then stay quiet and watch. Note where they stop, what they ask and what they click first. Then change your prompt or request to the AI based on those notes, not on your own taste. Two or three rounds like this are usually enough to know whether the idea is worth continuing, needs a new direction, or should stop.