Studio Operating System v1
Defining the constraints for Axiom Labs. Why we are choosing a "Systems First" approach over generalist agency work.
Axiom Labs
Field notes from the studio
Why Systems First instead of "we do everything"
Generalist agencies say yes to every tech stack and industry, burning time on context switches and Day 0 infra.
We chose fewer stacks and fewer domains, turning our patterns into reusable modules so we can ship reliable software fast.
Pillars of Studio OS v1
Opinionated tech stack: Next.js/React on the edge with Cloudflare Workers, D1 or Postgres, Drizzle, Auth.js, and Paystack or Stripe.
Engagement templates: discovery, architecture briefs, and delivery cadence with explicit constraints and success metrics.
Runbooks over heroics: repeatable steps for incidents, webhooks, and schema drift so muscle memory replaces firefighting.
Observability by default: structured logs, latency/error/volume metrics, and non-negotiable audit trails for money-touching flows.
Constraints we operate under
We will not build in every stack; focus creates leverage and reusable libraries.
We will not ship without documentation: local dev readme, high-level architecture, and runbooks for critical flows.
We will not ship money features without tests. Automated coverage is table stakes for anything that charges or calculates.
We optimize for long-term maintainability over quick hacks; a day spent removing a class of bugs is worth it.
What v1 means for clients and products
Clients get edge-native modern architecture, boring reliability on core paths, and documentation instead of just a repo.
Our default mindset is "how could this break in production?" rather than "how fast can we demo this?"
Internally we get less decision fatigue and higher quality as the same patterns get exercised across products like TaxCalc.ng.
Where Studio OS goes next
Future iterations add shared auth/payment libraries, a reusable design system, and deeper Web3 playbooks.
For now v1 is enough: it runs TaxCalc.ng, it runs our experiments, and it will run client work without reinventing process.
Apply this pattern
Use the same guardrails on your build
Copy the playbook, reuse the benches, and tailor the constraints to your stack.
Key takeaway
Studios get sloppy when they chase everything. Guardrails, constraints, and rituals keep us pointed at production outcomes.
Useful? Send it to someone scoping a similar build.
Related Signals
Stay in the loopHow to scope an internal tools project without building the wrong thing
Internal tools go wrong when teams start from screens instead of workflow boundaries. Here is how to scope the project before the build drifts.
What to prepare before building a business system
Business systems projects go vague when the workflow is still trapped in tribal knowledge. Here is what to prepare before the build starts.
When a business system should stop living in spreadsheets
Spreadsheets are fine until the workflow itself becomes the product. Here is how to tell when the process needs a system instead of another tab.
Follow the Studio
More field notes and build logs.