The honest answer to “should we build this?” is usually no. Most business problems are shared problems, and a mature subscription product will beat a custom build on price, speed and reliability for at least the first few years. We say this to prospective clients regularly, and it costs us work — which is also why it is worth something when we say the opposite.
The real question: is your process the product?
Custom software is not better in the abstract. It is better when the thing that makes your business work — a way of pricing, scheduling, dispatching or reconciling — is something no vendor models.
In that situation, configuring an off-the-shelf tool means encoding your differentiator as a set of workarounds: custom fields, exported spreadsheets, an administrator who knows the trick. That is not cheaper. It is the same cost paid in staff time and fragility rather than in development.
Four questions that separate the cases
First: how much of the tool would you actually use? If the answer is under a quarter, and the missing quarter is the part that matters, configuration will be a fight.
Second: what does integration cost? A tool that cannot exchange data with your inventory, accounting or POS creates a recurring reconciliation job, and that job has a salary attached.
Third: what is the switching cost if the vendor changes pricing, is acquired, or sunsets your plan? Fourth: who owns the data, and can you get it out in a form that is usable rather than merely compliant?
The middle path is under-used
Buy the commodity parts — accounting, email, payments, storage — and build only the layer specific to you, connected by APIs. Most of the systems we deliver are exactly this shape: a custom operational core with documented integrations into software the client already pays for.
It keeps the build small, which keeps it affordable, and it puts the custom work where it earns its cost.
Write the workflow down first
If you are making this decision now, document the workflow causing the pain before you look at any tool or talk to any developer, including us.
Nine times out of ten the document itself makes the answer obvious. In the tenth case, it becomes the specification.
Working on something this touches on? Tell us what you are building — we will say honestly whether we are the right team for it.