Six years ago I started building AIREP because the tools available to small and mid-size businesses didn't fit the way those businesses actually work. Off-the-shelf ERP systems are either too rigid, too expensive, or too generic. Accounting platforms like Xero and MYOB are great for bookkeeping but stop short when you need manufacturing, CRM, and fulfilment in the same workflow. So I built my own.
AIREP is a multi-tenant ERP built in Django. Each company that uses it gets a fully isolated PostgreSQL database — not row-level filtering with a tenant column, but a separate database per tenant. That decision was made early and has paid off consistently: there is no risk of data leaking across accounts, migrations can be rolled out tenant by tenant, and performance doesn't degrade as any single company's data grows.
What it covers
The system has grown to thirteen interconnected modules over six years.
Sales and procurement sit at the centre. Sales orders move through a documented lifecycle from draft to confirmed to invoiced, with line items, pricing tiers, and communications tracked at every stage. Purchase orders follow the same discipline on the supplier side — linked to inventory thresholds, supplier item codes, and historical pricing. Both feed into the accounting layer automatically.
The inventory module manages an item master catalogue with sell prices, cost prices, units of measure, images, weights, and dimensions. Stock movements are tracked against every transaction — purchases, sales, adjustments, stock-takes. Kit components let you define assemblies and have their consumption tracked when a kit is sold. Physical locations (rack and bin positioning) are supported for warehouses that need it.
Manufacturing was added when one of the businesses using AIREP needed to track production orders from a sales order all the way to a finished product leaving the door. Production stages have their own status lifecycle. Quality inspections and defect logs are recorded against each production batch. Workshop-floor templates let supervisors define standard stage sequences for repeat jobs.
The accounting module handles chart of accounts, journal entries, payments, bank reconciliation, budgets, payroll, and GST/BAS reporting. The most significant piece of work here was the Illion bank feed integration — automated retrieval of bank transactions with optional MFA handling, matched against recorded payments using a rules engine. For businesses that previously reconciled manually at month end, this alone saves several hours a week.
CRM tracks the sales pipeline from lead to closed deal. Contacts, interactions, campaigns, and lead-scoring rules are all there. It is not Salesforce — it is scoped for small sales teams that need a system of record without the overhead of a dedicated CRM platform.
Shipping manages carriers, freight accounts, and shipment tracking. The freight quote module pulls dimensions and weights from inventory items to generate accurate estimates before an order is dispatched.
Workforce covers projects, time entries, timesheets, and work logs. If a business bills by the hour or needs to cost projects against payroll, this ties together the time spent and the accounting entries that follow.
Six years of decisions
There are a few decisions I am glad I made early, and a few I wish I had made sooner.
The multi-database architecture was worth the upfront complexity. It forces explicit thinking about what belongs to a tenant and what belongs to the global application — authentication, company records, and user-company memberships live in the global database; everything else lives in the tenant's database. The discipline this creates has prevented whole classes of bugs.
Django's ORM is a good fit for this kind of domain. Complex queries stay readable. The admin interface has been genuinely useful during development for inspecting state without building dedicated UI. The migration system, despite its constraints, gives a reliable audit trail of every schema change.
The audit log was added in year two and should have been there from day one. Every meaningful state change in the system records the user, IP address, timestamp, and a diff of what changed. This has been essential for debugging, for customer support, and for compliance conversations.
HTMX for partial page updates was added in year four. Before that, the UI had too many full-page reloads. HTMX gives most of the interactivity of a single-page app without the build tooling and the complexity that comes with it. For a system where the server is the source of truth, it fits well.
Nova integration
The most recent layer added to AIREP is the Nova integration. Nova is my AI assistant — a separate system built on FastAPI with its own agent architecture. AIREP exposes an internal API that Nova calls to perform actions: creating sales orders from parsed emails, generating procurement recommendations, running morning briefings, flagging overdue invoices, quoting freight.
This integration has changed how the system gets used day to day. Tasks that previously required opening AIREP, navigating to the right screen, and filling in a form can now be delegated to Nova as a natural-language request. Nova acts, AIREP records, and the audit log captures exactly what happened and why.
Where it is now
AIREP currently supports businesses in engineering, signage, and industrial parts supply. The Find a Sign and Sweeper Parts integrations use AIREP as their backend — managing inventory, orders, customers, and accounting while the customer-facing storefronts run independently and call into AIREP via webhooks.
Six years in, the system does what I set out to build: one place where a small business can manage operations end to end, without paying enterprise licensing fees or stitching together five different SaaS subscriptions. It is not finished — nothing like this ever is — but it is in production, it is used daily, and it gets better every week.