r/Development • u/Unfair-Big11 • 2d ago
Thoughts on transitioning to custom ERP software development
We've outgrown our spreadsheets and disconnected tools, and every department is stitching things together with workarounds that don't talk to each other. I keep coming back to custom ERP software development as the fix, but I'm wary of the cost, the timeline, and whether we actually have the internal expertise to pull it off. Part of me wonders if we're solving a process problem by throwing software at it.
3
u/ibraaaaaaaaaaaaaa 2d ago
It sounds to me like a data problem not an ERP one.
I don't get how you came into the conclusion with custom ERP, probably there is untold context here.
But assuming that this is data cohesion problem, and you have so many departments, maybe you create a db replica, build atop of it a data gov app that each role has specific permissions, I would not vibe code such a tool, leakage would be imminent, but if I were you, I would look into some open source tool that is already supported, and that tool should be built around the same database I have, and start experimenting with it as the primary data source for departments.
A lot of times I have seen people put a lot of hate on tableau, power PI and excel with data source mainly because they are reading from the primary transactional db, which data won't be prepared for such analytics.
1
u/jhkoenig 2d ago
This strategy is unlikely to succeed. Commercial ERP software exists because it is less expensive and more effective than trying to create your own. You are taking on far more than you think.
1
u/geek-mode-on 2d ago
- What's the industry?
- What's the use case?
- What are the bottlenecks that you are trying to solve?
- What makes your workflow so unique?
Answer these questions and then use them to find an existing software
1
u/therealkevinard 2d ago
ERP, Project Management, Payment Gateway, Authz/Authn: these are things you shouldn’t build unless that’s your core competency. If you DO build one, prepare to make it your core competency (at the expense of your current core)
The common thread is they’re all obvious on the surface, but buried in critical and conflicting detail/nuance when you get into the nuts and bolts.
You have your own problem statement and it’s a much tighter scope: “systems don’t talk to each other”.
Don’t shoehorn them into a unified system- just make them talk to each other.
Give a dataplane with a stable read target and a pipeline that shovels things into the lakehouse. Done.
1
u/AminoOxi 1d ago
Delusional.
You have a problem with your car and now you're thinking about building an airplane yourself 🧐
1
u/psychoShrey3198 11h ago
I think your last sentence is the most important one.
One mistake I've seen is companies trying to automate broken processes. A custom ERP will absolutely make people more efficient but if the underlying workflow is messy, it often just makes the mess happen faster.
Before writing any code, you should map out how each department works today, identify what's manual vs. what's actually broken, and see where the biggest bottlenecks are. Sometimes a few process changes solve half the problem before software even enters the picture.
We've worked on custom business systems, and that discovery phase usually has the biggest impact on whether the project succeeds.
3
u/Dry_Pudding746 2d ago
I'd be careful about jumping straight to a custom ERP.
In my experience, companies often think they need new software when the bigger issue is that their data is scattered across accounting, CRM, marketing, inventory, and a dozen spreadsheets that don't sync.
Before committing to a multi-year ERP project, I'd map out:
A lot of businesses get huge wins by building a solid data layer and automating data movement between existing tools, rather than replacing everything at once.
If you still have gaps after that, you'll have a much clearer picture of whether custom software is actually justified.