Most companies don’t need a custom ERP
We’ll start with the unpopular part. Most businesses that ask for a custom ERP would be better off on ERPNext or Odoo with a few custom modules. Accounting, stock, purchasing and payroll work much the same everywhere, and the standard apps have years of edge cases baked in that a new system will rediscover the hard way.
So before we build anything from scratch, we ask what percentage of your daily work happens inside the parts that are genuinely unusual. If it’s a small slice, extend a standard ERP with ERPNext custom modules or Odoo module development and keep the rest stock.
Signs off-the-shelf really doesn’t fit
Custom starts to make sense when several of these show up together:
- Your main transaction isn’t a sale or a purchase. Milk collections, clinical trial visits, container moves, school bus routes. Forcing them into Sales Orders creates fake customers and fake items.
- You’re paying for modules your staff never open. Half the menu is hidden and still confuses new staff.
- The pricing logic is the business. A rate that depends on a lab reading, a route and a date isn’t a price list, it’s a formula that changes weekly.
- The users aren’t office workers. People on tablets at a weighbridge need three buttons, not a desk full of menus.
Our write-up on build vs buy for ERP goes through this decision in more depth, and the Odoo vs custom ERP comparison sets the two options side by side.
What Frappe gives you before the first rule is written
erpfly generates a Frappe app and installs it on a bench without ERPNext. You’re not inheriting an ERP. You’re inheriting the framework under one, which handles the parts that sink most custom projects:
Comes with the framework You still decide
-------------------------- ------------------------------
Login, 2FA, password rules Which roles exist
Role and record permissions Who sees which centre or route
List, form and report views What the DocTypes are
REST API and webhooks Which methods are exposed
Version history on records Business rules and validation
Print formats, email, files Rate charts, payment cycles
Background jobs, scheduler What runs nightly
Data Import from CSV/Excel How old records are migratedThat left column is months of work in a greenfield project, and it’s the part people underestimate. Everything erpfly writes goes in the right column.
Example: milk procurement for a dairy cooperative
Take the cooperative from the prompt. Farmers deliver twice a day to village centres. Each can is weighed and tested for fat and SNF (solids-not-fat), and the price comes from a rate chart that head office revises when feed costs change. Farmers get paid every ten days, less any advances for cattle feed.
ERPNext could technically hold this as Purchase Receipts against thousands of Suppliers, one per farmer. In practice it would be miserable. The centre staff would face a purchase screen built for buyers, and the rate calculation would sit in Server Scripts with no tests and no history.
As a custom Frappe app, it’s a Farmer, a Collection Centre, a Rate Chart, a Milk Collection and a Payment Cycle DocType. The controller on this page does the pricing. A whitelisted method gives the tablet one way to record a delivery. User Permissions keep each centre inside its own data. A Script Report shows litres and average fat by route, and a scheduled job builds the ten-day payment run. Feed advances and the ledger go to ERPNext accounting on the same bench, or to whatever the cooperative already uses.
One thing we’d flag early: village centres often have patchy mobile data. Frappe’s desk expects a connection, so the tablet side needs a small offline-first app that queues deliveries and posts them to that method when the signal comes back. It’s not hard, but it’s a real piece of work, and it should be in the plan from week one rather than discovered in week six.
What it costs, and what goes wrong
We can’t give you a sensible number without knowing the scope, and you should be wary of anyone who does. What we can say is where the money goes. The build is the cheap part now. What stays expensive is owning it. Someone has to review changes, keep Frappe up to date, answer “why did this farmer get paid less” and know where the rate logic lives. If that person is one freelancer who moves on, you’ve got a problem no matter who wrote the code.
The risks we see most often are scope creep (the system slowly grows its own half-built accounting), undocumented rules that lived in one clerk’s head, and data migration from years of spreadsheets. None of that is solved by AI. It’s solved by a small first version, a named owner inside your company and a developer you can call. Our comparison of erpfly and hiring an ERP developer spells out which parts still need a person.
When to choose ERPNext or Odoo instead
- Your process is mostly standard with a few odd corners. Customize a standard ERP. It’s cheaper to own.
- You can’t name an internal owner for the system. A custom ERP without an owner decays quickly.
- You need broad localized accounting and tax on day one. Standard ERPs carry that work so you don’t have to.
If you’re torn between the two big open-source options, our ERPNext vs Odoo comparison is a good next read.