SaaS organizations
Organization shapes
Software companies come in a handful of recognizable shapes. Each is a different arrangement of the same ten primitives: which scopes exist, which seats they contain, who holds which powers, and where agents sit. Here are four common ones, drawn as trees and written as code.
Seed stage: two founders and a team of agents
Text description of this diagram
- Northwind
- CEO — founder
- CTO — founder
- Deployer — program, ships low-risk
- Ops — agent, scales in envelope
- Support — LLM, triage + drafts
- Architect — agent, sandbox only
- Engine — engine
Two people, and everything else is a program or an agent with a narrow, compiled envelope. The founders are the constitution: every amendment needs both. Agents can do a lot, but only inside envelopes, and anything expensive or irreversible routes to a founder with a deadline.
scope Northwind : org.Organization {
persona NorthwindCo
use gov.Constitution(
founders = { CEO, CTO },
amendBy = CEO,
board = CTO,
quorum = 1,
delay = 2 d
) as Const
position CEO : org.Owner {
cardinality 1
eligible when self is pp.Person
}
position CTO : org.Officer {
cardinality 1
eligible when self is pp.Person
}
position Deployer : org.Member {
cardinality 1
eligible when self is ag.Program
}
position Ops : org.Member {
cardinality 1
eligible when self is ag.Autonomous
}
position Support : org.Member {
cardinality 1
eligible when self is ag.ModelBased
}
position Architect : org.Member {
cardinality 1
eligible when self is ag.Autonomous
incompatible with Ops
}
use rz.RealizationEnvelope(
holder = Ops,
requirement = Api,
operation = ops.Scale,
admissible = a.n <= 12
and holds ops.price(bound(Api)) * a.n <= 4_000 USD per month
) as OpsEnvelope
use org.Approval(
approver = CTO,
subject = ops.ScaleRequest,
threshold = true,
deadline = 1 business-days,
escalateTo = CEO
) as ScaleApproval
use rz.ExperimentPower(
holder = Architect,
pattern = Experiment,
budget = 200 USD,
duration = 1 d
) as Research
use fin.Budget(
scope = Northwind,
resource = econ.Money,
limit = 18_000 USD per month,
reserve = 2_000 USD,
window = month,
orElse = gov.Freeze(except = { Const.Materialize })
) as Runway
}- Constitution of two. Both founders are founders; either can propose, and the CTO's vote is the quorum on constitutional change.
- Agents with envelopes. Ops scales up to 12 units under a cost cap; the Architect researches in 200-dollar sandboxes; Support's outputs are claims at N until the founders' trust policy says otherwise.
- Runway as a rule. A monthly budget with a freeze keeps the company inside its burn, and the reserve keeps the compiler able to apply an approved raise.
Product-led growth: squads, a platform, a guild
Text description of this diagram
- Brightline
- Exec — CEO · VP Eng · VP Product
- Product
- Growth — PM · EM · 4 eng
- Activation — PM · EM · 3 eng
- Billing — PM · EM · 3 eng
- Platform
- SRE — on-call 2..
- Deployer — program
- GTM
- Self-serve — LLM
- Sales assist
- Web guild — member when …
Autonomous squads each own a slice of the funnel. A platform team keeps production running. A guild cuts across squads without owning anything. The interesting parts are what squads may do alone and what they may not.
pattern Squad(focus : Text) {
scope S : org.Team in Product {
persona SquadP
position PM : org.Officer {
cardinality 1
}
position EM : org.Officer {
cardinality 1
incompatible with PM
}
position Engineer : org.Member {
cardinality 2..6
}
norm Experiments {
power of PM to decide launch | stop about growth.Experiment
when e.traffic <= 20 % and e.squad = here
}
norm ShipsOwnCode {
power of EM to authorize execute about eng.Deploy
when c.owner = here and c.risk = "low"
}
}
}
use Squad(focus = "acquisition") as Growth
use Squad(focus = "onboarding") as Activation
use Squad(focus = "revenue") as Billing
-- Pricing changes cross squad boundaries: Billing proposes, the VP Product decides after Finance reviews.
use gov.ReviewedProposal(
kind = growth.PriceChange,
approver = VPProduct,
reviewer = Finance.Lead,
deadline = 5 business-days,
escalateTo = CEO
) as PricingRoute
scope WebGuild : org.Team in Brightline {
member when self member of Product and holds eng.frontend(self)
norm Standards {
power of persona to enact _ at level operational about eng.FrontendStandard
}
}- One pattern, many squads. A squad is a pattern instantiated three times; changing the pattern changes every squad, with provenance.
- Local autonomy, bounded. A PM can launch experiments up to 20 % of traffic; an EM can ship the squad's own low-risk code. Anything beyond is a proposal.
- Guilds as scopes with computed membership. Members are whoever works in Product and holds the frontend claim; the guild can enact operational standards and nothing else.
Platform and stream-aligned teams
Text description of this diagram
- Corvid
- Stream-aligned
- Checkout
- Search
- Mobile
- Platform
- offers CI
- offers Deploy
- offers Observe
- Enabling
- Security — time-boxed
- Subsystem
- Billing engine — specialists
- Stream-aligned
In the Team Topologies shape, stream-aligned teams consume what the platform team offers. In Endoskeletal that is literal: the platform team offers capabilities with contracts, and stream teams require them. The contract is the API between teams.
scope Platform : org.Team in Corvid {
persona PlatformP
offers capability Deploy {
operation deploy(c : Entity) -> outcome : Claim
guarantee eventually holds eng.deployed(c) or holds eng.rolled-back(c)
property lead-time <= 15 min
property availability >= 99.9 % per month
}
offers capability Observe {
operation probe(r : Capability) -> observations : Claim
property freshness <= 1 min
}
}
scope Checkout : org.Team in StreamAligned {
requires capability ShipCheckout {
operation deploy(c : Entity) -> outcome : Claim
property lead-time <= 30 min
for CheckoutConversion
}
}
-- enabling teams hold time-boxed powers inside the team they are helping
use org.Delegation(
from = SecurityEnablement.persona,
into = StreamAligned,
expires = 6 weeks
) as Embed- Team APIs are contracts. Checkout's requirement is met by the platform's offered Deploy. If the platform's lead time degrades past 30 minutes, Checkout's requirement stops being satisfied and a gap opens with an owner, before anyone files a ticket.
- Enabling teams are temporary. Their power inside a stream team is time-boxed; after six weeks, their acts there misfire.
- Complicated subsystems are ordinary scopes whose positions require specialist qualifications as eligibility claims.
Enterprise SaaS with compliance
Text description of this diagram
- Halcyon
- Engineering
- Teams — ×6
- CAB — 5 voters
- Security & GRC
- CISO
- GRC analyst
- Evidence — program, collects controls
- Customers
- Acme DPA — EU residency
- Globex MSA — 99.95 % SLA
- Auditor — external party
- Engineering
Once enterprise customers arrive, contracts and controls become part of the organization. Each customer agreement is a contract scope with its own obligations. Security and GRC own controls, and a program collects the evidence auditors ask for, continuously.
scope AcmeDPA : org.Contract in Customers {
persona AcmeDPAP
norm Residency {
prohibition on any Party
aim exists x : Entity . x is cu.AcmeData
and custody-jurisdiction(x) not in { EU }
source external acme.DPA # "§4.2"
level constitutional not tradeable not defeasible
}
norm BreachNotice {
obligation of SecurityGRC.CISO to acme.Party
when holds sec.breach(x) and x is cu.AcmeData
aim within 72 h: occurred assert(sec.Notified(acme.Party, x))
}
}
use org.SegregationOfDuties(
act = authorize execute(eng.Deploy, c),
subject = eng.Change,
separate = { c.author }
) as NoSelfDeploy
norm ControlEvidence {
obligation of SecurityGRC.Evidence to persona
when occurred tick(t) and t.boundary = "day"
aim within 4 h: occurred derive(grc.ControlStatus(_, t.day)) by SecurityGRC.Evidence
not tradeable
}- Customer terms become rules. A data-processing agreement's residency clause is a constitutional, non-tradeable prohibition with the contract as its external source.
- Segregation of duties is checked, not audited after the fact: an author's authorization of their own change misfires.
- Audit evidence is a by-product. Because the log is the only state, the evidence for an access review or a change-management control is a projection, and a program derives it daily.
Other common variations
| Variation | How it's expressed |
|---|---|
| Remote-first, follow-the-sun | Regional positions whose eligibility and routing read a calendar claim; handoff obligations at shift boundaries. See incident response. |
| Open-core with community maintainers | A Community scope admitting external parties; a counts-as rule turning a signed contributor agreement into a grant; maintainers' merge power limited to the open repositories. |
| Marketplace with third-party vendors | A contract scope per vendor; vendors offer capabilities; their claims start at N and are corroborated by your own monitors. |
| Holacracy-style circles | Scopes with a circle lead position, governance powers at collective level, and roles as positions any member may occupy by election. |
| Agency or professional services | A project scope per client with an attention budget; utilization targets as soft intents; change orders as reviewed proposals. |