What Is a Mini ERP? When a Small Company Needs One

A mini ERP is one system built around how a specific company works. It covers that company's core operations, such as orders, stock, purchasing and reporting, in one place, without the parts of a large general ERP the company would never use.

You want to know whether an order can ship, but the answer is split between a spreadsheet, a supplier email and a warehouse message. When I say I build mini ERPs, I mean joining that work up so your team can act without chasing the missing pieces.

What does ERP mean in plain words?

ERP stands for enterprise resource planning: one system for the core work of a business. Think of an order, the stock it needs, the purchase that replaces that stock and the records of what happened. Those details belong together, so people don't have to copy them between separate lists.

Oracle's ERP guide defines ERP as software for daily business activities including accounting, purchasing and supply chain operations.

My concern with a large general ERP for a 10 to 50 person company is the size of the change. It has to accommodate many kinds of business. You can end up changing how you work to fit the software, while setting up parts you'll barely use. I want the scope to match the work that needs fixing.

What does a mini ERP cover?

A mini ERP covers the work that has to stay connected for your company to run. At Silla, the furniture company I built an app for, that means much more than a list of orders. Buying stock, packing, delivery, complaints and reports all sit in the same system.

Orders and delivery: Website orders arrive in the app automatically. The app creates a courier shipment and a packing task. The packing task stays open until the correct model, color and quantity have been scanned.

Stock by component: A chair is a seat, a backrest and four legs. Silla tracks stock by component, with reservations for open orders. The app knows which orders can ship today, rather than leaving someone to work that out from a sheet.

Purchasing: Each purchase runs from the supplier order to receipt in the warehouse. Stock increases when a warehouse worker scans the goods in. Orders waiting for a missing part have their own list.

Product publishing: The team publishes colors, photos, dimensions and prices for new products on the website from the app.

Complaints and outlet: Complaints connect to the order, shipment and customer photos. An employee can send the right spare part without entering the address again. Returned goods with minor damage become outlet items with their own barcodes and appear on the website automatically.

Reports and finances: Orders, revenue, margins, deliveries, returns and warehouse output by day and employee are visible without manual spreadsheets. Finances and receipts sit alongside orders.

The Silla case study shows what each part does in the team's daily work.

Your version doesn't have to replace everything. A mini ERP can be designed to sit next to accounting software you already use. Decide which tool holds each record and how updates pass between them. Keeping a useful tool is fine; making someone copy its data all day needs attention.

When does a small company need a mini ERP?

Five signals tell you a mini ERP is worth a closer look. Follow a real order and look for scattered information, rules your tools can't handle, dependence on you, admin that grows with volume and repeated typing. The point is to identify work a better system should remove.

1. One order's story is spread across several tools

The first signal is that nobody can see an order's full story without searching several places. The quantity is in a sheet, the promised date is in chat and the delivery address is in another tool. A routine customer question turns into a search before anyone can answer it.

At Silla, answering a customer's status question could take up to 15 minutes of searching across apps. Now the status is on one screen. Open an order in your own company and ask someone to find its latest agreed details. Watch where they look.

2. Your core flow has rules standard tools miss

The second signal is that the way your work moves matters, and standard tools keep forcing workarounds. Component stock is one example: you need to know whether the parts for an order are available, including what other open orders already need. A count of finished products doesn't answer that question.

At Silla, stock reservations and component records answer that question together. Write down the rule your own spreadsheet or chat is handling outside the main tool. Test a standard product against that rule before deciding you need a custom build.

3. You have to be there to know what's happening

The third signal is that you can only see the business by being there. People can tell you what's happening, but the records can't. If you have to walk around asking what shipped, what's stuck and who's doing what, you are assembling the picture your tools should show.

Before Silla's app, information lived in people's heads, on paper and in Excel. The owner had to be there to know what was happening. The app now shows orders, deliveries and warehouse output by day and employee. Check which routine facts still require a call from you.

4. More orders mean more admin

The fourth signal is that extra volume mostly creates extra copying, checking and chasing. Look at the work you would give the next person you hire. If their day would revolve around keeping different lists in agreement, fix that work before assuming another desk is the answer.

With its app in place, Silla's same team went from about 20 orders a day to about 90. Look at your own admin per order: where does someone print, copy, check or forward something? Those steps show where extra orders would add work.

5. The same details get typed again

The fifth signal is repeated entry of information your business already has. A customer address, product choice or quantity should travel with the order. When someone types it again for packing, shipping or a complaint, the business has created another copy that can disagree with the first.

At Silla, the address was copied for the third time when someone entered it into the courier's system. The app now creates the shipment. Follow one address through your own process and mark every place someone types it. Include what happens when the customer changes it.

How to start: one flow at a time

Start with the people who handle a real order, from its arrival through delivery and any complaint. Mark every handoff, repeated entry and unanswered question. Then choose one connected flow to improve, starting with the work that causes the most trouble for the team or customer.

1. Map one normal order and one awkward one. Sit with sales, the people doing the work and whoever handles purchasing or stock. Write down what happens, who does it and where the details live. Include a changed quantity, missing part or return.
2. Agree on the rules. Decide who updates a change, when stock is reserved and who can approve an exception. Put names beside responsibilities. Software needs to reflect decisions the team understands.
3. Test what you can buy. Walk both orders through a standard tool. If it handles the work without separate lists and manual copying, keep it on the table. The guide to custom software vs off-the-shelf walks through that choice.
4. Start with the flow that hurts most. Define its beginning and end. Order arrival through packing is a connected flow; an isolated dashboard isn't. Add other parts when the people doing the work can show why they're needed.

Even the UK government's service manual for its own digital teams recommends small, frequent software releases, so the people using the software can give feedback sooner.

At Silla, I mapped the work from order to complaint with the people doing it. I connected the systems, then built warehouse and delivery functions. Complaints, outlet, purchasing and reports went into use as the operation came together. The team stopped using paper and Excel.

My build work starts with paid Discovery of 1 to 2 weeks, ending in a written proposal with a fixed scope and price. I work with you and the team, then stay involved through build, rollout and troubleshooting. Ongoing support and improvements are monthly.

Common mistakes, and when not to build

Building a mini ERP is the wrong next move when a standard tool fits, the volume doesn't justify the change or the team hasn't agreed how work should happen. The five signals help you name the gaps. They don't turn every awkward handoff into a reason to commission software.

• Custom-building a standard process: Test existing products against real orders before drawing screens. A preference for different button labels isn't a reason to build a system.
• Building for low volume: If one shared sheet stays accurate and nobody spends much time maintaining it, keep it. A quiet, reliable process doesn't need a new app to look professional.
• Coding an unresolved disagreement: If sales and the warehouse disagree about when an order is ready, decide what ready means first. I work on responsibilities and processes as well as software; those decisions belong in the work.
• Replacing every tool at once: Keep the tools that earn their place. Decide what needs to connect, which record people should trust and when a separate list can be retired.

See where the business still needs you

A mini ERP can make the daily work visible, but unclear responsibilities still need your attention. If you want to see how much runs on you, the Business MRI is 10 questions, about 2 minutes, no email needed to see your result. It gives you a founder dependency score, your three weakest areas and a first move for each.