The system
Every module, and every wire between them.
Software is easy to list and hard to explain. A list of modules makes this look like twenty products you have to buy. It is one product, and the reason it works is not any single screen. It is what happens between them. This page draws that.
The map
Tap any module. The lines are the product.
The dark centre is not a module. It is the jobs table, and one integer on it called
stage. Every ring module either writes that integer or reads it. The curved
lines are the connections that do not go through the centre: a configurator handing a
takeoff to the Proposal Builder, an install seeding the next door knock, a crew's hours
landing on the job they were standing on.
Drag the diagram sideways to read it
Users & Audit sits around all of it
five roles · every route gated server-side
Reps and field crews cannot read cost or margin. That is not a hidden nav item, it is the API refusing. Pick a module above to see what it is wired to.
The spine
One integer, twelve values — and everything hanging off each one.
Every module above filters on this one number. Move the job along it. Above the line is what goes out at that moment; below it is what runs. This is the part that is hard to say out loud in a meeting: not what the modules are, but how many of them a single job quietly passes through between a Facebook ad and a paid invoice.
Stage 3 is the handoff line: sales owns everything to its left, operations everything to its right. It is the only place in the company where a job changes hands, and it is one number changing. Moving a job forward timestamps an activity row, fires the sequences bound to the stage it entered, and cancels every queued message from the stage it left.
Why the wires matter
Three things that are only possible because it is one system.
Nothing gets re-keyed
The takeoff becomes the contract.
Every configurator pushes the same shape onto one queue: trade, items, spec, price. The Proposal Builder reads it. What the rep measured at the kitchen table is what prices, what gets signed, what gets ordered and what gets costed. Five trades, one contract, no retyping between them.
Nothing embarrassing gets sent
Signing cancels the chase.
Moving a job forward auto-exits every queued message from the stage it left. The system cannot text a customer asking whether they are still deciding after they have signed. That is not a rule someone remembers to follow, it is what the stage change does.
Nothing fires on import
Migrating 300 customers does not text 300 customers.
The import path deliberately does not fire triggers. One deliberate omission is the difference between a CRM takeover you can run on a live business and one that introduces itself to your entire database at once.
Where this drawing comes from
It is traced from the running system, not sketched.
The twelve stages are one array in the server. The connections are the handoffs, triggers and reads that already exist in the build: the trigger bus, the takeoff queue, the price book reads, the cost roll-up. If a line here does not exist in the product, that is a defect in this page, and it is worth telling us about.