JetCustoms: the whole shop on one system, in three months

Ten users, five business domains, and no system of record. Jobs, hours, parts and client statements each lived in a separate spreadsheet or hand-made PDF, so the same entity existed several times over with no key joining the copies and no constraint preventing them from diverging. Every aggregate a manager asked for — cost per vehicle, margin per project, hours booked against a job — was recomputed by hand from documents that could already disagree, and nothing in the process was able to detect that they did.

One application over one Postgres database, with the five domains modelled as bounded contexts inside a single schema rather than as separate services. Each fact — an hour, a part, a vehicle, a settlement line — is written once and referenced by key; aggregates are derived by the engine rather than assembled by a caller. Authorisation is a schema concern, not a UI concern, so the same predicates hold for the application, an admin path and an ad-hoc query alike. Shipped with a handbook and an engineering guide, so the shop is not dependent on us to change it.

The decision that shaped every other one: a cross-domain question should be a join, not an integration.

One database rather than five services buys referential integrity enforced by the engine, cross-domain reads inside a single transaction, and no inter-service contract to version. What it costs is independent deployability: a migration touching finance ships with everything else, and the module boundaries are a review discipline rather than a wall the runtime enforces. At ten users with one engineer that trade is correct by a wide margin. The boundaries are drawn in the schema from the first migration rather than discovered later, which is what keeps the decision reversible if the shape of the problem changes.