Turning Excel Chaos into a Controlled System for Interior Contractors - HUSK DESIGN
The Product
Husk Master Planner is an integrated site- and project-management system built for interior and remodelling contractors in Korea. In practice, the industry runs on fragmented Excel files — a master workbook of construction methods, separate worksheets per site, estimate documents, purchase orders, labour schedules, work instructions, and settlement sheets — all maintained manually, often across different versions on different staff computers. Husk replaces that spread with a single-file web application that pulls from a single master dataset and automatically outputs every downstream document. The engagement later extended past the estimate line into the two things a construction site actually runs on and never records properly: what it spends, and what it says.
Role & Fit
I was engaged as an external consultant on requirements definition and system design. The contractor had deep knowledge of how interior work actually gets done on site and years of accumulated estimate data in Excel. What they lacked was a structured way to convert that operational knowledge into a system specification that a developer could build against. My job was to sit between the operational reality and the technical build — translating how the business actually runs into a data model and module structure that the team could execute.
Context
Interior contractors in Korea share a common operational pattern. Estimates are written from a construction-method master that each company maintains in its own Excel. Once a project begins, the same data has to be reused across purchase orders, labour scheduling, daily work instructions, and final settlement — but because each document is its own Excel file, the data is copied, modified, and eventually drifts. Errors compound. Margin leaks. Staff spend hours reconciling numbers that should have come from one source.
The Excel problem was only the visible half. The other half was that the real operating record of a site — what was approved, what was actually spent, what was decided and by whom — never entered a system at all. Spending was requested by message or phone call and reconciled after the fact, so cost by site and by trade could only be reconstructed at settlement, when it was too late to act on. Site decisions reached the founder as one undifferentiated stream of messenger traffic; because everything reached him, nothing was filtered, and the volume itself became the constraint on the company’s speed. Neither the money nor the decisions were data anyone could query.
Challenges
Three problems to solve. First, the construction-method master was the source of truth, but had an inconsistent structure — missing values, sub-header rows polluting data, and inconsistent classification. Second, project-level and company-level data were intermingled, making it unclear what should be shared across sites and what should be isolated to a single project. Third, the team needed the system to be simple enough to maintain without a dedicated IT department — no build steps, no frameworks that the staff could not open and read.
Two more surfaced as the scope widened. Fourth, expense approval had no gate: the request, the approval, and the record were three separate events living in three different places, which is precisely why the numbers never added up. Fifth, the communication problem could not be solved by summarising messages, because a summary of a hundred messages is still a hundred messages’ worth of reading. What the founder needed was not a shorter feed but a shorter list of decisions.
Approach & Execution
I led the requirements definition with the operator side of the team. We mapped the current Excel workflow end-to-end, identified which fields were genuinely master data versus project-specific, and defined a five-level cascading structure as the backbone of all downstream documents. The calculation logic — subtotal = (material + labour + overhead) × quantity — was locked as the single formula across all modules so that numbers would not diverge. On the system design side, I recommended a single HTML file with localStorage for solo use and an optional Node.js server with WebSocket for multi-user sites, with last-write-wins as the concurrency policy. The architecture was deliberately minimal so the contractor’s team could maintain it themselves.
For spending, I specified a request-and-approval workflow rather than a ledger. Staff submit a payment request from a phone — site, trade, amount, method, and the supporting document attached at the moment of asking — and an administrator approves or rejects it. Every approved request lands in one table keyed by site, trade, and month. The design point is that approval and data capture are the same act: expenditure by site and by trade becomes queryable as a by-product of how the work already happens, not as a reconstruction at the end of the project. The stack stayed deliberately small — a lightweight service with an embedded database behind a single-file front end, running in a container on hardware the company already owned — for the same reason as the planner: it has to outlive my involvement.
For communication, the design principle was subtraction — remove the ninety percent the founder does not need to see. Site messages are compressed into agenda cards rather than summarised: one card is one decision with its options, and everything that is not a decision is discarded rather than shortened. Cards are ranked by a fixed formula weighting urgency, financial impact, customer impact, and whether the decision genuinely requires the founder at all. He clears the queue by swiping, and the outcome routes automatically to delegation or settlement. Decisions already taken on site and merely awaiting ratification are scored down, so retrospective approvals stop competing for attention with decisions that are still open.
Outcomes
The resulting system replaces the scattered Excel workflow with one source of truth. A site manager enters the worksheet once using cascading dropdowns from the master, and the estimate (by space and by trade), purchase orders, labour schedule, work instructions, and final settlement are generated from the same dataset. Errors drop because there is no copy-paste between files; margins become visible because every line item traces back to the master; and the team no longer reconciles numbers manually at the end of a project.
The two later systems buy the same thing in different currencies. Site spending is now a record that can be read by site, by trade, and by month while a project is still running, because approving and recording are one action instead of two. And the founder’s inbound stream is triaged before it reaches him — the queue holds decisions rather than messages, and the ranking sets the order instead of whoever happened to message most recently.
The principle is consistent across all three. An operator will not maintain a system that asks them to produce data on top of doing the work; they will maintain one where doing the work correctly is what produces the data. Every design decision here — the cascading master, the approval gate, the agenda card — is that same trade made in a different place.