Custom ERP Development: Small ERP or Large? A Practical Guide for Growing Companies

When people hear “ERP” they picture a two-year project, a room full of consultants and a budget with too many zeros. That is one kind of ERP. But most of the custom ERP development we do at Dynomica starts much smaller, and that is exactly why it works.

After 120+ software projects, my view is simple: build the smallest system that removes your biggest pain, then grow it.

Signs you need an ERP (even if you hate the word)

You do not need to call it ERP. You just need to recognise the symptoms:

• The same data is typed into three places: an order, an invoice, a spreadsheet.
• Only one person knows how stock is really counted, and they are going on holiday.
• Month-end reporting takes days of copying and pasting.
• Your sales team cannot see what production or the warehouse is doing.
• You have more spreadsheets than employees.

If three or more of these sound familiar, you have an ERP problem. The good news is that it rarely needs an ERP monster to fix it.

Small ERP vs large ERP

What a small ERP usually includes

A small ERP connects the few processes that really run your business. Typically:

• Clients and contacts in one place (the CRM part).
• Orders or projects with clear statuses.
• Stock or resources, if you have them.
• Documents: offers, invoices, protocols, generated automatically.
• Dashboards that show today’s numbers without asking anyone.
• Users and roles, so people see what they need and nothing more.

That is often enough for a company to feel as if it has hired three extra people.

When it is time to scale up

You move towards a larger system when:

• You operate several legal entities, warehouses or countries.
• Integrations multiply: accounting, e-commerce, couriers, banks, B2B partners.
• Approval flows and audit trails become a legal or contractual requirement.
• The number of users grows so much that permissions become a project of their own.

The trick is to design the small system so it can grow. Clean data structures and a proper API from day one cost very little and save a rebuild later.

Buy vs build: the honest version

I run a software company, so you might expect me to say “always build”. I won’t.

Buy (off-the-shelf or SaaS) when:

• Your processes are standard and you are happy to adapt to the software.
• You need something running next week.
• The monthly fee is lower than the cost of the pain.

Build custom when:

• Your way of working is your competitive advantage.
• You are paying for five tools and still exporting to Excel.
• You need to connect systems that were never meant to talk to each other.
• Per-user licences are becoming a serious line in your budget.

There is also a middle path: keep a standard tool for accounting, for example, and build a custom layer around it for the parts that are unique to you. We do this a lot.

How custom ERP development works in two-week stages

Long projects fail quietly. Short stages fail loudly and early, which is much cheaper. That is why we deliver in two-week stages:

1. Discovery. We map how work really flows, not how the org chart says it does. We agree on the one process to fix first.
2. First usable stage. In the first two-week cycle, a real piece of the system goes live for real users. Not a mock-up.
3. Feedback and adjust. Users tell us what annoys them. We fix it in the next stage.
4. Next process. Orders, then stock, then documents, then reports. Each stage adds value on its own.
5. Integrations and automation. Once the core is stable, we connect accounting, e-commerce, couriers or anything else with an API.

After every stage you can see, use and judge what you paid for. If priorities change, the plan changes. That is the point.

Pitfalls I have seen (so you don’t have to)

Automating chaos

If a process is confusing on paper, it will be confusing in software, only faster. Simplify first, then build.

Building for the exception

Every company has that one client who pays in three currencies with a special discount. Handle them manually. Do not design the whole system around them.

No owner on the client side

A system without an internal champion becomes nobody’s job. One person who cares is worth more than a thick specification.

Migrating everything

You do not need twelve years of history in the new system on day one. Migrate what you use; archive the rest.

Ignoring the people

The best ERP fails if the warehouse team finds it slower than their notebook. Watch them use it. Then fix it.

A good ERP should feel less like software and more like the company finally remembering what it already knows.

What to prepare before the first meeting

You don’t need a specification. Bring these instead:

• The three spreadsheets your team opens most often.
• A list of the tools you currently pay for.
• One process that annoys everyone, described in plain words.
• The name of the person who will own the system internally.

That is usually enough for a productive first conversation and a realistic first stage.

Why Dynomica

At Dynomica we build custom software: ERP and CRM systems, B2B platforms, booking systems and APIs. We work with an in-house team using AI-assisted development, with no outsourcing. We also build and run our own SaaS products, so we know what it means to live with software every day, not just hand it over.

Let’s talk about your system

If you recognise the spreadsheet symptoms and want a small, sharp ERP that can grow with you, have a look at Dynomica’s custom software services. I am happy to have a first conversation, no slides required.

See how we build ERP systems →