HomeBrigadier Pro — Provider Platform

A booking is an event for one side and a workload for the other

The marketplace side of HomeBrigadier solves the homeowner's problem: find a verified provider, see real availability, book, pay. From that side a booking is a single moment that either happens or does not.

For the provider it is the opposite. A confirmed booking is the beginning of something — it has to be assigned to somebody, fitted around the work already scheduled, attached to the right client history, and then actually delivered. Everything that makes it a good experience for the homeowner is work that lands on the provider afterwards, and none of it is visible from the consumer app.

That is the gap HomeBrigadier Pro fills. It is the operational system where service businesses manage their clients and bookings, and it exists because winning the job and running the job are different problems. A marketplace that only solves the first one hands its providers a growing pile of the second, which is how a provider ends up successful on the platform and operationally worse off than before they joined.

Operations software has a different failure profile

Provider operations involve staff with very different responsibilities, and that is the requirement the platform is shaped around rather than a feature it happens to have. In a service business the person arranging work, the person carrying it out, and the person accountable for the business are not the same people and should not see the same things. Modelling that as four distinct roles is what allows the system to be given to a whole team rather than kept on one person's login — which is the difference between operational software and a spreadsheet with extra steps.

The second constraint is that this software is used while working, not while planning. Someone opens it between jobs, on a phone, with a client waiting. Day-to-day booking management has to be fast and dependable in that setting, and dependability outranks capability: a feature that is occasionally slow is worse here than a feature that does not exist, because the person using it has already committed to being somewhere.

The third is that this is the second system in an ecosystem rather than a standalone product. A booking created on the marketplace has to mean the same thing on the provider side — same state, same client, same commitment. Two systems describing one booking differently is not a synchronisation inconvenience; it is a provider turning up on the wrong day.

Building around the two objects the business runs on

Client management and booking management are the whole product, and treating them as the two primary objects rather than as screens is what keeps the system coherent. A service business thinks in exactly these terms — who the client is, and what is booked — so a platform organised the same way needs very little explanation to the people using it.

Client management is what turns repeat work into an advantage. A provider who can see a client's history arrives already knowing the property, the previous job, and what was agreed last time, which is the practical difference between a service relationship and a series of unrelated transactions. That record is also the thing a marketplace cannot hold on the provider's behalf, because it is specific to how that business works.

The four-role access control is enforced structurally rather than by hiding interface elements. Roles that only affect what is displayed are a presentation choice; roles that determine what each person can reach are an access model. In a platform holding client details and booking history across a whole provider network, that distinction is the one that matters, since a hidden button is not a boundary.

Angular, Node.js and MongoDB carry the operational side, and it is worth noting plainly that this is a different stack from the consumer marketplace it works alongside. These are two products with two sets of users and two very different jobs — one optimised for a homeowner making a single booking decision, the other for a team managing hundreds of them — and they are separate systems rather than one application wearing two interfaces.

What the numbers describe

100+ clients and 2,000+ bookings describe an operational load rather than a traffic figure, and it is the volume at which informal coordination stops working. A provider can hold a handful of clients and their histories in memory. At this scale the alternative to a system is not a simpler system — it is things being forgotten, and the forgetting happening in front of customers.

Four access roles is a small number that represents a real separation. It is worth reading as evidence that the platform was built to be used by an actual team, since a tool with one level of access is a tool that ends up operated by one person regardless of how many people need it.

99.9% uptime carries a specific weight for operational software that it does not carry for a consumer product. When a marketplace is down a homeowner books later. When the operations platform is down the provider cannot see today's schedule, cannot look up who they are visiting, and cannot work — the business stops rather than slows. Availability here is not a quality metric measured after the fact; it is a precondition for the day happening at all.