Startup playbook
Are we ready for a Pilot?
Before moving from POC to Pilot, the company needs a data governance baseline. This is separate from technical governance. Technical governance asks who can deploy, who can access Azure and how the environment is built. Data governance asks what information the company collects, where it is stored, why it is allowed to hold it and how it protects it.
Useful for
Introduction
This has to be considered before Pilot because external users may start entering real information. Even if the Pilot is not Production, we have to assume that data entered into it may include personally identifiable information. That means GDPR requests have to be supported from the moment external users are involved.
Why this stage matters
A Pilot is different from a POC because external users may enter real data. Even if the product is still changing quickly, the governance stance has to assume that personal data, commercial data or customer-sensitive information may appear.
This gate exists because Pilot data creates real obligations. The company may need to support data subject requests, explain where data is stored, understand its Controller or Processor position and make honest promises to Pilot users.
The decision
The Pilot can start when the product can accept external use without the data protection, infrastructure and support position being fictional.
Data governance
Pilot data must be treated as real data. As soon as external users can enter information, the company has to assume that personal data, commercial data or customer-sensitive information may appear, even if the product is still described as a Pilot.
This does not mean every data protection process has to be fully automated. It does mean the company needs to know what data it collects, why it collects it, where it is stored, who processes it and how it would respond to basic GDPR requests.
Infrastructure
Pilot infrastructure is the point where the organisation starts to capture what the product needs to run. The POC may have been disposable, but the Pilot needs enough structure that workloads can be recreated and the team can explain how data is protected.
This is usually the right time to introduce Infrastructure as Code. The team should now understand enough about the resources required to start capturing them deliberately, especially if Pilot workloads may need to be recreated or separated later.
Architecture
Pilot architecture needs more explicit decisions than POC architecture because external users change the risk profile. The product may still evolve, but the team needs to understand customer isolation, data flow, AI model use and the consequences of any deferred platform decisions.
The aim is not to over-engineer the Pilot. The aim is to make architecture choices visible before they become customer-facing obligations.
Related guidance
Data protection assurancePilot to Production data migrationPolicies and proceduresCost governance and unit economicsContainer platform decisionsAI model governanceMulti-tenancy and customer isolationSummary
The company should understand what data may appear, where it goes, what users have been told, how Pilot resources can be recreated, and which architecture decisions affect customer risk.
How Brokenhouse helps
Turn this into a practical plan.
I help technology teams turn this guidance into decisions, implementation plans, governance evidence and production-ready operating models.
Talk through your situationNext guidance
Related decisions to work through
Agents used by the delivery team need a different governance model from AI models embedded in the product. Delivery agents may not be part of the customer-facing service, but they can still create risk because they may read code, write code, inspect logs, summarise documents, generate infrastructure changes or draft customer-facing material.
AI models used by the product need their own governance model. They are different from agents used by the delivery team because they sit closer to customer workflows, user data, automatic processing and contractual promises.
Use containers as the default packaging stance. They give the product a flexible route from POC to Pilot to Production without forcing the final hosting decision too early.