Guest post by Filip Lauc, CEO of Jaspero.
Most companies ask the build-or-buy question once, for the whole project, and get a poor answer either way. This article gives you a way to sort your operation workflow by workflow: what a standard system should run, what deserves custom software, what should stay manual and what should simply stop. It ends with the one rule that keeps the pieces from fighting each other afterwards.
"Should we buy an ERP or build our own?" is the question we hear most often from companies that have outgrown their spreadsheets. It sounds like one decision. It is really a few dozen small decisions bundled together, and the bundling is what makes both answers go wrong. Buy for everything, and the one workflow that makes your business different gets squeezed into a shape designed for someone else. Build for everything, and you end up paying developers to reinvent VAT handling.
The better question is narrower: for each thing your business does every week, where should the rule that governs it live? We have been building custom business systems since 2014, including the back office and apps that replaced a London fitness community's spreadsheets, and six connected systems for a Croatian farm-to-table marketplace. In both, some of the most valuable decisions were about what not to build.
Step one: list workflows, not features
Feature lists come from vendors' comparison pages. Workflows come from your week. Write each recurring piece of work as a verb, an object and a trigger:
- confirm a booking when the payment arrives
- send each driver their route before the first pickup
- issue an invoice once the goods are delivered
- chase suppliers who have not sent their order sheet
Include the rules that live only in someone's head or in a spreadsheet colour. When we started with MOVE & MEET, the London social fitness community, one colour in the booking sheet meant a member had paid cash at the studio, so the payment provider's record would never match. No brief mentioned it. It still needed a home in the new system, and so will yours.
The only reliable way to find these is to sit with the people who do the work for one full cycle, a week of events or one order-to-delivery loop, and write down what they actually do. Asking them in a meeting gets you the process they designed, not the one they run.
The five destinations
Every workflow on your list ends up in one of five places.
- Standard system, as it comes. Your ERP, accounting package or commerce platform runs it with configuration only.
- Standard system, with your process adjusted. The software does it slightly differently from how you do it today, and you change the habit rather than the software.
- Custom software beside the standard system. A separate application that owns its own records and talks to the standard system through its API.
- Manual, with good support. A person decides, helped by a clear screen, a checklist or a spreadsheet.
- Stopped. The work disappears because it only existed to patch over the old setup.
Destination 2 is the one most companies skip. A surprising share of "we do it differently" turns out to be habit rather than advantage. If a customer would never notice the difference, adjust the process and keep the software standard.
Five questions that route each workflow
Ask these in order for every line on your list. The first "yes" decides the destination.
| # | Question | If yes |
|---|---|---|
| 1 | Does this work exist only because of the tools you use today? | Stop it |
| 2 | Is the rule defined by law, your accountant or your bank? | Standard system |
| 3 | Would a competitor describe this workflow in the same words? | Standard system (as it comes, or adjust your process) |
| 4 | Does it break the standard system's data model? | Custom software beside it |
| 5 | Does it run rarely, change often, or depend on judgement? | Manual, with good support |
| – | None of the above | Standard system |
Question 1 clears out re-keying, copying between two spreadsheets that should be one, and nightly checks that two systems still agree. None of it should be rebuilt. It should vanish once each fact has one home.
Question 2 covers invoicing, VAT, fiscal receipts, payroll and record retention. These rules change on the lawmaker's schedule, not yours. Germany's B2B e-invoicing obligation, phased in from 2025, and Croatia's e-invoicing reform, in force since 2026, are the kind of change a standard system vendor implements once for thousands of customers. In custom software you would pay for it alone, on a deadline you did not choose.
Question 3 catches purchase orders, stock counts, quotes, customer records and most of CRM. If every company in your sector does it the same way, a standard system has already met a thousand variations of it.
Question 4 is where custom software earns its place, and the test is concrete: can you describe the thing you sell in the standard system's fields without a workaround? For Plodovi, the Croatian farm-to-table marketplace, the answer was no. A customer orders "one bunch of kale", and at picking it becomes 420 grams at a different price. That order line needs the requested, picked and invoiced quantities as three separate facts, and a platform that thinks a product is a SKU with a stock count cannot hold that without constant patching. If you are already running a standard tool and wonder whether it has stopped fitting, we wrote up the five signals we watch for when a standard tool stops paying for itself.
Question 5 keeps software away from decisions that belong to people. At MOVE & MEET, refunds stayed manual on purpose: the policy was deliberately flexible, and encoding a flexible policy just moves the judgement into a settings screen nobody trusts. At Plodovi, one-off wholesale quotes stayed manual because they are rare and negotiated. Our rule of thumb: if something runs less than a few times a week, or its rules change every season, give the person a good screen and leave the decision with them.
Notice the last row. When nothing matches, the answer is the standard system. Custom software has to earn each line it gets.
Draw the border at the record, not the screen
Once you run custom software beside a standard system, most of the trouble comes from two systems that both believe they own the same fact. The customer's billing address gets corrected in the portal, the ERP still has the old one, and the next invoice goes to the wrong place.
The rule that prevents this: every type of record has exactly one owner. The other system reads it, or asks the owner to change it, and never edits its own copy. Write the split down before anyone builds anything. For a company running a standard ERP next to a custom customer portal, it might look like this:
| Record | Owner | The other system |
|---|---|---|
| Customer legal name, tax ID, billing address | ERP | Portal displays it and sends change requests |
| Invoices and payment status | ERP | Portal displays them |
| Delivery slots and picking results | Portal | ERP receives the final quantities for invoicing |
| Product descriptions and photos | Decide one, explicitly | The other copies, never edits |
Two habits make this hold over years. First, the custom system talks to the standard one only through its official API, never by writing into its database, so the standard system can be upgraded without breaking your integration. Second, when a word means different things in each system ("quantity", "delivered", "active customer"), give each meaning its own name. On Plodovi, leaving "quantity" ambiguous would have turned every mismatch between the shop and the warehouse into an argument about which number was right.
Where custom software does not belong
A practitioner article that only recommends building is a sales pitch. These are the cases where we argue against it.
- Accounting, invoicing, payroll and tax. Question 2 settles it. We have never seen a business advantage in a custom general ledger.
- "The standard screens are clumsy for my team." That is usually a configuration or training problem. Where it genuinely is not, a small custom screen over the standard system's API is enough. It is not a reason to replace the system underneath.
- Heavy changes to a standard system's core. You pay the licence and the custom maintenance, and every version upgrade becomes a project of its own. If a workflow needs deep changes to the core, that is usually a sign it belongs in destination 3, as a separate application beside the system.
- A process you have never run by hand. If you have not done it manually for a few cycles, you do not yet know its rules, and you will pay to write them twice. MOVE & MEET ran on spreadsheets before we built anything, which is exactly why we could find its rules.
And be honest about the trade-off you accept when you do build. Custom software is not a one-off purchase. Our rule of thumb is a maintenance line of roughly 15 to 20 percent of the build cost every year, for dependency updates, small changes and hosting. That cost is worth paying for the workflow that makes you different. It is not worth paying for one that makes you the same as everyone else.
What to do on Monday
Open a spreadsheet (the last one you should need for this) with five columns: workflow, who does it, how often, which question answered "yes", and destination. Fill it in with the people who do the work, not only their managers. Then count the lines per destination.
If the custom column holds more than a handful of lines, go through each one again with question 3 in mind. Then take the sheet to whoever you are talking to, whether an ERP partner or a development agency. A good one will argue with some of your lines, and that argument is worth more than any demo.
About the author
Filip Lauc is the CEO and fractional CTO at Jaspero, a software development agency in Osijek, Croatia. He has built custom business systems for over a decade and now leads Jaspero's AI integration and automation work, retrofitting language models into products already in production for clients like GlycanAge, where his team has been the engineering team for six years.
Comments