Can we start the POC?

Introduction

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 team is trying to learn what works, what does not, what should be thrown away and what might be worth carrying forward. The aim is to learn quickly without creating avoidable governance debt that later slows down or blocks a Pilot or Production launch.

This gate exists because the habits created in the POC often become the default operating model. Source control, pull requests, deployment, secrets, decision records and logging standards should be in place before the first useful demo.

The POC does not need Production-scale governance, but it benefits from Production-shaped habits: source control, review boundaries, reproducible deployment, managed secrets, safe logging and visible architecture decisions.

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.

Architecture decision records are useful even when the POC is disposable. They explain why a choice was made, what was deliberately deferred and which constraints should guide generated code. For AI-assisted delivery, they become guardrails as well as history.

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.

At minimum, the POC should have:

• A GitHub repository or equivalent source control location.
• Pull requests for meaningful changes, even if the team is only one or two developers.
• A simple automated deployment path.
• A known demo environment that represents the latest working version.
• Secrets stored outside the repository, such as in Azure Key Vault or an equivalent secret store.
• A logging stance that prevents PII being written to logs.
• A clean merge habit, such as squash merging, so the history shows coherent changes rather than every experimental step.

Pull requests are not only about approval. They create a boundary around a feature or change. That boundary is useful when code is being generated with AI because it gives the team a visible point to review, accept, reject or revert the work.

Squashing changes before they land on the main branch is useful for the same reason. A POC can move quickly and still leave a readable history of decisions, features and reversions. That clean history matters later when the team needs to understand how the product changed, why a shortcut was taken or which work should be carried forward into Pilot.

Automated deployment can be basic at this stage. The important part is reproducibility. A POC will be demoed, discussed and changed quickly. The team should not depend on a local machine or a half-finished development branch being in the right state when someone needs to see the product. The team should be able to deploy a known version consistently without relying on one developer's laptop.

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?

Because POCs get demonstrated, there should be a known environment containing the latest working version. The team should not discover five minutes before a demo that the product only works on a local branch that is still being developed.

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.

The governance aim is to avoid blockers at the Pilot gate. The company should be able to show that the POC did not depend on local-only code, local-only deployment knowledge, secrets in source control, unmanaged personal data in logs or unrecorded architecture compromises.

The POC should also remain visibly disposable. If the team wants to carry it toward Pilot or Production, that should be a deliberate decision with known gaps, not a silent drift from demo environment to customer-facing service.

Related guidance

Summary

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