Written by the team behind AIOTFY (Aiotfy Pty Ltd, Adelaide).
A clickable prototype is not a miniature production system. It is a bounded answer to one product question. Founders get into trouble when the quote is vague about what "done" means, who owns the files, and which extras are out of scope. This article turns those boundaries into a checklist you can reuse before you sign.
Start from the question, not the stack
A useful prototype answers a single learning goal, for example:
- Will people complete the first task without help?
- Does one AI-assisted step actually change the decision a user makes?
- Can an internal team finish a pilot workflow end to end?
If the goal is unclear, the build becomes a grab-bag of features. Scope documents should name the question in plain language before they name frameworks. Stack choices matter later. They do not rescue an undefined question.
Write the question so a stranger can falsify it. "Make onboarding nicer" is not falsifiable. "Can a new user invite one teammate and create one project in under ten minutes without chatting with us?" is falsifiable. The second sentence belongs in the quote.
What a written scope should lock
From how we describe prototype work publicly, a quote should define:
- The question the prototype must test.
- Features in scope, and a short exclusion list.
- Review rounds and sign-off points.
- Whether AI features are required for the question (use the simplest approach that answers it).
- What is not included unless the quote says so: hosting, third-party services, production hardening, and ongoing support.
Those five lines prevent most "we thought that was included" threads. If a stakeholder wants to add a feature mid-build, the scope should say whether that consumes a review round, extends the timeline, or needs a change order. Silence here creates free infinite revisions in practice even when nobody agreed to them.
IP and licences at hand-over
Ownership should be explicit:
- Once the prototype is delivered, intellectual property in that delivered prototype belongs to the client.
- Third-party and open-source components keep their own licences and should be listed in the hand-over note.
If you need an NDA before sharing sensitive material, agree it in writing before you send the material. Privacy of the idea is a process choice, not a slogan on a homepage.
Founders sometimes ask whether they "own the prompts" or "own the model." For most clickable prototypes the honest answer is narrower: you own the delivered application artefacts defined in the quote. Model providers and open-source libraries keep their terms. Put that in the hand-over note so finance and legal are not surprised later.
Timeline honesty
"How long does it take?" only has a real answer after scope exists. A timeline that is not tied to a written feature list is a wish. Ask for the timeline to travel with the quote, not as a separate marketing number.
Also ask what "done" means on the calendar: clickable on a staging URL, installed on your laptop, or accepted after a named review round? Those are different finish lines. Pick one in writing.
Prototype vs full product
A prototype and a live product need different security, hosting, and support. Carrying on to a full version is possible, but it should be scoped separately. Treating a clickable demo as production-ready is how teams inherit fragile auth, unpaid invoices for third-party APIs, and no monitoring.
A practical boundary language you can reuse:
- Prototype: enough fidelity to answer the learning question.
- Production: threat model, secrets handling, backups, uptime expectations, and support hours.
If marketing copy needs a public URL, say whether that URL is temporary demo hosting or a hardened launch. Do not let launch language rewrite the exclusions after the fact.
A hand-over pack checklist
When the build ends, founders should expect at least:
- The runnable or clickable prototype itself.
- Notes on components and licences.
- The final scope and which review round signed off.
- Clear statement of what was excluded (hosting, hardening, support) unless purchased.
If any of those four are missing, the engagement is not finished even if the UI looks polished. Add a fifth item when relevant: credentials and environment notes for whatever temporary hosting was in scope, plus a date when that hosting ends.
Who this shape of work fits
Publicly, this shape is aimed at solo founders validating an idea, small teams needing a first version to test one question, and businesses running an internal pilot with a defined goal. It is not a substitute for a multi-year platform program, a compliance rebuild, or an always-on retained product team.
If your real need is ongoing discovery across many bets, you may want a different engagement shape. A single prototype quote should not pretend to be that program.
What we refuse to pretend
- That every idea needs an AI feature.
- That a prototype quote silently includes production operations.
- That ownership can stay "flexible" after money changes hands.
- That a beautiful UI proves the learning question was answered.
Clear exclusions are kinder than optimistic scope. So is saying "we are not the right fit" when the ask is unbounded.
Closing
Own the question, the written scope, the IP statement, and the hand-over notes. Those artefacts matter more than which UI library shipped in week two.
If you want the service page this checklist mirrors: https://aiotfy.com/services/prototype-development?utm_source=devto&utm_medium=article&utm_campaign=geo_p1
