Enterprise · Finance · Operations
An open-source ERP chosen over expensive commercial options
Set up, customised, and now maintain a 21-module ERPNext deployment covering accounting, treasury, HR, manufacturing, and analytics.
Domain: Enterprise / Finance / Operations Engagement: ERPNext evaluation, deployment, customization, and multi-year ongoing maintenance Team Size: Backend-heavy, full-stack
A growing enterprise needed a unified system for financial operations, HR, inventory, manufacturing, and reporting — all under one roof. Existing commercial ERP solutions were either too expensive (SAP, Oracle) or too rigid for their workflows.
The strategic question underneath was the harder one: build, buy, or open-source? A bespoke ERP would take years and never reach feature parity. A commercial ERP would lock them in. Open-source ERP carries its own trap — it's tempting to fork core source, which then makes every future upgrade a merge conflict and eventually strands the client on a stale platform.
We recommended ERPNext on the Frappe framework, with a strict rule: no core forks. All client-specific behavior would live in extension points the platform officially supports, so the ERP stays upgradable for the life of the business. We took ownership of:
A 21-module ERPNext deployment spanning the full spectrum of enterprise operations.
The difference between an ERPNext project that lasts five years and one that has to be re-platformed in eighteen months is entirely a function of how the platform is extended. We stuck to the officially supported extension surface and avoided the temptations that cause most ERPNext projects to calcify.
All client-specific behavior is implemented through supported Frappe extension points:
doc_events, scheduled_tasks) for workflow logicThe rule of thumb: if implementing something requires editing frappe or erpnext source, we treat that as a design smell and look for a supported path first. That rule is the difference between "stuck on ERPNext v13" and "routinely upgrading".
The client operates multiple legal entities. Rather than running multiple ERP sites, we used ERPNext's multi-company features within a single site: company-scoped charts of accounts, inter-company transactions, consolidation reports, and company-restricted user permissions. Role-based access is layered with user permissions (ERPNext's record-level ACL) to enforce who can see which entity's data — a distinction that is routinely overlooked and becomes a compliance issue later.
Banking and tax integrations are not wired into core code; they sit in a dedicated custom app that exposes webhook receivers (for inbound events from banking partners) and REST clients (for outbound calls to tax-filing endpoints). Each external system is behind its own adapter module, so swapping a banking partner is a configuration change, not a rewrite. Credentials live in Frappe's site-config / password fields, not in source.
We use the right tool per question: Script Reports for anything requiring cross-DocType logic, Query Reports for reports that are essentially SELECT queries, stock Report Builder for the long tail of ad-hoc needs, and Dashboard Charts for KPI surfaces. Custom reports are committed as fixtures so they survive rebuilds.
Replacing the legacy systems was a migration exercise, not an import exercise. We mapped legacy entities to ERPNext DocTypes, ran multiple dry runs against staging sites, validated trial balances against the old system for every historical period, and cut over with reconciliation checkpoints. Opening balances were loaded as journal entries against a dedicated opening-balance party so any discrepancy is immediately traceable.
The stock role permission model is necessary but not sufficient at real-world scale. We layered:
| Layer | Technology |
|---|---|
| Platform | ERPNext (open-source ERP) |
| Framework | Frappe (Python) |
| Database | MariaDB / PostgreSQL |
| Task Queue | Redis + RQ (scheduler + background workers) |
| Extension surface | Custom DocTypes, Server/Client Scripts, Hooks, Custom App |
| Integrations | Webhook receivers + REST adapters for banking & tax |
| Reporting | Script Reports, Query Reports, Dashboard Charts |
| Ops | Bench-managed sites, scheduled backups, staging-first upgrade path |
Not every project requires building from scratch — and knowing when not to is a senior call. The value we delivered here wasn't a novel platform; it was the discipline to deploy a well-chosen open-source platform correctly: staying on the supported extension surface, modelling multi-entity permissions properly, keeping integrations behind adapters, and treating upgrades as a first-class operational activity. The system is still upgradable, still auditable, and still the client's ERP of record — which, for an ERP project, is the outcome that matters.
More recent work
Healthcare · Patient management
A six-app healthcare ecosystem — the product our client took to Shark Tank
Patient app, resident web, staff portal, admin dashboard, shared SDK, and an AI emergency dispatcher — all sharing a single backend with role-isolated access. Built for a healthcare startup that was later featured on Shark Tank with the product we delivered.
Read the case study
Transportation · Smart city
Multi-modal routing and cashless ticketing for public transit
Proprietary IP we built and productised — launched on the App Store and Play Store. 150+ APIs, dynamic fare engine, real-time vehicle tracking, ONDC-certified, and a voice AI for 250+ metro stations.
Read the case study
Tell us what you're trying to build. Discovery calls this week, scope within 3 business days.