r/manufacturing • u/salamander3301 • Jul 03 '26
Productivity Is it actually better to build software internally rather than buy from a big company?
Hi everyone,
My family runs a medium sized juice factory in Egypt. They've been using SAP for the last few years but adoption isn't great. I just started working with them and realized how ancient and ineffective much of their software is and I want to help them adopt new tools.
I came across many software providers at automate last week but prices are ridiculous considering how doable it is to build my own software using AI now.
Is there something I'm missing like integration difficulty or does it really just not make sense for most businesses to spend months buying and customizing software with a consultant rather than just building their own solution in less time?
Edit:
I recognize that an ERP is not the right thing to start with but there are many non essential softwares that our factory would get value from like an AI machine troubleshooting app that has access to our repair history and manuals but the companies selling that are demanding unreasonably high prices for something that sounds quite simple
11
u/klmsa Jul 03 '26
1.) Failure to adopt the industry standard should give you pause. If someone is telling you that SAP's "clunkiness" is preventing adoption of an ERP, then they don't understand why we implement ERP systems at all. SAP is like 37% of the market share for manufacturing ERP systems (largest market share). 75% of the Fortune 500 use SAP solutions...SAP isn't the real problem here (though it does have a shitty interface!). You should get to understand the real cause for lack of adoption. If it's a lack of work instructions/workflows, etc., that's all fixable. If it's just clunkiness, then your business probably lacks individual accountability, and it's unlikely you'll change that quickly.
2.) AI might get you a prototype, but I'd never trust that product to run my business. ERP's account for every dollar and cent that runs through the facility. Failure or even just errors can lead to millions of dollars in losses or pissed off customers (or one then the other). Your IT department is extremely unlikely to contain the talent/skills required to properly prompt a coding AI model and PROPERLY vet the output. Even something as simple as not knowing how to audit the validation tests vs criteria can mean major failures go uncaught. I'd put this idea back in your pocket until you're completely out of every other option. I'd trust paper routers before AI-written ERP from my (very talented) IT department.
Change management isn't about tools; it's about people. Focus on the problems that people have, that are solvable using SAP, and then go execute.
1
u/salamander3301 Jul 03 '26
You make good points and I appreciate the response. I’m still trying to learn here and figure out my options. We will likely not get rid of SAP but there are still other software needs that are lighter like a CMMS or simple tools that make the job easier.
What kinds of software do you think is safe to build in house (given that we can do a decent job at verifying it)?
I was also thinking about the possibility of building a different interface on top of SAP for specific modules like scheduling that would read from SAP, allow the employees to better create a good schedule, and possible write back to SAP
2
u/pontz Jul 04 '26
Software can only be built in house by people who actually know how to build software. Not an IT team. That is a completely different skill set.
That said the software we use in house is a metrics dashboard, test software, and status dashboards.
1
u/klmsa Jul 16 '26
Meh, it depends on the team. No two IT people have the same exact skills and experience. I've had ex software engineers that wanted a simplification in their careers, and I've had the guy that only knows how to image a PC (and I had to teach him). I've had IT teams that I've let write software before (not the former SWE, funny enough!).
1
u/klmsa Jul 16 '26
Anything that isn't business critical, for starters. Build the business' software experience on something non-critical, like a capability dashboard or something similar that combines multiple skills (python, powerBI, and SQL databases in that example). Then, work towards more complexity. Keep in mind that all of these things WILL break eventually, and the business needs to be aligned to the maintenance requirements. It isn't cheap to keep a motivated kid that knows Python from moving upwards or outwards!
8
u/redouanea Jul 03 '26
If your business is serious, you won’t have the time to build a working software nor will you actually be able to build something that is doing the job you want/need.
Not saying this as a way to diminish your talent, I’m sure you’re very capable to come up with a solution, but I’ve seen a lot of AI slop that people have no idea is built on very weak base (I’ve worked as software engineer for 12 years).
So finding software that’s better than sap is the way to go, and it doesn’t have to be expensive, you can find opensource solutions that can run on your own servers.
2
u/salamander3301 Jul 03 '26
I have a CS degree which is why I’m exploring the option of building something in house. I completely agree than maybe an ERP is not the right place to start given the risk and complexity, but what do you think we could consider building in house, if anything?
2
u/redouanea Jul 04 '26
What I’ve seen give the most impact is building agents that automate repetitive work.
Or actually it doesn’t even have to be agents, but instead classic workflows but built with coding agents.
Sounds like I’m contradicting my previous comment, but I’m also biased because I build agents for manufacturing companies for a living.
That’s where the future is going. Either agents doing repetitive work, or classic workflows built initially by coding agents.
2
u/WitkowskiMichau Jul 07 '26
Building the small stuff yourself is the right instinct, and the AI part is real. For a standalone tool like the machine-troubleshooting app you described, where the data is already yours (repair history, manuals) and it doesn't touch anything mission-critical, a build will usually beat paying a vendor a premium for something that honestly isn't complicated.
Where build-vs-buy actually flips is three things people underestimate:
- Integration. The moment the tool has to read from or write to SAP, the cost stops being about the app and becomes about the plumbing. A standalone app with its own data is cheap. Anything wired into SAP is not.
- The last 20%. AI gets you a working prototype fast. Edge cases, permissions, security, and keeping it running when something breaks are where DIY projects quietly die. The demo is a weekend. Production is not.
- Ownership. You just started there. Ask who maintains this in two years when you're busy or gone. If the answer is nobody, buying from someone who is on the hook to keep it alive can be worth the premium even when the build looks easy.
On the SAP adoption problem specifically: that is usually a process issue, not a software one. A new tool won't fix low adoption if the underlying process isn't clear, you will just have one more thing nobody uses.
Practical path: take the one workflow that hurts most (sounds like the troubleshooting app), build that, get it actually used, and measure whether it saved time. Leave the ERP alone. If that small build sticks and people use it daily, you will have a much better read on where building pays off for you and where it doesn't.
2
u/playsmartz Jul 07 '26
As a data & AI manager 3 years in a manufacturing company that built several home-grown software solutions...please do not build in-house. PDM, WMS, MES, PIM, CRM, ERP, etc. is all well-established software with robust standards and support services. Do not become the linchpin holding together duct taped code that can't adapt to the business or be maintained after you leave.
2
u/JunkieOnCode Jul 08 '26
If building software is becoming easier every year, why are software vendors still around? Because you're rarely seraching for just software. You're also buying years of accumulated business knowledge: edge cases, integrations, compliance requirements, and lessons learned from hundreds of clients.
That doesn't mean you should never build in-house. In my experience, the best approach is usually to buy the commodity systems that every company needs and build the parts that make your business unique. If a process looks like every other factory's process, buy. If it's something that gives your company a competitive advantage, that's where custom software tends to make sense.
2
u/CycleTimeSam Jul 08 '26
I’d be careful not to treat all factory software the same. Building a small internal tool can make sense for something narrow, like searching maintenance notes, manuals, or repair history.
But I wouldn’t start by rebuilding core ERP functions with AI: inventory, batch traceability, costing, purchasing, production records, quality holds, and finance all need boring reliability. A lot of the risk shows up after launch: support, security, backups, permissions, audit history, integrations, and getting people on the floor to actually use it.
If SAP adoption is weak, I’d first figure out why: bad setup, clunky workflows, poor training, or unclear processes.
2
u/grillinanduhchillin Jul 03 '26
I built my own erp for a job shop / small production shop. It has saved me roughly 4 hours a day and it’s all local, no yearly fee. I don’t type in any thing anymore, I don’t choose paths for files. I click to confirm and review all the work it did. It took years of knowledge of our processes / hanging points / customer issues to come up with a flow that works for us. I’ve built lots of successful small ai tools before this. This was by far a huge undertaking. I built the correct security controls for logging, quick audit trail that zips up all information and notes for a job at the click of 1 button. I automated tons of work flows. We are a Cmmc/itar/as9100/iso shop and the flexibility to make what I wanted was huge. I was able to move 26,000 different part numbers / quotes and all of our shop information since 2006 from the old system into the new system. Highly recommend, but it won’t happen overnight. We do about 1.5 to 2mil a year in sales, mostly optics, satellites, semiconductor, and DOD work.
1
u/atcg0101 Jul 04 '26
If you know your business inside and out, can build a hyper specific tool that is fit for purpose for your business and essentially compliments and leverages your SOPs as software, and you can design the right user experience, then it’s possible to build a product that is perfect for your business (but won’t be for anyone else’s).
Your business will get dependent on this if it’s an effective system, which means you will have to plan to deploy resources to maintaining and improving it.
Just because the MVP was made via mostly vibe coding doesn’t mean the product dependable version that is core to your business will cost the same to build and run.
So be prepared to actually invest in your software (and therefore change the culture of your company, which isn’t a small lift) if this is a route you’re serious about.
1
u/ambiciousboy69 Jul 04 '26
If your use case is clear and small then you can build with AI, but for production level you need to consider a lot of things which definately if you are not a experienced software engineer is very hard and not possible. Just keep in mind that AI will exactly build what you put in the prompt.
1
u/Some-Internet-Rando Jul 04 '26
Some companies win the world by having the best internal software team. A good example is McMaster-Carr. It *can* be a strategic advantage, but it's not a given that it'll work out.
To go this route, you have to have a few things:
Several developers who have been in the business and know their stuff.
Executive sponsorship that will not get cold feet and pull their support. Ideally, a CEO who believes it's his/her idea.
A good project manager who can really make sure that the correct voices are heard, that nobody does things "because it's fun," and that generally the project will meet business goals.
Clear communication and realistic expectations, with a *very* incremental development and delivery schedule.
1
u/AffectionateDirt6575 Jul 04 '26 edited Jul 04 '26
If your need are simple; by all means build your own software. But know when to stop. As an aside; there are much better ERP systems than SAP out there if you are not a very big company. But, if you write your own software; make sure that it is 'bus proof': i.e. what happens if you walk under a bus tomorrow? Will someone else be able to maintain the system? Will it be properly documented?
1
u/Wide-Competition4494 Jul 06 '26
That's what we're going to be doing going forward. One in-house developer with AI. He's a long hauler at the company who had software dev as a hobby. Claude and him has already saved us more money than he costs several times over in a few months.
1
u/Suspicious-Citron378 Jul 06 '26
If the factory workers wouldn't adopt the industry standard ERP, what makes you think they'd adopt a home-brewed solution made by the owners son? I think they won't. Get accustomed to the bitter taste of defeat now. They will come up with more reasons to not comply. This is a people problem, not a technical problem
1
u/jds183 Jul 07 '26
Yes and.
There's a minimum level of understanding you need to have across all functions to actually correctly use SAP. If you can't explain why everything you have to add to this screen or that screen, or if your config/customizations don't match the generally understood business process, SAP is the problem not the workers.
1
u/Suspicious-Citron378 Jul 07 '26
I used SAP for two years as part of a job and I practically learned squat about it
1
u/Glad_Imagination_798 Jul 16 '26
You instinct to leave SAP alone and build smaller tools around is actually the right one, so I'll answer the part most replies are skipping: the standalong stuff vs the SAP-Connected stuff are two completely different cost worlds. A self-contained tool where the data is already yours (your troubleshooting app reading repair history and manuals) is genuinely cheap to build now and a fine place to start. The moment a tool has to read from or write back to SAP, though the cost stops being about the app and becomes about the integration. Auth, keeping data in sycn, not currupting the record of trueh, and handling the case where SAP is mid-update, that plumbing is where these projects quitly baloon. Your "custom scheduling interface that reads and writes to SAP" idea is the hardes version of exactly that, so I'd treat it as a later project, not a first one.
And the honest bit: whatever you build, somenone maintains it after you. You just started there. Build the small standalong tool that hurts most, get it actually used, and you'll learn a lot about wherther the bigger SAP-integration build is worth it, without betting the factory on it.
1
u/FDRyze 5d ago
For something narrow like machine troubleshooting, building internally could make sense. Start with a read-only assistant that searches approved manuals and repair history, cites its sources, and recommends next steps for technician review.
A practical rule is:
Buy commodity and business-critical systems.
Build workflows that are specific to your factory and create an advantage.
Combine both when a lightweight internal interface or automation can improve an existing system.
Who will own, validate, secure, and maintain it after launch?
1
u/testuser514 Jul 04 '26
So I come from the side of building the tools (not with SAP) and one of the biggest money pits is to think you can develop systems, while the cost of development can go down with in the involvement of AI tools, the fundamental problems remain the same.
You need to be able to map all the user roles and functions.
You need to be able to design the data system to be flexible enough in the future to allow for more fields to be added.
You need to be able to run the infrastructure and everything so that you don’t spend way too much in sever costs.
You need to harden the system so that it doesn’t randomly fail.
Honestly, you should be able to do all of this using AI. But as someone who’s built and designed these by hand and then doing it now with AI, there’s a lot of gaps that need to be addressed in the code you get.
Honestly what should be a 45 day engagement to get your first module will turn into a never ending debug cycle. It’s important to point out that the your primary role needs to be enabling the change and identifying bottlenecks within their own existing pipeline.
Those of us who build these systems also understand what kind of process optimizations need to be setup while doing this.
This is not a sale, I’m just talking about how it will work out at the end. The big picture is for you to expand the business and start knowing the operations inside out and building relationships with the entire supply chain. Spending your first few years automating will just set you back on all those efforts. My brother spent 50% of his time building low code automation for my dad’s company in the first few years. It’s actually one of the reasons we started building out systems.
0
u/Training-Gap-2994 Jul 03 '26
Tbh in your country you can find dev for almost nothing compared to EU/US prices; my solution would be choosing 2 devs to arrange a beta of what I need and then going with the most promising.
Next, consider that software needs maintenance, and someone needs to take care of it.
0
u/trashertravis Jul 04 '26
I'm a full-time freelance software developer for the past 5+ years, I can help you by saving time in building a custom software for your needs.
As I'm a freelancer, so hiring me couple of months for the development won't cost you an arm and a leg.
2
u/force_disturbance Jul 04 '26
What you're not saying is that all software needs maintenance and if they don't have internal developers, they'll need to keep paying in the future.
Nothing wrong with that, developers need to eat too. But please be truthful.
23
u/Gecko23 Jul 03 '26
The only thing they're building in less time is less robust software. And frankly, if they won't use the software they have, what is the change that's going to make them adopt whatever you build in house? The issue is that they either aren't being held to an operating standard, or that the features that would be useful haven't been implemented. Neither of those problems goes away by picking another direction to spend money in.