I was part of a team for 12 years and watched it for longer, that helped a company on a journey exactly like this. I don't really want to get caught up in phone

I was part of a team for 12 years and watched it for longer, that helped a company on a journey exactly like this. I don't really want to get caught up in phone calls because I need to focus, but here's some of it. Rough version: - Outsourced to a company. Supposedly top people. - My friend joined that company. He threw his heart into it. Eventually, he got the contract. He was the only person fully committed to the success, and the outsourced company was committed but not to the same extent. The key here is that he had extreme ownership over it and threw his being into making it work, and he was (became) very good with people - devs, execs etc., while helping to make enough of the right technical choices. - He made a lot of money, because he was helping a significant business during a lot of churn as they grew. He helped them a lot, over 25+ years. - At some point I joined them for far too long, but I learned a ton of what was good and bad about this. - The company bought a few others as they grew, rolled this system out to those companies. It worked well for them. - Even in this case, helping them be the biggest in their (local) industry, they eventually wanted to move to a big-boy system. The lines of custom code become paper cuts. Arguing over budget, infinite demands from across the company. Friend, as always, helped them in every way possible to get the right result. - Friend helped them move from a custom system to an ERP + custom. That hasn't been plain sailing, it's extremely hard to move from a custom solution because it fits like a (sometimes hairy) glove. Over the long term, probably the right move. But you lose a lot of time in the switch, time that could be spent beating competitors. He was fully dedicated to the customer success. He charged extremely well, it made him financially. He owned it. You absolutely need ownership, and you need a smart person owning it. He knew that his success lay in always putting them first. If you can hire that person, great, but in this case the money helped him be fully committed, for an extended period of time. I later spent time at a startup bank, where we assembled an incredible system out of build + buy, with a SAP core. This will absolutely trigger the HN crowd but it was an excellent base. You do not want to be figuring out how you do rounding, or multi-currency, or storing user data. You do not want to be responsible for every line of code in your stack indefinitely. You want to know what is yours to own and build and will help you differentiate, and what is important to have but will just get you parity (e.g. accounting, invoicing, marketing, whatever). You don't want 100% custom code unless software is a big part of your business and it'll give you an edge over competitors, because it's both an asset and a liability. The thing to keep in mind here is TCO - Total Cost of Ownership. A good ERP will help you roll out business features really fast without having to reinvent the wheel. Don't modify too much of the ERP where it's not really important to do so, rather use as much standard tooling as possible, because you need to own all the changes. There are also absolutely risks here. SAP deployments can crush companies. Skills. You want a setup that has easy access to skills, indefinitely. It's very hard to build something and know that it'll always be in fashion. React will one day go the way of COBOL. The team replaced the front-end a number of times and kept the core database. That stable core was the best thing they had, for a very long time. Remain agile. If a component or team isn't working, switch. Don't marry every technology. In the bank, we switched very large pieces out and it was always the right choice. CRM, API Gateway, messaging technology, hosting technology for some parts of the stack. Be careful what you depend on. Every part of the stack wants to make you dependent on them. Try to avoid a big boolean switch when you turn off the whole system and move to the other one. If you can strangle the old system and chip off pieces as you learn, great. Sometimes it's not possible and you're in for a lot of weekends while you check the new one does everything the old one did, and doesn't fail in some weird way.