// Auxil Chassis

Accounts, tenancy, billing and operations, delivered as source in your stack

Launch with accounts, tenant isolation, billing, durable jobs, audit and deployment already built for your stack.

// The situation

The situation

A new product team needs to prove its core idea, but production readiness depends on a large amount of standard engineering: accounts, permissions, billing, tenant isolation and reliable background work. Building that foundation can consume the first months of delivery before the differentiating product is ready.

Tenant isolation is especially difficult to retrofit because it affects every path to customer data. Weak foundations often surface during an enterprise security review or acquisition diligence, when fixing them is most disruptive and expensive.

// For technical teams

What sits underneath the promise

Domain-driven and hexagonal

Business rules live in focused domain modules behind explicit ports. Identity, payments, storage and infrastructure remain replaceable adapters rather than becoming tangled through the product.

Three layers of tenant isolation

PostgreSQL row-level security, an explicit access context on every data operation, and authorisation policies inside each domain reinforce one another. Isolation does not depend on every developer remembering one check.

Strong types at the core

The reference implementation uses distinct identity types and makes many invalid states impossible to represent. When delivered in another language, boundary validation, typed interfaces and tests preserve those guarantees.

Tests at the boundaries that matter

Unit tests specify domain behaviour, integration tests exercise tenant isolation against real PostgreSQL schemas, and architecture checks prevent forbidden dependencies. The suite acts as an executable specification, not a vanity test count.

// What you get

Core capabilities included

Accounts, login and single sign-on

Sign-up, sessions, roles, teams, invitations, and the identity provider your enterprise customers insist on. Switching provider is a setting, not a rebuild.

Keeping customers' data apart

Three independent safeguards prevent one customer from accessing another's data, so a mistake in one layer is caught by the other two. Building isolation in from the start is safer and less expensive than retrofitting it.

Billing, subscriptions and usage limits

Plans, trials, upgrades, metered usage and quotas, checked against the payment provider rather than assumed. What a customer was charged can be reconstructed line by line.

Background jobs that survive a crash

Long-running and scheduled work picks up where it stopped, retrying the step that failed rather than the whole job. Onboarding, imports and provisioning do not half-happen.

File storage, email and an audit trail

Uploads kept apart per customer, transactional email that works locally as well as in production, and a record of who did what, written automatically rather than remembered at each call site.

Deployment, environments and monitoring

Environments defined in code, database migrations that run in a known order, a build pipeline your team can reproduce on a laptop, and logging and tracing wired through from day one.

Three layers. At the bottom, foundations that are kept: accounts, tenant separation, billing, jobs, storage and operations. Above it, the engine holding what is genuinely hard about the domain. On top, the customer-facing product, which is expected to change.

// In your language

In your language

The foundation is implemented in the language your team already uses: TypeScript, Python, Java or .NET. It is delivered into your repository with documentation and tests, ready for your developers to maintain and extend.

Auxil maintains an OCaml reference implementation to verify the core isolation and workflow rules before they are adapted to your stack. Your team does not need to run or maintain OCaml.

// Who this is for

Who this is for

Venture studios and holding companies

You start new companies on a regular cadence and pay for the same groundwork every time, out of a budget meant for the product.

One foundation across the portfolio, so a new venture starts at week one on its actual idea.
Corporate innovation teams

You are standing up a new product inside a larger business, and the parent's security and audit expectations apply to it from the first review.

Groundwork that answers the security questionnaire before it is sent, in your own stack.
Funded startups going upmarket

The prototype won early customers. Now an enterprise buyer wants single sign-on, an audit trail and a security review, and your team is quoting a quarter for it.

The enterprise requirements built properly, while your engineers stay on the product.
Teams outgrowing their foundations

The original scaffolding is holding the product back, and it cannot be replaced with everything paused for three months.

Foundations rebuilt underneath a running product, alongside the people who maintain it.

// How it is delivered

Choose the delivery model

// Option one

Foundation build

Fixed scope, your stack, alongside your team

The foundations implemented in your repository, in your language, working with your engineers rather than around them. You own the code, there is no runtime licence, and nothing calls home. Your team maintains it after we finish.

// Option two

Internal licence

Perpetual internal use across your portfolio

For organisations that start products repeatedly. Each new product is stood up as a short engagement on the same foundations, so your people and the answers to diligence questions carry from one venture to the next.

The thinking behind the three layers is set out in the batting stance.

book a call