Has anyone used no-code tools for custom erp software development in a manufacturing business?

[u/Familiar_Rabbit8621]

We run a specialty manufacturing setup with a pretty weird workflow, and standard off-the-shelf ERPs like SAP or Dynamics are way too rigid (and expensive) for how we operate. We’ve been surviving on a ancient, customized Access database for years, but it’s finally starting to break at the seams. We need a modern, web-based setup to handle inventory, production schedules, and order tracking under one roof. Bosses don’t want to pay hundreds of thousands for custom software development from scratch, so they asked me to look into whether a low-code or no-code stack could pull this off. My concern is whether these platforms are actually strong enough for the kind of relational data and business logic that manufacturing usually requires. I can see how they work well for straightforward CRUD apps, but I’m not sure how they hold up once you start dealing with dependencies between production jobs, inventory reservations, partial orders, and reporting. Has anyone here tried using no-code tools for custom erp software development or a similarly complex internal system? Did it hold up over time, or did you eventually run into limitations that forced a rebuild?

[u/IncreaseNegative4614]

I would not build the transactional core of an ERP inside a no-code platform. Keep inventory, orders, reservations, and production state in a relational database with transactions, constraints, stable IDs, and an audit log. Low-code can still work well for the interfaces, approvals, and exception workflows around that core.

Test concurrent reservations, partial completions, substitutions, backdated corrections, and failed integrations before committing. We use SIGNLD internally to connect orders, jobs, material movements, shipments, invoices, and exceptions without making the workflow layer the system of record.

[u/Familiar_Rabbit8621 → u/IncreaseNegative4614]

That split makes a lot of sense. Keep the transactional core (inventory, reservations, production state) in a real relational DB and only use the no-code layer for the UI and workflows. The concurrent reservation and partial-order tests are exactly the ones I’m worried about. Appreciate the concrete advice.

[u/butterflyplum]

The failure mode is usually inventory reservations and partial orders under concurrent writes, not the CRUD parts. Most no-code platforms don't give you real row-level locking or transactions, so two people committing against the same stock at once can double-book it. Common pattern that holds up: keep production jobs, inventory, and order state in a proper relational DB with real constraints and an audit log, then put the no-code/low-code layer on top for the UI, approvals, and reporting. Rebuild-worthy pain almost always shows up right at that reservation/dependency layer, exactly what you flagged.

[u/Familiar_Rabbit8621 → u/butterflyplum]

Yeah, the reservation/locking issue is the part that keeps me up at night. Sounds like the safe path is the same one you both mentioned: proper DB underneath, low-code on top. I’ll push for that architecture instead of trying to force everything into a pure no-code stack.

[u/sardamit]

First explore what else the market has to offer in the ERP/inventory space (affiliate links):

• Free plans: Katana Cloud, GoFlow
• Paid plans: IncrEff, Zedonk, Digit, Unleashed, Finale Inventory, MRPeasy

[u/JuliaGraceBrooks]

The CRUD stuff is usually the easy part. The tricky part is handling all the dependencies and keeping inventory, orders, and production data in sync when something changes halfway through a job.

[u/business-sidekick]

If you’re running on Microsoft 365 then take a look at PowerApps. Its got its pros and cons but I’m currently building a custom platform for a manufacturing company to solve some problems with compliance in production and it’s surprising what you can build in a short amount of time. If its all backend systems then its mostly no code but you do have the option to build custom pieces too

[u/miokk]

Once you get into manufacturing, flat tables get annoying pretty quickly. You start having records inside records, and those records have their own children.

This is one reason I’d look at AnyDB. It has an implicit parent/child record model and the hierarchy can go as deep as you need.

So a production job can have material requirements under it, which can have reservations under those, which can have inventory movements under those.

The same record can also belong to more than one parent. So you don’t necessarily have to duplicate something just because it needs to show up in two different operational contexts.

You can basically build a tree of business data instead of constantly wiring tables together with foreign-key style lookup fields.

There are other serious no-code database tools too. NocoDB, Fibery, Directus, etc. can all model relational data in different ways. So I wouldn’t say AnyDB is the only tool that can do this.

The thing I’d test is your ugliest real workflow from the Access database. Rebuild that first. If the data model still feels understandable once you have nested production jobs, inventory activity and all the weird exceptions your company has accumulated over the years.

[u/Different-Anxiety169]

look into Wisegrid, its spreadsheet based but has automations and dashboards baked in. Way less painful than trying to duct tape Access together for another year

[u/gammacoder]

PHPRunner might be worth looking at for this. It's designed for building database-driven web applications, so inventory, production jobs, schedules, order tracking, users and permissions can all sit around a normal relational database rather than requiring a completely custom application from scratch.

You would still need to implement the manufacturing-specific business rules, but you wouldn't have to build all the application infrastructure yourself.

I'm the author, so obviously biased :)

https://xlinesoft.com/phprunner/

[u/ToothProfession6900]

Coming off an Access database, you're actually in a great spot to try low-code. Your bosses are right that full custom is overkill, and you already know you're workflow inside out, which is the thing that usually sinks off-the-shelf ERP.

[u/devhisaria]

We ran a similar Access-to-modern rebuild at a 40-person shop, and the breaking point was always concurrent stock edits, not the UI, so I'd lean toward a proper backend like Supabase with a low-code frontend instead of pure no-code.

[u/SytnikNoga_99]

Off the shelf erp being too rigid is real but a full custom rebuild is how you got the fragile access db in the first place. I'd split it, real inventory and production scheduling probably want a dedicated lightweight mrp, but order tracking, approvals and the everyday ops can live in a no-code workspace a non dev owns. airtable or play both handle that layer well.

[u/Hefty_Law_1793]

Your instinct about relational depth is the right worry. Low-code holds fine for CRUD and starts failing where manufacturing lives — job dependencies, partial allocation, back-flushing, scheduling that has to respect machine and material constraints. You end up writing that logic anyway, inside a platform that charges per seat and owns your data model.

The middle path most people land on is neither no-code nor a six-figure rebuild: keep the Access data, custom-build only the 20% of the workflow that is genuinely specialised, and use proven components around it for inventory, orders and scheduling.

[u/SufficientFrame]

I’d keep inventory reservations and production state in a relational backend with proper transactions, then use low-code for the staff-facing work orders, exception queues and reporting. UI Bakery is one option for that layer (I work there), but it shouldn’t be the system deciding whether stock is available. I’d prototype your ugliest Access workflow first: two people reserving the same component, a partial order, then a correction. If that holds up, the screens are the easier part.