Startup playbook
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.
Useful for
Introduction
In an agentic SDLC and remote-working model, identity and documentation become even more important. People and agents both need a clear source of truth. Access needs to be deliberate. Decisions need to be recorded. The company needs to move quickly, but it also needs to avoid creating an avoidable mess that has to be untangled later.
Why this stage matters
Before a startup begins building software, it needs enough company infrastructure to operate deliberately. This does not mean building a mature enterprise control environment on day one. It means putting the company in a position where identity, domain ownership, email, documentation, devices and basic responsibilities are understood.
This gate exists because early shortcuts become difficult to unwind. The first tenant, the first domain, the first admin account and the first documentation area can quietly become the foundation for everything that follows.
The decision
The company is ready when it can safely create accounts, communicate externally, hold governance documentation, control administrative access and explain who owns the public presence of the business.
Identity
Identity is the first control plane for the company. Before software delivery starts, the business needs to know who can sign in, who can administer systems and how emergency access will work.
The aim is not to create a heavy enterprise access model. The aim is to avoid shared accounts, uncontrolled administration and unclear ownership becoming the foundation for everything that follows.
The original playbook is deliberately stronger than "turn on MFA". It expects the habit of privileged access management to start early, even if the company is small. PIM, break-glass handling and alerting set the tone before product infrastructure exists.
Domain
The domain becomes part of the company's trust boundary. It supports identity, email, the corporate website and the way customers recognise the business. If ownership or DNS control is unclear early, the company can inherit avoidable operational and security risk.
The domain does not need a complex operating model on day one, but the company must know who owns it, where DNS is managed and who can make changes.
Email is part of the company's external credibility and internal control environment. It is how the company communicates with customers, suppliers, regulators and staff. Getting the basics right early helps avoid deliverability problems and reduces impersonation risk.
For this gate, the requirement is simple: email must work, and the domain must be protected enough that the company is not starting from a weak trust position.
Corporate presence
The corporate website and public contact channels are part of the company's operating surface. They do not have to be hosted on the final product platform, but the company needs to understand who owns them, who can publish changes and which public channels customers can use.
This matters early because privacy, security and support expectations often start before the product is ready. If the public presence is unmanaged, customers and partners may receive inconsistent or unreliable information.
Governance
Governance needs a home before it can become useful. A startup should know where decisions, policies, procedures and operating notes live, even when those documents are lightweight.
This is especially important for agent-assisted delivery. Decision records are useful to people, but they are also useful to agents that need to understand why choices were made and what constraints already exist.
Related guidance
Tenant security monitoringDomainEmailExternal presenceData protection assurancePolicies and proceduresSummary
The company should be able to operate with named accounts, known domain ownership, working email, clear public contact points, a governance home and an explicit device stance.
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 should not replace expert judgement. They should help capture, structure, challenge, and reuse it.
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.