Note
Templates Over Custom Builds: Why Picking Beats Designing
The idea is understandable. A contractor who has worked through several software tools that never quite fit eventually reaches the same conclusion: the generic system is the problem. The solution is to build something around how the operation actually runs.
That instinct is not wrong. Generic systems do fail. The question is whether a custom build is the right response, and what it costs while you are building it.
Why Contractors Reach for Custom Builds
The frustration that drives the decision is real. Past systems typically fail in recognisable ways:
- Too many fields nobody uses
- A job structure that assumes a different kind of work
- A mobile experience confusing enough that technicians return to LINE
- Reports that do not match what the billing queue actually needs
When software does not fit the work, people stop using it. That is a reasonable conclusion: the software was not built for this kind of business. It is worth separating that from why the last system stopped being used, which is usually a different problem.
The leap from “that system did not fit” to “we should build our own” is where the cost starts accumulating. Building something custom requires knowing, in advance, what the system should do. That knowledge is harder to specify than it appears. The people doing the work know it intuitively, but translating that into a working system involves decisions that ripple in ways that are not obvious until the system is running.
What Custom Builds Actually Cost
The visible cost is the build itself: the developer’s time, the platform, the iterations. The cost that rarely gets counted is the time the operation goes unimproved while the build is in progress.
A custom build for a contractor of 15 to 25 technicians typically takes three to six months from decision to something usable. During that period, the scheduling is still done the old way. Jobs are still closed the old way. Billing is still delayed the same number of days. Nothing changes in the operation because the tool that is supposed to change it does not exist yet.
Work through the arithmetic. If your average days from site completion to invoice is 14, and a functioning system could bring that to 4, those 10 days represent tied-up working capital on every single job that closes during those six months of building. That cost is real, even if it never appears on a project budget.
There is a second problem: custom builds encode your current process. The requirements come from how work runs today, including the habits that cause the delays in the first place. A handover workflow built around how your team currently handles close-out will include the gaps in how your team currently handles close-out. The builder cannot see those gaps from the outside, and the people inside the operation are accustomed to working around them.
Does a Template Actually Fit Your Work?
The objection to templates is usually that the operation is specific. That is true in some dimensions and not in others.
An electrical contractor installing solar or LED systems in Thai factories follows a recognisable pattern: win the project, schedule technicians across site days, dispatch to the site, complete and document the work, close with a signed handover, pass the site to a maintenance cycle. The variables are team size, number of concurrent projects, and the complexity of each site. The underlying pattern is consistent.
Where individual operations feel unique, it is worth asking whether the uniqueness is a feature or a problem. A business that schedules work in a way that no system supports might have a workflow that has grown around a limitation rather than a deliberate choice. Templates make those distinctions visible.
Why Does Fitting to a Template Actually Help?
The thing that makes a good template useful is that it was built around a workflow that is known to function. The template reflects decisions already made about what needs to happen and in what order. A job cannot be closed without a signed handover, a sequence the system will not let anyone skip. A site cannot be marked maintained without a dated record. The inspection calendar raises work before the date catches you.
When a template requires that certain things happen in a certain sequence, fitting your operation to it means confronting whether your current sequence actually makes sense. That confrontation is uncomfortable and it is also productive. The fields that feel like extra work are usually recording things the operation needs but does not currently track. The step that feels like overhead is usually the step that, when skipped, causes the problem you already know about.
A worked example. Consider a contractor whose technicians currently complete jobs by calling the foreman. The foreman updates a shared sheet. The invoice goes out when someone notices the sheet. A template that requires a phone-based close with a customer signature and a photo upload feels like three extra steps. It is also precisely the three steps that move the close date from guesswork to a timestamp and the handover from a phone call to a document in a file.
FAQ
Won’t a template force us to change how we work?
In some places, yes. The question is whether the way you currently work is producing the results you want. If billing is delayed, if return trips happen because documentation was missing, or if a site’s warranty status requires a phone call to figure out, those are signs the current workflow has gaps. A template that enforces a better sequence is not a constraint: it is the fix.
What if our operation has workflows the template does not cover?
Most electrical contractors doing factory installs are more similar than they think. If a specific workflow genuinely has no equivalent in the template, investigate whether that workflow is necessary or whether it grew around a limitation in a previous tool. Occasionally the template needs adapting. More often the workflow does.
How long does it take to fit an operation to a template system?
For a contractor with 8 to 40 technicians handling 2 to 10 projects per month, the core setup including board configuration, job order structure, handover documents, and site register is typically done in a few short sessions. TRACE 30 is designed to be running in 30 days because the decisions about structure are already made.
If you want to see whether TRACE 30 fits how your operation runs, visit /program/ for the full detail of what the five steps put in place, or /schedule-a-call/ to walk through it with the team before committing to anything.