What 10 Years in IT Services Didn't Teach Me About Manufacturing ERP

I have been writing code for over 10 years. I have built enterprise software for travel technology and for medical devices. I have shipped products used by thousands of people. I thought building an ERP for manufacturers would be a straightforward application of everything I already knew. I was wrong about almost everything.

The first thing that surprised me was how purchase orders work in manufacturing. In the IT services world, a purchase order is a simple transaction — you order something, it arrives, you pay for it. In manufacturing, one PO can have deliveries spread over three months. The supplier ships 40% now, 30% next month, and the remaining 30% whenever raw material is available. Each delivery has its own quality inspection, its own GRN, and its own payment terms. A single purchase order can generate a dozen transactions before it is fully closed.

Sales commitments were equally complex. A customer places an order for 10,000 units. You deliver 3,000 this week, 4,000 next week, and the final 3,000 after a quality hold is cleared. Each partial delivery needs its own delivery challan, its own invoice, and its own payment tracking. The order is not done until the last unit is shipped and the last rupee is collected — which can take months.

Then there is pricing. In IT, you quote a rate, the client accepts or negotiates once, and you move on. In manufacturing, pricing negotiations can last longer than entire software projects. A customer asks for a quote. You send it. They come back asking for a 5% discount on items A and B but want a different finish on item C that changes the cost structure. You re-quote. They accept items A and B but want to split item C into two separate line items with different delivery dates. The quotation goes through four revisions before the first purchase order is raised.

Material management was another revelation. In software, your raw materials are developers and cloud servers — both relatively predictable. In manufacturing, your raw material could be MS plates that are available in the market this week but not next week. Or it could be a specialized alloy that has a 45-day lead time and a minimum order quantity that is three times what you need for this particular job. Inventory management is not a feature — it is the central nervous system of the business.

The biggest lesson was about building products versus building services. In IT services, the cycle is clear: understand the requirement, build it, ship it, move on to the next project. Client is happy, invoice is paid, everyone wins. In product development for manufacturing, you cannot move on. You have to understand why the business works the way it does. Why does the factory owner insist on partial deliveries? Because his customer insists on partial deliveries. Why does he track inventory by weight instead of units? Because his raw material is sold by the kilo, not by the piece. Why does he need three different price lists? Because he has three different customer segments with three different margin structures.

Every feature request has a story behind it, and that story is rooted in how physical goods move through a factory — from raw material receipt to finished goods dispatch. If you build the software without understanding that physical reality, you end up with a system that is technically correct but practically useless.

This experience has fundamentally changed how we build SAMaGRA. We do not start with feature specifications. We start with factory visits. We watch how the supervisor creates a work order. We see how the dispatch team loads a truck. We understand why the accountant reconciles stock every Saturday morning. Then we build software that fits into those existing workflows instead of forcing new ones.

If you are a software engineer thinking about building for manufacturing, my advice is simple: spend a week on a factory floor before you write a single line of code. Watch how things actually work. Talk to the people who do the work every day. The gap between what you assume and what actually happens is where most ERP products fail — and where the real opportunity lives.