Custom Budget Control Software for an Electrical Construction Company

Here is what the platform does, module by module — from the materials catalog that feeds every cost calculation to the progress report that becomes the invoice.

What we built

A web application built from scratch in React and Node.js — not an ERP, and not a configured off-the-shelf product. The system is organized around executing a construction project: what it should cost, what it is costing, and what has been earned so far.

1. Materials master

Every material registered individually — screws, boxes, conduit, cable, faceplates — with its own price history: what was paid, when, and where it was bought. The catalog became the single source of truth for every cost calculation downstream.

2. Unit Price Analysis builder

The heart of the system. Users compose any unit of work from its real components — every material it consumes plus its labor allocation — and the system computes the unit cost. Each Unit Price Analysis carries both its bill of materials and its labor, so the price of a unit of work stops being a number someone remembers and becomes a structure the company owns, reuses across projects and can audit.

3. Project budgeting

Take-off quantities from the drawings are multiplied by the unit prices to produce the full project budget. This produces two things the company never had before: a total project cost built bottom-up from real components, and consumption ceilings — “this project consumes at most 30,000 screws” — a hard reference against which every purchase order and every withdrawal from the warehouse can be checked.

4. Labor planning and control

Personnel are modeled as a distinct resource with skill tiers — site foreman, skilled officers, helpers — each with its own rate. Staffing is planned month by month across the project timeline and validated against the labor pool the budget allows. The operational goal is explicit: execute below budget, because the gap is the margin.

5. Procurement and suppliers

Purchase history by supplier: what was bought, at what price, from whom and when — so purchasing decisions rest on the record rather than on whoever remembered the last quote.

6. Warehouse and material movement

Inventory across warehouses, with visibility into how much material moved from one warehouse to another and to which project it was assigned.

7. Schedule tracking

Project timelines with progress visible at any moment — where the work is, where it should be, and which fronts are falling behind.

8. Budget vs. actual variance

The control module. Budgeted consumption against actual consumption, per material, per labor tier, per project. This is what converts data into an early warning: if the project is at the halfway mark and the cable is already gone, something is seriously wrong — and it is visible now, not at close-out.

9. Biweekly progress reports

Every two weeks the team registers executed work and the system produces the progress report: what was completed, and what is to be billed for it. The document that used to be assembled by hand became an output of the system.

How it works: from drawings to billing

1. Register the materials. Every input the company installs, each with its current price and purchase history.
2. Build the Unit Price Analyses. Compose each unit of work from the materials it consumes plus its labor allocation. The system computes the unit cost, and the library is reused on every project that follows.
3. Build the budget. Take off the quantities from the drawings, multiply by their unit prices. The result is the project budget, its material consumption ceilings and its labor pool.
4. Execute against it. Purchase orders, warehouse movements and staffing are all recorded against those ceilings.
5. Watch the variance. Budgeted vs. actual consumption is visible throughout execution, not after it.
6. Bill it. Every two weeks, executed work becomes a progress report — the client-facing record of what was done and what is owed.

What this engagement says about how CodeBranch works

• Definition before code. Three discovery sessions, requirements documentation, wireframes and mock-ups before development — the practice that is now formalized in CodeBranch’s Spec-Driven Development (SDD) framework, where every project opens with a Product Definition phase and per-feature estimates.
• Domain first, software second. The system is organized around Unit Price Analysis, progress reporting and real site roles because that is how construction works in this market. Generic project management software fails here for exactly that reason.
• Custom where custom pays. Nothing here was configured on top of a generic platform. The data model — materials, unit prices, labor tiers, progress reports — was built to match the operation, which is why the operation could lean on it.
• Ship, use, grow. The tool expanded module by module, driven by what the operation actually needed next.