THE CHECKLIST
Ten things to check before your prototype meets real users.
None of these needs to become a six-month enterprise programme. The point is to make the important risks visible, put sensible foundations in place and leave you able to keep shipping.
Product analytics
Can you see what users actually do inside the product, not just whether the site is online? A pilot should tell you which features are used, where people get stuck and whether your core journey is working. We usually get founders set up with leading SaaS tools for this, for example PostHog for product analytics, so you can learn from real behaviour without building a reporting system from scratch.
Safe delivery pipeline
Can you test changes before they go live, then release them without crossing your fingers? A production-ready app needs a place to try changes safely, a clear path from idea to release and automatic checks that run before anything reaches customers. For most founder-built prototypes, that means staging, preview environments, basic continuous integration and a release process that makes shipping feel routine instead of tense.
Data location and jurisdiction
Do you know where your app runs and where your database lives? Defaults can be surprisingly important here. On a recent client project, the app was executing in a Vercel data centre near Washington DC while the database was hosted in Frankfurt. That meant customer data was being processed outside the EU, and every request had to cross the Atlantic before it could talk to the database. Moving both app and database to London made the product faster and made the data story much easier to explain to UK prospects.
Third-party data handling
Do your analytics, AI, email, payments, storage and support tools process data in the right region? The major vendors often have EU or UK-friendly hosting options, but prototypes tend to inherit the quickest default. Before a pilot, it is worth checking every tool that receives customer information. You may not need to change vendors, but you do need to know what is being sent where, and whether your settings match the commitments you want to make.
Privacy and access control
Can the wrong person see, edit or export the wrong data? This is one of the places vibe-coded prototypes most often look fine on the surface. A button may be hidden in the interface, but the underlying request may still be possible if someone knows how to ask for it. Real access control belongs on the server and in the database, where it can be checked consistently and tested automatically.
Customer data separation
If your product serves multiple customers, is each customer’s data properly isolated? This matters as soon as you have organisations, teams, clients, tenants or accounts sharing the same system. The test is simple to state and serious to prove: one customer should never be able to reach another customer’s data, even by changing a URL, replaying a request or asking the database in an unexpected way.
Automated test coverage
Are the important journeys protected against accidental breakage? You do not need tests for everything, especially before a pilot, but you do need tests around the behaviour that would damage trust if it broke. That usually means login, permissions, billing, core workflows, data changes and the features founders keep asking AI tools to modify. Good tests are not bureaucracy. They are what lets you keep moving.
Error handling and recovery
What happens when something fails? A production-ready product should handle broken payments, slow AI responses, failed emails, missing data and service outages without leaving users confused or corrupting important records. The goal is not to prevent every failure. It is to make sure common failures are expected, explained and recoverable.
Observability and alerts
Will you know when the product is misbehaving before a customer tells you? Tools like Sentry, structured logs, health checks and alerts turn vague reports into problems you can diagnose and fix. They also change how you appear to customers. Instead of waiting for someone to complain, you can say, we spotted an issue, we understand the impact and we are already working on it. That is a very different conversation.
AI delivery harness
Does your AI coding setup understand the product, the rules and the release process? Paradoxically, many vibe-coded codebases do not contain good instructions for the AI tools that created them. A proper harness gives Claude Code or similar tools a product map, non-conflicting rules, useful skills, relevant MCP servers, review checks and release boundaries. It helps you keep the founder speed while making the next round of feature work much less chaotic.
PROTOTYPE → PILOT
You do not need to slow down. You do need stronger rails.
Appified helps founders turn TypeScript, React, Next.js, Vercel and Supabase prototypes into products that are ready for real users. In 6–8 weeks, we put the practical foundations in place: safer data, better visibility, staging, tests, measured performance improvements and an AI delivery harness so you can keep shipping with more confidence.