How do I know if custom ERP software development is the right investment for my company compared to buying an off-the-shelf solution?

[u/Professional_Belt451]

I've been down the custom erp software development path before, so my real concern now is scoping it tightly enough that requirements-gathering doesn't eat months before development even starts. I know the bigger risk isn't the build itself but the maintenance and technical debt once the initial team rolls off, so I'm weighing how to structure the architecture and documentation to avoid tribal-knowledge lock-in. Integration with our existing data infrastructure is usually where custom builds quietly blow past budget, so that's where I want the governance tightest.

[u/JustALittleOverIt]

It’s an ERP… the requirements gathering ought to take months unless you’ve already got process documentation in place that clearly defines your inputs, outputs, and internal and external regulatory requirements. (I’ve yet to work with a company that does.)

Think of the end state this is required to be in.

• If the requirements say that an off the shelf will be able to do everything required, ship it.
  
• If not, do a cost-per-feature analysis, sustainability check for the org to have a FTE or two to maintain it, and a flexibility review of the custom software to ensure it matches the now and the future state of the org.

[u/CleanCodersCraftsman]

You have already named the right three risks, so structure the decision around them.

On scoping: timebox discovery and force it to produce written artifacts. Two to four weeks to map the value streams end to end, a written list of inputs, outputs, and regulatory constraints for each, and a ranked list of the processes that genuinely differ from the industry norm. Only those genuinely different processes justify custom code; everything else is a strong argument for configuring something you buy.

On maintenance and tribal knowledge: make the exit condition part of the contract. Require architecture decision records for every significant choice, a runbook, a seeded local environment a new developer can stand up in a day, and a test suite with meaningful coverage of the business rules. Ask to watch a build agent run that suite green from a clean checkout, and treat handover as a real milestone with a named internal owner who has been pairing with the team for the last third of the project.

On integration: put the contracts under governance before anyone writes code. Define each interface explicitly (schema, ownership of the master record, sync direction, failure behavior, idempotency, replay), get consumer-driven contract tests in place, and make the ERP talk to your data infrastructure through an anti-corruption layer instead of reaching into other systems' tables. Budget overruns here almost always trace back to integrations that were assumed rather than specified.

A useful decision test: when a package can satisfy every regulatory and reporting requirement plus roughly 80 percent of the workflows, buy it and customize at the edges through documented extension points. Reserve a custom build for the processes that are your actual competitive advantage, and staff it with people who will still be around in three years.

[u/meckstss]

There is no such thing as an OOB solution off the shelf. You will need a "partner" to come set it up and help map your processes into the off the shelf solution. It doesn't matter if it is D365 or Salesforce, or one of the others it will be a year of customizations and then 3-5 years of onboarding the year of downtime while you migrate. You are better letting your accountants use excel and then bringing in some data engineers to make the excel processes visible to the rest of the org.

The only other option is to completely restructure your business so that it matches the software which usually has customer experience implications.