ERP Development2 min read
Custom ERP vs Off-the-Shelf ERP: How to Decide
When custom ERP development makes sense, when off-the-shelf ERP is the better choice, and why a hybrid — standard core plus custom domain app — is often the answer.
Service · Engineering
ERP development by engineers who understand the business logic
ERP code is unusual. It handles money, stock and legal documents, so a subtle bug can misstate a balance sheet or ship the wrong lot to a customer. It also has to survive platform upgrades every year or two. General web developers often underestimate both.
Overview
What erp development involves
Our developers specialise in ERP platforms. They understand double-entry accounting, stock moves and costing, and they write code that respects the platform's data model, access controls and upgrade path.
01The problem
Where things usually go wrong
01
Freelance code with no tests
Modules written quickly by different contractors, never tested beyond the happy path, breaking whenever data looks unusual.
02
Performance that degrades with growth
Code that worked with a thousand records times out with a million, because it loops instead of batching.
03
Changes made directly in production
No staging environment, no version control, and no way to roll back when something breaks.
04
Logic duplicated across systems
The same pricing or allocation rule implemented separately in the ERP, the web shop and a spreadsheet — and disagreeing.
02Our approach
How we handle it
Every engagement starts with the repository: all custom code in Git, a staging environment that mirrors production, and a deployment process that does not involve anybody editing files on a server. That foundation alone removes a large class of incidents.
From there, we build in small, reviewable increments. Each change has a ticket explaining the business need, a pull request reviewed by a second developer, and tests that exercise realistic edge cases: partial deliveries, returns, multi-currency, multi-company, users with limited access.
03Capabilities
What the work covers
01
Custom modules
New business objects and workflows that integrate with standard accounting, inventory and sales.
02
APIs and connectors
REST endpoints, webhook receivers and connectors to third-party systems.
03
Reports and analytics
PDF documents, Excel exports, SQL reporting views and data feeds for BI tools.
04
Portals and front-ends
Customer, supplier and partner portals, plus role-specific back-office interfaces.
05
Scheduled jobs
Background processing for imports, recalculations, notifications and reconciliations.
06
Performance engineering
Profiling and fixing slow screens, reports and batch jobs.
04Technical considerations
Details that decide whether it holds up
01
Version control and CI
Git branches per environment, automated test runs on pull requests, and tagged releases.
02
ORM discipline
Batched reads and writes, prefetching, stored computed fields where appropriate, and raw SQL only with documented reasons.
03
Transactional safety
Operations that touch stock or accounting are atomic, idempotent where retried, and fully audited.
04
Upgrade compatibility
Use of public extension points and avoidance of private APIs that change between versions.
05Process
How the engagement runs
- 01
Clarify
Business need, acceptance criteria and test scenarios agreed before code.
- 02
Design
Technical approach reviewed for data model, security and upgrade impact.
- 03
Build
Implementation in a feature branch with unit and integration tests.
- 04
Review and test
Code review, automated tests and user validation on staging.
- 05
Release
Deployment through the pipeline with release notes and rollback plan.
06Outcomes
What you should expect afterwards
Fewer production incidents
Tested, reviewed code deployed through a controlled pipeline.
Code you can hand over
Documented, conventional code that another competent team could maintain.
Performance that scales
Code written for realistic volumes, not just test data.
Where it applies
Industries and systems we commonly see
Relevant industries
Relevant integrations
Related solutions
Related services
Often delivered alongside
ERP CustomizationTailor your ERP to real processes with the least custom code that will do the job.Custom ERP DevelopmentPurpose-built ERP software for operations that standard products fit poorly.ERP API IntegrationDesign and build ERP APIs, webhooks and connectors with security and reliability built in.ERP Performance OptimizationFind and fix slow screens, reports, batch jobs and integrations with evidence, not guesswork.
Insights
Related reading
ERP Development3 min read
Odoo 20 Access Rights: Migrating to ir.access
Odoo 20 removes record rules and merges them into access rights with domains. What changed, how to migrate ir.model.access.csv and ir.rule, and what to test.
ERP Development2 min read
Odoo Studio vs Custom Code: Where to Draw the Line
What Odoo Studio does well, where it creates trouble, and when to switch to custom module development. A practical decision guide with examples.
FAQ
Frequently asked questions
Which languages and platforms do you work with?
Primarily Python and the Odoo framework, with TypeScript/Node.js for integration services and front-ends, and SQL for reporting. We also extract data from and integrate with other ERP platforms.
Do you provide documentation?
Yes. Each module has a README covering purpose, configuration and dependencies, and significant logic is documented in code. We also maintain a customization register at system level.
Can you take over development from another team?
Yes. We begin with a code audit, set up version control and staging if they are missing, and then take on new work.
Do you work on a fixed-price or time-and-materials basis?
Both. Well-specified pieces of work can be fixed-price. Ongoing development and work with unclear scope is usually better on time and materials with regular reporting.
Next step
Need ERP engineering capacity?
Describe the work. We will tell you how we would approach it and what it would take.