What we need before we build a prototype

A prototype should answer a question, not merely prove that code can be written.

That changes what we need from you at the start. We do not need a long technical specification. We do not need every future feature settled. We do not need you to translate the work into software language before speaking with us.

We need enough truth about the work to build a small version that can be judged honestly.

Here is what that means in practice.

The problem in your own words

Start with what is happening now.

Tell us which task takes too long, where customers get stuck, what staff keep copying between systems, or which question has become difficult to answer. Describe the work as the people doing it would describe it. The awkward details matter more than polished terminology.

A useful starting point might be a routine request that arrives by email and gets copied into several places. It might be a website visitor who cannot find the information needed to make a decision. It might be a policy question that requires someone to search through a folder and decide which document is current.

We are listening for the boundary of the problem. Who encounters it, what sets it in motion, what happens next, and where does judgment enter the process?

That is enough to begin shaping a prototype.

Representative material

A prototype becomes useful when it works with material that resembles the real job.

For a website, that may be the actual copy, photographs, menu, service list, or contact information. For an internal tool, it may be a sample spreadsheet, a blank form, or a few ordinary records with sensitive details removed. For an AI workflow, it may be a small set of approved documents and examples of the questions people actually ask.

The material does not have to be tidy. In fact, a carefully cleaned sample can hide the exceptions that decide whether the idea works. We would rather see an ordinary example, including the parts that cause trouble.

We do not need every record you hold. We need enough representative material to learn whether the proposed approach handles the real shape of the work.

Sensitive information should be treated deliberately. If a useful test can be run with redacted or invented records that preserve the same structure, we should start there. Access to production data should never be the price of an early conversation.

The person who knows where the work bends

Every process has a written version and an experienced version.

The written version says which steps happen in order. The experienced version knows which customer requests need special handling, which fields people routinely leave blank, which policy has an exception, and which apparent shortcut creates more work later.

We need access to someone who knows that second version.

That does not require weeks of meetings. It means having a person who can answer concrete questions when the prototype reaches an edge case. Depending on the work, that may be an owner, an office manager, a front desk employee, a subject specialist, or the person everyone already asks when the process goes wrong.

Without that perspective, a prototype can look convincing while solving an imaginary version of the job.

A decision the prototype should support

Before we build, we should agree on what you need to learn.

Perhaps you need to know whether customers can understand a new service from the homepage. Perhaps staff need to see whether one screen could replace a spreadsheet and a group text. Perhaps an AI system needs to show that it can answer from approved material, cite the source, and admit when the answer is uncertain.

The question should be narrow enough that the prototype can answer it.

"Can this replace everything?" is too broad. "Can a staff member process this common request without copying the same details twice?" is useful. The second question points to a task we can observe and a result you can inspect.

A clear decision also prevents the prototype from becoming a small project with no finish line. We are not trying to squeeze the final system into an early proof. We are trying to learn enough to decide what deserves to be built next.

An honest test

A prototype is valuable only if the test resembles the decision you will make.

That means agreeing in advance on what you will inspect. Can a person complete the task? Is the supporting source visible? Does the uncertain case reach a human? Can the page be understood on a phone? Does the workflow preserve the information the next person needs?

The test should include an ordinary case and at least one inconvenient case. A system that works only when every input is perfect has not yet proved much.

This is also where we name what the prototype will not establish. An early version may show that the workflow is sound without proving how it performs at full scale. It may demonstrate the customer path without carrying every page of the eventual site. It may test an answer against approved documents without connecting to the live system of record.

Those limits are not defects when they are explicit. They keep the result interpretable.

What you do not need to bring

You do not need to arrive with the technology chosen.

You do not need wireframes, a feature inventory, or a document written in technical language. You do not need to know whether the answer is a website, an internal tool, an integration, or an AI workflow. Choosing the mechanism before understanding the work often makes the project harder.

Bring the problem, the material, the person who knows the exceptions, and the decision the prototype should support.

If the project is a fit, we can turn those inputs into a working version you can inspect before you pay. You can judge the thing itself, identify what is missing, and decide whether the next step is worth taking.

That is the point of starting small. Not to avoid the difficult parts, but to find them while the decision is still easy to change.