Can we start the POC?

Introduction

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.

At this point we are still trying to move quickly. The POC is throwaway, but the habits around it should not be. The aim is to define the minimum rules that make the work understandable, repeatable and safe enough for a small team.

Why this stage matters

A POC should be cheap, fast and disposable, but it should not be chaotic. The aim is to let the team learn quickly without creating avoidable governance debt that later blocks a Pilot or Production launch.

This gate exists because the habits created in the POC often become the default operating model. Naming, repositories, secrets, decision records, basic DevOps and logging standards should be in place before the first useful demo.

The decision

The POC can start when the team can build, deploy and learn without storing secrets in source, capturing PII in logs, losing important decisions or creating infrastructure that is mistaken for Production.

Architecture

POC architecture should support learning rather than pretending to be the final platform. The team does not need to make every long-term technical decision before a POC starts, but it does need to record the decisions it makes and the compromises it accepts.

This matters because early architecture choices become reference points for people and agents. If a choice is temporary, insecure or made purely for speed, that context needs to be visible in source control before the work is copied into later stages.

DevOps

The POC does not need a mature delivery platform, but the team needs a controlled way to build, deploy and collaborate. The minimum aim is to avoid unclear repository ownership, uncontrolled access, unreproducible demos and secrets leaking into source control.

For a small startup, the approval model should be pragmatic. Barriers should exist, but early teams may need to self-approve as long as actions are visible, traceable and reviewed when risk increases.

Infrastructure

POC infrastructure should be deliberately lightweight. It exists to prove an idea, support demos and help the team learn. It should not quietly become Production by accident.

The key at this stage is clarity: what is the environment called, who can access it, what does it cost, how is it protected and what will happen to it when the POC ends?

Governance

POC governance should be light, but it should exist. The point is not to slow the team down. The point is to make the minimum expectations visible before useful code, data flows and deployment habits begin to form.

At this stage, policies are statements of intent rather than heavy procedures. They should still be backed by evidenceable procedures where needed, because those early records become useful for new clients, future staff and delivery agents.

Related guidance

Summary

The team should be able to build and demo quickly without losing decisions, leaking secrets, writing PII to logs or letting the POC become Production by accident.