Why trade shouldn't be a decision made once and hardcoded
Painting and electrical work don't break into the same sections, don't measure in the same units, and don't model cost the same way. A product that only works well for one trade usually shows it in the details: section names that don't fit, a unit missing from the dropdown, a cost model built around assumptions from a different kind of job.
The alternative is treating the trade itself as something a company configures, not something the software hardcodes. Sections, units of measure, and the cost model should end up as settings that belong to the organization, not the codebase — that is the direction, not a finished migration. Today one trade is fully wired through the estimator; the presets described below currently reach the financials setup, not the full estimate flow.
A preset, not a blank form
Configuration alone isn't enough, but a preset can only responsibly fill in structure, not money. Every trade a company can select starts from a preset built with real domain knowledge: the sections that job normally breaks into and the units it's measured in. Rates start at zero on purpose — shipping someone else's numbers as a default has silently produced a wrong break-even before, so a filled-in form with empty boxes beats a guessed one.
The presets are where the actual product knowledge lives. They get built with someone who works in that trade, not guessed at from the outside.
The tradeoff we're not pretending away
Generalizing a system costs it specificity. The reason a purpose-built estimator is good at one trade is that it knows what drywall mud is and how long it takes to cure: specific, encoded knowledge. A fully generic system starts out knowing nothing about any trade, and only knows what a contractor teaches it.
The presets are the mitigation, not a way to avoid the tradeoff, and they mitigate structure, not price. Ship a trade with the right sections and units so a new contractor starts somewhere sensible, then let their own numbers and corrections fill in what a preset shouldn't guess.
Why the cost model doesn't get diluted either
The same principle applies to how a job's cost is modeled, not just what it's called. A cost model built specifically for a trade that works in daily crew blocks is a good, specific model, and it should stay that way rather than getting stretched into a vague formula that also has to cover hourly production rates or flat markups for a different kind of work.
That's the standard the roadmap is held to: a new trade should get a cost model shaped for how that trade actually prices work, not squeezed into the first one that got built. Today the estimator itself still runs on one trade end to end; this is the design constraint the expansion has to satisfy, not a claim that it's finished.