Where custom is most often justified and most often regretted
We push hard toward extending a mainstream platform before building anything from scratch. Building wins when an industry’s workflow genuinely has no product behind it. Either way, moving your history across is the largest part of the work.
In short: Most companies who ask for a custom CRM or ERP are better served by configuring and extending an established platform. A minority genuinely are not, and for them a build is the right call. We will tell you which group you are in before you commit budget, and we will be blunt about the migration.
Why we argue for the platform first
A custom system starts life matching your process exactly. That is the appeal, and it is real. What people underestimate is everything the platform vendors quietly carry on your behalf afterwards: permissions, audit logs, mobile clients, reporting, tax and compliance updates, single sign-on, an ecosystem of connectors, and a hiring market of people who already know the tool. Build from scratch and every one of those becomes a line item you own forever.
The regret usually arrives in year three. The system still works. It is just that the person who understood it has moved on, three features have been requested that the original data model resists, and the annual cost of keeping it current has settled somewhere nobody planned for. Ask any team running a custom internal system of that age and you will hear a version of the same story.
So we start by trying to break the case for building. Can the standard object model hold your data if you rename a few things? Is the unusual step actually unusual, or is it a habit? If a platform covers most of it, we extend it with custom modules, scripted automations and a few purpose-built screens, and you keep the vendor doing the heavy lifting underneath.
Configure first
Objects, fields, pipelines, roles and automations inside the platform. Slower to admit, faster to live, and cheap to change when the process changes.
Extend where it stops
Custom screens, calculations and modules bolted onto the platform for the parts it does not model. The vendor still handles the rest.
Build the true gap
A separate system for the workflow no product serves, connected to the platform by an interface rather than merged into it.
Keep an exit
Whatever the shape, your data comes out in a documented format. Systems outlive the reasons they were chosen.
When building is genuinely the right call
Some industries have never had a product built for how they work. Specialist manufacturing with unusual batch rules. Field operations where the unit of work is a route rather than an order. Trades with regulated paperwork that generic products treat as a note field. In those cases the platform fights you: everyone spends their day translating real work into the shape the software expects, and the translation becomes the job.
The test we use is simple. Is the awkward part of your process the thing that makes you money, or is it just an old habit? If it is the source of your margin, protect it and build around it. If it is habit, adopt the standard and save yourself years of maintenance. That conversation is usually short and occasionally uncomfortable.
The migration is bigger than you think
This is the part that gets a single line in most plans and then eats the schedule. Ten years of records built up under three different sets of rules, with a field that changed meaning in 2019, duplicate customers created by a since-departed sales team, and orders whose statuses no longer exist. None of that is visible until you try to move it.
We treat migration as its own project with its own plan. Profile the data first, so the mess is on the table early. Agree what gets cleaned, what gets archived read-only, and what genuinely has to come across live. Then rehearse the load repeatedly, and reconcile after each rehearsal: record counts, financial totals, open items. If the numbers do not match the old system, we do not go live. Where the tangle is mostly about records living in several places at once, our CRM data integration work often solves more than a new system would.
Cutover deserves the same care. A weekend switch with no way back is a gamble, so we plan a rollback, keep the old system readable for a period, and pick a quiet week in your calendar rather than ours.
What we won’t do
We won’t build from scratch when configuration would do
It is the larger project and the larger invoice, and that is exactly why we test the case against a platform first. If an established product covers your process with sensible setup, we will tell you and lose the bigger piece of work.
We won’t go live on data we cannot reconcile
If totals in the new system disagree with the old one and nobody can explain the difference, the launch waits. A go-live date is not worth a year of people quietly distrusting the reports.
We won’t rebuild your current process without questioning it
Some steps exist because of a rule that lapsed, a customer you no longer have, or a system you retired. Encoding those into a new system makes them permanent, so we will ask why each one is there.
Should you build this, or configure it?
Describe the workflow that no product seems to fit. We will look at it against what the platforms can already do and give you an answer either way.
How do you decide between extending a platform and building?
We test whether the awkward part of your process is the thing that makes you money or simply an old habit. If a platform can hold your data with sensible setup, we extend it. If the workflow has no product behind it at all, building is justified.
Why is migration usually the largest part?
Because years of records carry rules that changed, fields that were reused for something else, and duplicates nobody logged. Profiling, cleaning, rehearsing the load and reconciling the totals afterwards takes longer than most of the feature work.
Do we have to move everything across?
No, and you probably should not. We usually move what is live and operational, archive the rest in a readable form, and keep the old system available to look at for a period after cutover.
Can a custom system work alongside the tools we keep?
Yes, and that is often the better shape. A separate system for the specialist workflow, connected by documented interfaces to the accounting or CRM platform you keep, ages far better than one system trying to be everything.
