ExistBefore
IT

Founder

How to protect a prototype before presenting it to the market

A prototype is the moment when an idea becomes concrete and visible. Consequently, it is also the most delicate moment: you show it, let people test it, and pitch it. Before taking it out into the world, prepare a clear version, document it, and lock it in time.

4 min read

1. How it usually happens

A prototype is born quickly: a working demo, a web app, an interactive mockup, a physical device, an AI model that finally "responds well". The team is thrilled and immediately tempted to show it to everyone: investors, clients, advisors, friends "in the industry".

Then the iterations begin. Someone asks for a tweak, someone suggests a feature, someone proposes a different use case. The prototype changes rapidly, sometimes even within the same week.

A typical anecdote: a founder presents a prototype at a trade show. They showcase a "still experimental" feature, explaining it won't be part of the final product. Months later, a potential partner remembers that exact feature as the core proposition. The problem isn't what was said, but what was perceived.

Another common scenario involves testing with users or early adopters. You send out a prototype version, then update some parts "on the fly". Before long, three or four different versions are circulating, with no clear trace of who saw what.

A less obvious perspective: a prototype isn't just code or design; it's also choices. Workflows, priorities, logic, compromises. Two prototypes might look similar but differ substantially in internal workings or user experience. Documenting these differences avoids confusion about what was actually ready and what was merely a trial.

Finally, the prototype is often the first asset to leave the team's "total control". It gets shown, copied, photographed, recorded. At that point, having a precise snapshot of what existed before the presentation is crucial.

2. What you need to prove

The goal is to prove the existence and content of the prototype in a specific version, before exposing it to the market.

It can be useful to prove:

  • the existence of the prototype in a certain version;
  • its actual functioning at the time of presentation;
  • included and excluded features;
  • graphic appearance and user experience;
  • the content of demos, pitches, or presentations;
  • differences between subsequent versions;
  • what was shown to investors, clients, or partners;
  • the prototype's access or usage conditions;
  • any stated limitations;
  • the chronological sequence of presentations.

In practice, you must be able to say: "this was the prototype, in this format, when I presented it".

3. What to collect

You need a package representing the prototype fully and comprehensibly, even years later.

Collect:

  • source code or prototype export;
  • build or executable version;
  • screenshots of main screens;
  • demo videos showing how it functions;
  • mockups, wireframes, or design systems;
  • technical or functional documentation;
  • the pitch deck used to present it;
  • notes on included and excluded features;
  • changelog or modifications list;
  • emails and chats regarding prototype sharing;
  • invites to demos, events, or presentations;
  • any written feedback received;
  • recordings of demos or calls, if available;
  • README file describing the prototype;
  • any terms of use or limitations.

A helpful tip: record a video while using the prototype. Showing real behaviour is often more effective than describing it.

4. How to proceed

Before presenting the prototype, create a "snapshotted" and closed version. It doesn't need to be perfect; it needs to be clear.

Organise a dedicated folder for the prototype version, with a name and date. Insert code, builds, screenshots, videos, and documentation. Add a README explaining what it does, what it doesn't do, and its current state.

Practical procedure:

  • identify the prototype version to be presented;
  • gather code, builds, and visual materials;
  • take screenshots and record a video demo;
  • write a README with descriptions and limitations;
  • organise everything in an orderly structure;
  • create a ZIP archive of the version;
  • certify the main package;
  • keep an unmodified internal copy;
  • log who you show the prototype to and when;
  • save communications and received feedback.

If the prototype evolves post-presentation, create a new version. Avoid silently updating the already shared one.

5. Mistakes to avoid

Many issues arise from overly informal prototype management.

Common mistakes:

  • failing to save a version prior to presentation;
  • modifying the prototype without version tracking;
  • showcasing undocumented features;
  • not distinguishing between demo and actual product;
  • not retaining presentation materials;
  • using generic file names like final_demo;
  • failing to log what was shown to whom;
  • relying purely on verbal explanations;
  • losing screenshots or videos of the original prototype.

Besides technical certification, adopting simple habits is useful: versioning, minimal documentation, tidy archiving, and post-demo summaries. Free certification is useful because it allows you to quickly secure a prototype version before exposure, without slowing down the team.

6. After the documentation

After documenting the prototype, keep working in versions. Every major evolution should have a new documented "snapshot".

Share versions internally with the team, so everyone knows what was shown externally. If you get feedback, link it to the specific prototype version.

If doubts or disputes emerge, clear documentation lets you easily reconstruct what was presented and in what form. In a startup's journey, the prototype is one of the first times the idea becomes visible: treating it methodically from the outset avoids much confusion as the project scales.