You’ve probably lived this little corporate comedy: you ship software, deploy with CI/CD, run Infrastructure-as-Code… and when someone asks “how does the company work?”, you point to a dusty PDF, three Google Docs, and “ask Sarah, she knows.”
Daniel Rothmann describes the same irony during an ISO 27001 audit: a highly digital software business whose core (policies, procedures, org structure) is still managed as static documents—leading to hundreds of extra person-hours gathering evidence, debating wording, and doing reviews. Source: Company as Code (42futures, Feb 25, 2025).
This article turns the idea into something you can actually build: Company as Code—modeling your organization as a declarative, versioned, testable system connected to your business tools (HRIS, CRM, ticketing, IAM) and ready for automation with AI agents.
What “Company as Code” really means
Company as Code (often grouped with Business-as-Code) means describing your company with a formal representation—think DSL + YAML/JSON/TypeScript—stored in Git, with:
- Versioning: every policy/org change becomes a commit and a pull request.
- Tests: you can automatically validate rules (segregation of duties, approvals, access constraints).
- Deployment: you “apply” changes into your systems (Notion/Confluence, Okta, Slack, Jira, HubSpot…).
- Queryability: you can ask your org questions like a database (“who can approve refunds over $5k?”).
This is not about “coding culture.” It’s about coding what must be explicit: responsibilities, rules, workflows, and controls.
Rothmann’s point is simple and painful: if we demand rich operational data, why do we accept sparse organizational data? (42futures).
Why now: AI + low-code make this inevitable
Two trends make Company as Code far more practical in 2026 than it was a decade ago:
1) Low-code/no-code is everywhere Industry forecasts widely cite Gartner’s view that 75% of new enterprise applications will be built using low-code/no-code by 2026. And aggregated industry stats report 87% of enterprise developers already use low-code for some tasks (DreamFactory).
Translation: your processes no longer live in one monolithic ERP. They live in configs and automations spread across tools.
2) Code generation and agents Gartner also predicts that by 2028, 40% of new enterprise software will be created using prompt-based code generation techniques (reported in a WSJ piece on “vibe coding”).
Translation: maintaining a “company model” in code becomes accessible—if you put guardrails around it.
The real problem: your company is already code… just spaghetti
Your business is already “programmed,” just not cleanly:
- Access rules in Google Workspace/Okta.
- Workflows in Zapier/Make/n8n.
- Sales pipelines in HubSpot/Salesforce.
- Support in Zendesk/Intercom/Jira Service Management.
- Finance in Xero/QuickBooks/Pennylane.
All of it has APIs. All of it changes. Yet your “source of truth” is usually a static doc.
- unclear decision rights,
- slow onboarding,
- audits that turn into archaeology,
- broken workflows from hidden dependencies.
Company as Code is about putting an architecture on top of the mess.
What you get (practical benefits)
1) Less audit and compliance tax Rothmann mentions hundreds of hours spent on evidence collection, policy wording debates, reviews, and the audit itself (42futures).
- automatic evidence (logs, exports, snapshots) attached to controls,
- continuous checks (e.g., “admin access requires MFA + justification”),
- pull requests that trigger compliance checklists.
2) Faster onboarding Instead of “ask around,” you provide: - a graph of teams/roles, - versioned runbooks, - reproducible workflows.
3) Less dependency on heroes Implicit orgs depend on people. Explicit, tested orgs depend on systems.
4) A real foundation for AI automation AI agents are terrible with contradictory PDFs. They’re good with: - explicit rules, - clear permissions, - events and APIs.
Company as Code becomes the “contract” that keeps agents from doing stupid things.
What a simple MVP looks like
You don’t need a fancy new language on day one. A realistic MVP for a small business:
1) A “company” repository
- /org/teams.yaml (teams, owners, missions)
- /org/roles.yaml (roles + responsibilities)
- /policies/ (security, purchasing, access, HR)
- /processes/ (onboarding, refunds, incident response)
- /controls/iso27001/ (controls + expected evidence)
2) Schema + linter - JSON Schema / OpenAPI to validate structure - a linter to prevent inconsistencies
3) Tests (yes, tests) Examples: - “Payments over $10k require 2 approvers from different departments.” - “No contractor can have both prod access and billing access.” - “Every team has an owner and a backup.”
4) A GitOps-style “apply” pipeline When a PR is merged: - update Notion/Confluence pages automatically, - sync Slack/Google/Okta groups, - create/update Jira tickets, - generate an “audit pack” (dated exports).
This aligns with the broader push to apply DevOps methods to BizOps. For example, Salto has been publicly discussing a “Company-as-Code” approach by versioning business tool configurations using a declarative language called NaCl (Salto blog, Jan–Feb 2026).
Use cases founders actually care about
Use case 1 — Expenses and purchasing approvals Problem: either everyone can sneak expenses through, or one person becomes the bottleneck.
- declarative rules (thresholds, approvers, exceptions),
- tests (no single approver for large amounts),
- deployment into your tools (expense platform + Slack approvals).
Use case 2 — Data access (GDPR/ISO/SOC2) Problem: you don’t really know who has access to what.
- mapping “role → systems → permissions,”
- automated quarterly access reviews,
- exportable evidence.
Use case 3 — Sales ops (CRM) Problem: your HubSpot/Salesforce pipeline drifts; fields change; automations break.
- versioned configs,
- PRs for critical field changes,
- rollbacks when things break.
Use case 4 — Incident management Problem: when production is on fire, you improvise.
- versioned runbooks,
- clear escalation paths (who’s on-call, who approves the postmortem),
- automatically generated incident reports.
The traps (and how not to shoot yourself)
Trap 1: formalize everything If you code too much, you create bureaucracy… in YAML.
Rule: only code what must be stable, auditable, or automatable.
Trap 2: confusing source of truth with interface Notion is a great interface. Git is a great source of truth.
Publish to Notion—don’t let Notion become where truth changes without review.
Trap 3: weak write controls Treat the “company” repo like production: - mandatory PRs, - reviewers, - audit logs, - signatures if needed.
Trap 4: “AI will run the company” fantasy No. AI executes. Humans govern.
The winning model is agents + human-in-the-loop + tested rules.
A 30-day roadmap to start
- list 10 critical decisions/workflows (payments, access, pricing, support, hiring)
- pick one scope (e.g., access + onboarding)
- create the repo + schema
- write 5 non-negotiable rules as tests
- connect 2 systems via API (e.g., Okta/Google + Slack)
- auto-generate published documentation
- add an automatic “audit pack”
- measure: onboarding time, access incidents, compliance time
Then iterate. Pragmatic, not dogmatic.
Bottom line
Company as Code isn’t engineer fan-fiction. It’s a logical response to reality: your business already runs on a distributed set of SaaS tools and automations. As long as your structure and rules live in static documents, you’ll pay an invisible tax—slowness, errors, painful audits, and dependency on key people.
The smart move in 2026: put a versioned source of truth at the center, connect your tools around it, and let AI automate execution under control.
Want to automate your operations with AI? Book a 15-min call to discuss.