PROTOCOL — PROTO-01
MVP and prototype development. One useful first version.
I work with founders, agencies, and SaaS teams across Canada from Winnipeg, Manitoba. Start with the question your first version needs to answer: will someone use it, can the integration work, or will a buyer pay? That decides whether you need a prototype or a usable MVP.
PROTO-01-SPEC
The spec, on one sheet.
A short scoping pass, then something testable. Here is who the protocol is for, what comes out, and how the run ends. Every run ends the same way the bench does: with a verdict.
| Protocol |
PROTO-01 — Prototype Sprint |
| Best for |
Agencies with client tool opportunities · SaaS teams testing a wedge · Founders needing proof for customers or investors |
| Output |
Working prototype or high-fidelity surface · Core user flow and screens · Demo data · Loom walkthrough · Next-build roadmap |
| Decision |
Kill it, refine it, pilot it, or productize it — logged either way |
the artifact is the deliverable. the deck is not.
PROTO-01-02
What the sprint produces
A focused product artifact that can be demoed, tested, sold, or used to decide the next milestone.
Clickable or working prototype
Technical notes
Basic auth or integration where needed
Roadmap for the next build cycle
PROTO-01-03
Prototype or MVP? Pick the right finish line.
A prototype helps you test a flow or technical assumption; it may use sample data and manual steps. An MVP serves real users through a deliberately narrow workflow. If customers will sign in, pay, or store business data, those responsibilities must be included in the scope. A polished demo alone does not establish production readiness.
One primary user
One end-to-end job
Named assumptions
Written acceptance criteria
PROTO-01-04
The first conversation should shrink the build.
Bring a sketch, an existing app, a spreadsheet, or a rough description. We identify the buyer, the action they need to complete, the systems involved, and the evidence that would justify another build cycle. Features that do not help test that question belong in the next-phase list. We agree the estimate, milestones, and handoff before implementation.
Scope and exclusions
Integration risks
Review milestones
Cost and timing assumptions
PROTO-01-05
Know what happens after the demo.
The handoff should identify the code repository, deployment accounts, configuration, known limitations, and next steps. Hosting, model usage, third-party subscriptions, ongoing support, and a later production build need explicit treatment in the agreement. For a paid MVP, the acceptance checklist also needs real account permissions, failure handling, and an owner for incidents.
Account ownership
Deployment notes
Known limitations
Support scope
PROTO-01-XREF
Pick the protocol that matches the decision you need.
Prepare before you commission.