The demo works. Now real users need to use it. We review one important journey and organise the tasks for your launch: what needs finishing first and what can wait?
View the MVP launch check See a working exampleA new account is empty. An entry is missing. The connection drops. These cases show whether someone can continue without your help.
See the exampleIdentify the task your first users should complete independently. That determines what needs doing before launch.
A different stack becomes a useful suggestion only once it is clear which requirement the existing structure cannot meet.
Show errors, preserve entries and check a retry.
First observe which actions the test group actually repeats.
The core journey is usable with the existing design.
Five invited test participants need a different setup from paying customers. The check therefore begins with the intended use.
MVP launch checkWe examine the selected journey with empty data, invalid entries and interrupted transactions. The interface needs to explain what happened and how to continue.
In a web application, a server response alone does not establish success. The HTTP status also needs checking.
MDN: handle responses and errors with FetchIf your product summarises documents, it needs typical tasks and difficult counterexamples. What must the answer contain? What must the model not claim?
Include an empty document and two documents with conflicting information in preparation. Does the interface show an uncertain outcome or present a finished answer anyway? A deeper evaluation of model quality is separate work.
Can a second person start the project? Is deployment documented? Which services are required? These questions locate technical problems more precisely than a framework's name.
A possible switch must account for migration effort and later maintenance. A complete architecture or cost review has its own scope.
The launch check considers first use. The stack review addresses architecture and maintainability; the cost review examines ongoing expenditure.
Your prototype works in the demo. We review one user journey and identify what is missing before your next launch.
Do you really need a rebuild? We review an application's structure and explain what to keep or change.
Hosting, tools and ongoing services: we organise up to ten cost items and include the work involved in a possible switch.
Launch and stack reviews overlap on technical questions. If you request both, we define their respective scopes before the proposal.
Describe the next use of your prototype. That determines what needs checking before this start.
Will a supported test group start, or should new customers work independently? That determines the review scope.
What should someone complete in the prototype? State the task and starting condition, such as an empty account or existing data.
We agree a demo, materials or limited read access. Passwords and tokens do not belong in the enquiry form.
Tell us your preferred start date. We agree a possible review and delivery date. The board also identifies open questions outside the review scope.
Who will address the findings afterwards? Name the responsible product or development contact so questions and next tasks can be assigned.
Frontend optimisation fits a defined goal, such as understandable saving errors. After checking suitability, we work in a test environment or separate branch.
Handover includes a documented before-and-after test. Your team can see which behaviour changed and how to verify the correction.
An idea alone lacks a testable prototype. Penetration testing or legal review requires separate specialists.
Ask us for advice How a project worksYes. We assess the intended use. The chosen tool is neither a reason for a blanket rebuild nor proof of quality.
For first use, the launch check starts with one important journey. For architecture, maintainability and deployment questions, the stack review fits better. We clarify technical overlap before a combined project.
First describe what you built and who will use it. We agree the materials, demo and access needed for the review. Credentials do not belong in the enquiry.
No. The check delivers findings within the agreed scope. It does not replace penetration testing, legal review or a complete review of every line of code.
The check includes a launch board and one round of written follow-up questions. Your team can implement the tasks. Implementation by us is scoped as a separate project.
What you can prepare so a participant finds their way without your demo.
Prepare the prototype test
