Many companies run on spreadsheets, paper forms and chat groups at first. Then one day the data stops adding up, nobody knows who's responsible, and new staff can't learn the process — and the question becomes "should we build a system?" The usual follow-ups: what should we prepare, how do we read a quote, and who looks after it once it's built? Here's what we've learned from our own projects.
Custom isn't the only answer. When a request comes in, we also assess honestly whether custom work fits, or whether another direction makes more sense. A rough guide:
| Situation | Better fit |
|---|---|
| The process is generic (bookkeeping, shift scheduling, basic inventory) and mature products exist | Try off-the-shelf software first |
| Little data, few users, a process that keeps changing | Stick with spreadsheets or online forms for now |
| The process is specific to your industry or company, and off-the-shelf tools need constant workarounds | Custom |
| It must connect to hardware or other systems (GPS devices, RFID, e-paper, an existing ERP) | Custom software or custom integration |
Take the ERP we built for the stone industry: tracking and pricing material through raw stone, slabs, and primary and secondary processing doesn't fit a generic ERP well. That's where custom software earns its keep.
You don't need a specification or technical knowledge. Rather than "we want a system with members and reports", this information helps a developer far more:
We prefer to understand how work actually happens on site rather than work only from a requirements list. Many real requirements only appear once you've watched the work being done.
Custom software has no price list, because every project differs in scale, complexity and degree of customization. We work in two steps:
When comparing vendors, don't just compare totals. Check what each quote includes: which features, which roles and interfaces (web, app), and which devices or systems it connects to. The clearer the scope, the fewer disputes later.
Building everything before launching is the riskiest path: six months in, you discover the process isn't what everyone assumed. We'd rather start with the most painful part of the process, put it into real use, adjust, then extend.
That's how the stone-industry ERP grew. It started as a UHF RFID and barcode digital-inventory pilot; once that proved workable, it expanded to raw stone, slabs, primary and secondary processing, accounts and materials. Primary processing is now live at two companies. See how a stone plant can take inventory with RFID for that story.
With phases, every stage is usable early, user feedback directly shapes the next stage, and the budget is easier to control.
There's no single right answer to these, and practices vary by vendor and project. What matters is writing them down before you sign, not discussing them after something goes wrong:
A system is really tested after launch. More users, process changes, new regulations and new equipment all require it to change too. So when choosing a vendor, look beyond whether they can build it to whether they can support it for the long run.
The fleet platform we built for Yong Fan, for example, has been maintained continuously since we started working together in 2023. It covers location tracking, dispatch, regulatory reporting and in-vehicle video, is used by around 200 fleet operators with 600 devices, and historical video playback is still being developed. See designing permissions for a fleet platform for how a system's design has to change as its users grow.
Working with a vendor for the first time? Bring the forms or spreadsheets you use today, write down your three biggest pain points, and book a requirements interview. A good vendor will keep asking "how do you do it now?" instead of opening with how many features their system has.
If your needs aren't related to e-paper, fleet management or industry ERP, see our Custom App & Web Development service. Tell us how you work today and where you're stuck, and we'll assess feasibility and give you initial recommendations.