Are we ready for a Pilot?
Useful for
Introduction
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.
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
Startup playbook: from POC to Production
This is a CTO playbook for augmenting the agentic SDLC with the company work that sits around the software. Most startup writing focuses on building the product. This playbook focuses on the identity, governance, data protection, delivery, cloud and operational decisions that allow a small SaaS company to move from idea to production without creating avoidable risk.
Is the company ready?
The first few months of a software business are not just about building the product. They are about creating the conditions that allow the product to be built, deployed, governed and supported without the company tripping over its own foundations.
Can we start the POC?
Before starting the POC, there is a small amount of governance that should be put in place. This is not about slowing the team down or pretending to be an enterprise. It is about creating enough shape that the first few months do not become a mess of forgotten passwords, inconsistent names, unclear decisions and accidental access.