# Custom ERP > A custom ERP is enterprise resource planning software built for one company's own processes, instead of a packaged suite configured to fit them. In practice it is often a set of custom modules around a packaged system for the ledger, payroll and tax. A custom ERP is enterprise resource planning software built for one company's own processes, instead of a packaged suite configured to fit them. It covers the same ground as any ERP (orders, purchasing, inventory, production, invoicing), but the data model and the screens follow how that company actually works. A full rebuild is rare in practice. A common shape is a packaged system for the parts every business does the same way, and custom modules for the parts that make the company different. ## Custom vs off-the-shelf ERP An off-the-shelf ERP is a product you license and configure. A custom ERP is software your team, or a contractor, writes and owns. Neither is the safe default. Each puts the cost in a different place. What a packaged suite gives you: - Commodity processes that already work: double-entry accounting, payroll, tax rules, period close. - Compliance updates you do not write yourself. - People you can hire who already know the system. What it costs you: - Your processes bend to its data model. Anything it does not model becomes a custom field, a workaround or a spreadsheet next to it. - Customisation lives inside the vendor's extension system, and upgrades can break it. - Your data sits in someone else's schema. What a custom ERP gives you: - A data model that matches your business, in your terms. - Screens built for the people who use them every day. - Full ownership of the data, the integrations and the change history. What it costs you: - Every feature is yours to build, test and maintain for as long as the company runs on it. - Commodity features (a correct ledger, payroll, tax) are hard to get right and add nothing that sets you apart. - Knowledge concentrates in the few people who built it. It is the same trade-off as any [build vs buy decision for internal tools](https://avohq.io/glossary/build-vs-buy-internal-tools): build what is specific to you, buy what is the same everywhere. ## Where off-the-shelf ERP stops fitting The misfit is usually not in accounting. It is in the core operation, which the suite's model does not describe. The usual signs: - A process central to the business shows up in the suite as a custom field and a note in a shared document. - Staff keep a spreadsheet next to the ERP because it cannot express a rule they work by. - Every workflow change needs a consultant or a vendor ticket. - Customisations make each upgrade a project, so the company stays on an old version. - The suite has dozens of modules, and the team uses a handful. ## The middle path: a packaged core with custom modules A custom ERP is often a hybrid. The company keeps a packaged system as the [system of record](https://avohq.io/glossary/system-of-record) for money, and builds the modules where its process is the product. Keep packaged: - The general ledger and financial reporting. - Payroll. - Sales tax, VAT and other tax calculation and filing. - Anything an auditor reads directly. Consider building: - The operational core that makes the company different: how orders are configured, scheduled, produced or fulfilled. - Approval flows and the rules behind them. - Glue between systems that today runs through exports and manual re-entry. Each custom module owns its own records and posts the financial results (an invoice, a payment, a cost) to the packaged ledger through its API. The ledger is the system of record for money. The module is the system of record for the process. ## A worked example Take a hypothetical coffee roaster that sells wholesale to cafés. Every order is roasted to order, each café has its own blends and prices, and green beans are bought by lot, so every bag shipped has to trace back to its lot. A packaged ERP handles its accounting, payroll and tax well. Roasting does not fit: the suite models stock as finished products on a shelf, not as green lots turned into roasted batches. So the roasting schedule lives in one spreadsheet, traceability in another, and the warehouse types batch numbers into a free-text field. The roaster keeps the suite and builds three modules next to it: 1. Green lots and roast batches, recording which lots went into each batch. 2. A roasting schedule built from open orders and each café's delivery days. 3. Customer blends and price lists, which the suite could only hold as notes. When an order ships, the custom app sends the invoice to the packaged system. The spreadsheets go away, "which cafés got beans from this lot?" becomes one query, and the accountant's tools stay the same. ## What it takes to maintain a custom ERP The first version is only the start. Plan for: - An owner on staff who understands both the code and the operation, with time set aside every month. - Tests around the rules that move money or stock. - Access by role, and a record of who changed what. - Backups you have restored at least once. - Business rules written down next to the code, so the next developer knows why a rule exists. A custom ERP is never finished. The business changes, and the software changes with it. ## Signs a small or mid-size business should not build one - Your processes are standard for your industry, and a packaged suite covers them with configuration. - Nobody on staff can own the software after it ships. - The pain is in accounting, payroll or tax. Those are the parts to buy. - You cannot name the process the packaged system gets wrong, only that it feels heavy. - You plan to rebuild everything at once, rather than one module where the misfit is worst. - The business model still changes every few months, so any data model you design now will soon be wrong. If most of these apply, configure a packaged system, stay close to its defaults, and revisit the question when one process clearly does not fit. ## Building the modules with Avo If your team builds those modules in a Rails app, [the Avo page on ERPs in Rails](https://avohq.io/rails-erp) makes the case for building the fifth of an ERP your team actually uses, over the models and database you already have, rather than a whole suite. Your team writes the models and business logic, and Avo is what they use to put connected screens, actions and permissions on top, as a [Rails admin panel framework](https://avohq.io/glossary/rails-admin-panel-framework). ## Frequently asked questions ### What is a custom ERP? A custom ERP is enterprise resource planning software built for one company's own processes rather than a packaged suite configured to fit. Its data model follows how that company handles orders, purchasing, inventory and production. A common approach is to build only the operational modules and keep a packaged system for accounting, payroll and tax. ### Should a small business build a custom ERP? Usually not a whole one. A small business with standard processes is better served by a packaged system kept close to its defaults. Building makes sense for one specific process the packaged system cannot express, and only if someone on staff can own the software afterwards. ### What are the limits of off-the-shelf ERP? A packaged ERP makes your processes fit its data model, so anything it does not model ends up in custom fields, workarounds or spreadsheets. Customisations live inside the vendor's extension system and can make upgrades hard. It is strongest at the processes every business shares, such as accounting and payroll. ### How do you extend an ERP with custom modules? Keep the packaged ERP as the system of record for money and build separate modules for the processes that do not fit. Each module owns its own records and sends financial results, such as invoices and payments, to the packaged ledger through its API. That way you replace one misfit at a time instead of the whole system.