Custom ERP for an events production company

The challenge

An events producer isn’t a business with one workflow — it’s several technical departments running in parallel: sound, lighting, video, rigging, power, transport, production. Each with its own inventory, staff and timings, and all of them required to converge on the same event.

That creates three problems no off-the-shelf tool handles well:

• Inventory scatters. Each department knows what it holds, but nobody can say what went out to a specific event or what hasn’t come back.
• Staffing is planning, not a list. Every person assigned to a department for an event generates an assignment record, and those records are what later drive payroll. If the calendar and payroll live apart, sooner or later they disagree.
• Auditing the auditor. In an operation moving expensive inventory and calculating payments, the uncomfortable question isn’t who watches the technicians — it’s who watches administration.

There’s also a contextual constraint that rules out half the catalogue options: this runs in Venezuela. The connection drops. The power goes. A system that only works online leaves a crew standing idle mid-load-in.

Only one written trace of the starting point survives, and it sits in the updater’s own code: installers were carried to each machine by hand, with nobody certain who was running which version. It’s a small detail that describes the moment well — an operation growing faster than the tools holding it up.

The solution

We built a complete internal ERP: a dedicated API, a desktop application for daily work and a mobile application for crews in the field, organised around the technical departments plus three cross-cutting roles — Administration, Event Control and Oversight.

What the system covers

• Per-department inventory with intake, dispatch, adjustments and transfers. In the mobile app every dispatch is tied to a calendar event, so all participating departments stay linked to it.
• Calendar → assignments → payroll. Each assigned person generates an assignment record; those feed Event Control, the internal ranking and rate-based payroll. The master sheet and payroll deliberately share one calculation, making it impossible for them to show different figures for the same month.
• Client, personnel and supplier databases, with role, department and attendance.
• Incidents and disciplinary records per department, routed to Administration with automatic reporting.
• Parts and servicing for the departments that maintain their own equipment, each with its own inventory and history.
• Suppliers, outstanding debt, licences and renewals with configurable advance warning.
• Quotes tied to client and event, carrying through to invoicing without anything being retyped.
• A services calendar, separate from the assignments calendar, for work that isn’t an event.
• A dashboard showing the state of the operation on one screen, surfacing to each role only what it is entitled to see.
• An AI assistant over the system’s data, under the same role permissions as the rest of the application.

The two decisions holding the rest up

1. Oversight watches Administration, and cannot see money. The oversight role belongs to no department: it sees the full audit log — including what administrators do — and deliberately has no access to amounts, payroll or clients. The comment in the code puts it plainly: a watchman with access to the money would be more risk, not less. In the other direction, Administration cannot read that log: the party being audited doesn’t decide what gets recorded.

2. Writes survive the outages. If the connection drops mid-operation, what’s pending is held and re-sent on reconnect — and that write does not execute twice. Logging the same equipment dispatch twice would be worse than not logging it. It’s the difference between an application built for a real connection and one built for a demo.

The result

The system is in daily use. Every department works from the same calendar and the same inventory; payroll and the master sheet come from one calculation, so they cannot contradict each other; and a dropped connection no longer stops work at the venue.

By agreement with the client we don’t publish their operational figures or the system’s technical detail. That’s their data, not our sales material — and describing publicly how something is built inside only makes life easier for anyone who wants to attack it. If you’re weighing up something similar and need the detail to decide, we’ll walk you through it on a call.

A case study not showing the internals of a client’s system ought to be the normal thing. If we ever work together, your data and your architecture get exactly the same treatment.

Stack used

Broadly, and without going into versions or infrastructure topology:

• A Python backend of our own over a relational database
• Native desktop and mobile applications from a single codebase
• Authentication with role-based access enforced at every layer
• An AI assistant connected to the system’s data, under role permissions
• The client’s own infrastructure — no per-user licences, no dependency on third-party platforms