Most ERP companies start with software and look for customers who fit. We started with factories and built software that fits them.
That is not a tagline. It is how every decision at SimpleGrid gets made.
The lens
Every conversation at SimpleGrid runs through one filter: "Would this work on the floor?"
Not "is this technically elegant." Not "does this match the product roadmap." Not "will this scale to 10,000 clients." The question is always: will the warehouse manager in a 400-person furniture factory actually use this? Will the job worker coordinator managing 20 locations across Bangalore actually trust this? Will the founder running three business streams actually see what they need to see?
If the answer is no, we do not build it. No matter how good it looks in a demo.
Why every factory is different
We have deployed for a furniture exporter where 550 SKUs each have 20+ components, each component requiring different wood species cut to different dimensions. The storekeeper issues material at the component level in cubic feet. The tracking shifts to SKU level at assembly. Contractors are paid per piece per stage, and settlements require reconciling issued quantities minus rejected quantities across multiple jobs.
We have deployed for an apparel operation where production is 100% job work across 20+ facilities, fabric and trims are issued per work order, ephemeral SKUs are generated per order and archived on completion, and three separate business streams share the same job worker network while keeping brand data structurally isolated.
Same platform. Completely different schemas. Completely different rules. Completely different user workflows.
If we had built a "furniture module" after the first deployment and tried to force the apparel client into it, we would have failed. Just like every other ERP vendor fails when they try to standardize what is inherently non-standard.
How we think about deployment
We do not treat deployment as a configuration exercise. We treat it as writing an SG Schema - a complete operational blueprint of how this one factory actually runs.
Day one is a conversation, not a questionnaire. We sit with the founder or the operations head and ask them to describe how their business actually works. Not how it should work. Not how the textbook says it should work. How it actually works, including the exceptions, the workarounds, the rules that only the planner knows about.
We write things down in their language. If they call it a "cutting ticket," we call it a cutting ticket. If they call it a "style," we call it a style. We do not rename things to fit our data model. Our data model adopts their language.
Then AI writes an SG Schema that describes their operation. Not code. A description. The platform reads it and generates the forms, workflows, validations, dashboards, and rules.
The founder sees a working demo in 24 hours. They tell us what is wrong. We fix it. They see it again. We iterate until it matches how the business actually runs.
The team
The founding team has a manufacturing background that is not common in software companies.
The founder built and operated a $30M manufacturing business. Managed multiple factories, hundreds of employees, international buyers. Survived two ERP failures and ended up running operations on Google Sheets. SimpleGrid exists because he was the customer first.
One of the engineers worked in manufacturing at a glass company as a shift engineer from the shop floor up before moving into software. He has stood in a warehouse at 6 AM and knows what it feels like to use a system that was not built for you.
This matters because the decisions we make are informed by operational experience, not just technical capability. When we decide that the chatbot should accept "Got 300 planks from Shree Timber" as a valid input, that decision comes from knowing that a storekeeper has dusty hands, a ringing phone, and 12 more receipts to log before lunch.
What we do not do
We do not build features based on competitor parity. If Epicor has a feature and we do not, we ask: "Does this feature solve a problem our ICP actually has?" If yes, we build our version of it. If no, we skip it.
We do not add complexity to the interface to satisfy edge cases. If a feature serves 2% of users and complicates the experience for the other 98%, we find a different solution. Usually through configuration, not UI.
We do not ship and disappear. Senior engineers and founders lead every deployment together. When you call SimpleGrid, you get someone from the team that designed your system, wrote your SG Schema, and knows your operation by name. That is not scalable forever. But right now, it is the reason our deployments work.
The bet
SimpleGrid is a bet that the mid-market manufacturing ERP problem is not a feature problem. It is a model problem.
Every factory is different. The ERP industry treats that as a bug. We treat it as the foundational design requirement.
If you can model any factory, you can serve every factory. Not by building modules for each one. By building an engine that reads models.
That is the bet. And so far, the factories are proving us right.
SimpleGrid: built by operators, for operators. Every factory is different. That is the whole point.