For a mid-size manufacturer, custom software is worth building for the work that lives in spreadsheets and email beside the ERP, after you have checked what the ERP can already do and whether a product fits. This guide walks through that decision and what the build path costs.
It is written for the VP of operations at a manufacturer that runs on an ERP, such as NetSuite, with quoting, order entry, approvals and reports still handled in spreadsheets and email. In 2022 the US had 239,265 manufacturing firms, and 93.1 percent had fewer than 100 employees, so a manufacturer with a few hundred people is among the larger ones in its field.
The Gnar Company builds enterprise software and internal tools for teams whose approvals, orders and reports still live in spreadsheets and email. One tool replaces the spreadsheet and the email chain, and every team works from the same records, so nobody types them in twice.
What does manufacturing software development cover?#
Manufacturing software development puts the ERP at the center and covers two kinds of software around it: shop-floor systems and back-office tools. This guide is about the second kind, the tools for quoting, orders, approvals and reports. Gnar Forge builds tools of that second kind, such as approvals, a reporting dashboard or a client portal, with one senior engineer who plans the work with you and builds it.
| Kind of software | What it does | Usually bought or built? |
|---|---|---|
| ERP | Finance, inventory, purchasing, orders, the system of record | Bought, then configured |
| MES and machine monitoring | Tracks work in progress and machine data on the floor | Outside this guide |
| Quoting and pricing tools | Turn a request into a priced quote with your own rules | Often a spreadsheet today; bought or built |
| Order entry and approvals | Get orders and changes into the ERP with the right sign-offs | Often email today, sometimes built |
| Reporting | The numbers leadership asks for every week | Often exported and pasted today |
| Customer and partner portals | Let customers check status and send files themselves | Bought or built |
Quoting, order entry, approvals and reporting are where this guide spends its time.
Where does the work leak out of the ERP?#
Work leaks out of the ERP wherever your own business rules do not fit its screens, so people copy data into a spreadsheet or an email to get the job done. The leak is easy to spot once you look for retyped data.
- Quotes. A salesperson builds the price in a spreadsheet with rules only two people understand, then types the result into the ERP.
- Order entry. Customers email purchase orders, and someone retypes every line.
- Approvals. A discount or a credit waits in someone's inbox, with no record of who said yes.
- Reports. Every week someone exports data, fixes it in a spreadsheet and pastes it into a slide.
- Partner visibility. Customers and suppliers call or email to ask where an order is, because they cannot see it themselves.
Gnar's ERP modernization page describes the goal as screens shaped around how each team works, "from the sales desk entering an order to the warehouse picking it." Each leak above is one of those screens that is missing today.
Configure, buy or build: how do you decide?#
Decide in a fixed order: configure the ERP if it can do the job, buy a product if one fits at a lower cost, and build only the part that neither covers. The table gives the rule for each path.
| Path | Choose it when | Watch out for |
|---|---|---|
| Configure the ERP | The ERP has a built-in feature or workflow tool for the job | Heavy customization that only one person understands |
| Buy a product | A product fits the job and costs less than building | A product that needs so many changes it no longer fits |
| Build a tool beside the ERP | The job depends on your own business rules and no product fits | A tool that keeps its own copy of the data instead of using the ERP's |
Work through the paths in that order. Configuration uses software you already pay for. A product is built once and sold to many customers. A build is made for you alone, so keep it to the part only your business needs.
Step 1: Check what your ERP can already do#
Start by listing what your ERP can do through configuration, because the cheapest fix is one you already own. Ask what workflow and approval tools your ERP includes before you price anything else.
NetSuite is a common example. Its SuiteFlow tool creates workflows for standard or custom records through a graphical interface, so an administrator does not need to write script. Oracle says "SuiteScript lets you customize more deeply," and it is NetSuite's scripting tool. Oracle's SuiteFlow overview lists transaction approval and record management among the business processes it can run.
Ask your ERP administrator or partner three questions for each leak on your list. Can the ERP do this with a built-in feature? Can it do it with its workflow tool? If yes, who will own that setup after the person who built it leaves?
Step 2: Buy when a product wins on cost and fit#
Buy a product when it fits the job and costs less than building one. Gnar's custom software page puts the rule plainly: buy when an off-the-shelf product wins on cost and fit, and build when it does not. In Gnar Discovery and Design, senior engineers plan both options and say which one wins, even when the answer is to buy.
Check fit by running your real process through the product. Bring three real orders, quotes or approvals from last month and ask the vendor to run them through the product. Count the changes the product would need. If a product needs many changes to fit, compare its total cost, subscription included, with the cost of a build.
Also check how the product connects to your ERP. A product whose copy of customers and orders is not synced with your ERP creates a second place to fix every mistake.
Step 3: Build the tool beside the ERP#
Build when the job depends on your own business rules and no product fits. The tool should sit beside the ERP and use its data, so the ERP stays the system of record. Gnar's internal tools page calls this "type it once": you keep your ERP and CRM, and the new tool reads from them and writes back where they allow it, so an order gets entered once. We build alongside the ERP you are keeping, not on top of its grave.
The same idea runs through Gnar's ERP work. Every change your team makes in the new apps writes back to the ERP, so accounting and every other team work from the same records. That page adds a second benefit: when the daily work moves out of the ERP, fewer people need an ERP seat, which lowers your license costs.
There are two sizes of build. One tool does one clear job, like approvals, a reporting dashboard or a customer portal. A bigger system touches several teams and systems, like order handling tied to your ERP. Size the build to the job before you talk to anyone about price.
No-code gets you to eighty percent. The stretch to ninety-five is why Gnar gets called. That last stretch is your own business rules and a live connection to your ERP or CRM.
What does each path need from your team?#
Configuring needs your ERP administrator or partner, buying needs someone to test products and manage the ERP connection, and building needs the people who do the job today.
| Path | What it needs from your team |
|---|---|
| Configure the ERP | Time from your ERP administrator or partner, and one person who owns the setup after it is live |
| Buy a product | Someone to run real cases through each product, and someone to manage the connection to the ERP |
| Build a tool beside the ERP | The people who do the job today, to show how it works and to test working versions as the tool is built |
The build path asks the most of the people who do the work. In Gnar's process, engineers sit with those people before anything is built, and show working versions to the people who will use the tool while it is being built. Decide before you start who on your team will own the tool once it is live, whether or not the firm keeps it running for you.
What does a tool beside the ERP cost?#
A Gnar Forge tool gets a written list of what will be made and a fixed price before the build starts, with the first month of maintenance included and maintenance from $1,000 a month. A system that touches several teams starts with Gnar Discovery and Design at $15,000, $20,000 or $30,000 for two, four or six weeks, and a build is typically $150K to $300K+. Use these as a reference point when you talk to any firm.
| What you need | Gnar's path | How Gnar prices it |
|---|---|---|
| One tool for one clear job | Gnar Forge: one senior engineer plans it with you and builds it | A written list of what will be made and a fixed price before the build, with the first month of maintenance included and maintenance from $1,000 a month |
| A system that touches several teams | Gnar Discovery and Design, then Build | Discovery: $15,000 for two weeks, $20,000 for four, $30,000 for six. A build is typically $150K to $300K+ |
Discovery maps how work and data move between your teams and ends with a build plan that has a fixed price on it. You do not have to build with Gnar after. Three commitments on every build engagement: a fixed milestone price with any overage on us, a guaranteed outcome meaning the software works as specified or we fix it, and a twelve-month bug-free warranty. It covers Discovery, Build, Forge and Maintain. It does not cover Embed. On Compass, Immerse and Integrate, ask us.
What the OnePak build looked like#
Gnar built a front end that gave OnePak's clients and partners a view of the data its back end already held. OnePak is a reverse logistics company that handles the return of laptops, desktops and servers to the manufacturers that made them, for recycling, refurbishment or disposal. Its clients had no visibility into how equipment was moving, and the manufacturers, warehouse partners and recycling partners each needed to see a different part of that chain.
The OnePak engagement supported order tracking, partner routing, order management, partner performance and asset pricing, with different views for each role. Gnar worked with OnePak's own back-end team and helped set the order in which that team built the connections the front end needed.
The back end stayed. The new tool gave every party a view of the data OnePak already had. OnePak won a Dell Supplier Award as a result of the work. When the project was done, OnePak hired its own engineers to replace Gnar's, and Gnar helped with the documentation and handed off its development process to the new team.
The case shows one version of the pattern: keep the back end that runs the business, and build a new front end on top of its data.
Questions to answer before you build#
Answer these questions before you ask anyone for a price. Each one either shrinks the build or shows that you do not need one.
- Which spreadsheet or inbox hurts most? Name the one job that costs the most hours or the most mistakes each week.
- What can the ERP do today? Ask your administrator which built-in settings and workflow tools cover that job.
- Is there a product that fits? Run three real cases through any product you consider.
- What are your own rules? Write down the pricing, approval or routing rules that make your process different.
- Where does the data live? List the systems the job touches, and which one is the system of record for each piece of data.
- Who will use it? Name the people who will test working versions while the tool is built.
- Who keeps it running? Decide whether your team or the firm hosts, watches and fixes it after launch.
- Can your own team build it? If your own team has the capacity and the direction, you do not need us.
Gnar's process starts the same way. Before building, Gnar sits with the people doing the job and traces every spreadsheet, email and system it touches, then gives you a written list of what it will make and a fixed price. Whether or not Gnar keeps the tool running after launch, you get the code and the docs.
For the AI side of the same question, Gnar's guide to AI for manufacturing covers where mid-size plants should start. If your biggest leak is order entry, read whether to build or buy an order management system, which covers the same decision for that one job.
