A system that fits. Not a system you learn to tolerate.
Four non-negotiables govern every engagement. They are not a pitch. They are the specific constraints that prevent ERP failure.
The first conversation is about what we will not touch.
Constraints are the work. Four boundaries sit inside the engagement contract before any configuration begins. They are why the implementation holds after we leave.
No custom development
Everything is built within ERPNext native capabilities. No Python scripts written by us. No custom DocTypes. No JavaScript overrides. Custom code creates fragile systems that break on every version update and require a developer to maintain indefinitely. Our constraint produces a system you can maintain and upgrade without us.
No exit at go-live
Most implementations fail after the consultant leaves. The team reverts to WhatsApp and Excel within three weeks because the system was never actually adopted. It was only technically live. We stay with you until usage is confirmed: transactions running in the system, not around it.
No behaviour overhaul before trust
We configure the system to match how your business already operates, then improve from there. Clients do not change their processes wholesale before they trust the tool. We map how you actually work, build a system that mirrors it, and introduce improvements only after the team has confidence in what is running.
No on-site requirement
Every engagement is delivered remotely. This is not a cost measure. It is a design decision. Remote delivery requires and produces asynchronous documentation discipline that on-site work rarely develops. Your team ends each phase with clear written records of every decision made and every field configured.
We do not configure anything until the process is documented.
Every engagement begins with a process mapping exercise. We document how your business actually operates, not how the org chart says it should work. Purchase orders, inventory movement, invoice approval, payroll cycles, reporting requirements. All of it. The ERPNext configuration follows from that document, not the other way around.
"A system built on an undocumented process replicates your current chaos at higher cost."
Typical process mapping phase.
Of configurations traced back to process decisions.
Lines written in any engagement.
Three things that are different six months after go-live.
The constraints above are not philosophical. They produce specific operational outcomes you can measure six months in.
Maintainability
Your team can add a field, edit a form, or create a new report without calling us. They were trained to do this in Phase 3. This was intentional, not an accident.
Upgradeability
When Frappe releases ERPNext v17, your instance upgrades without a rebuild. Configuration moves with the upgrade. Custom code does not.
Independence
Three months after go-live, you should not need us for routine changes. If you do, the adoption phase was not completed. The adoption guarantee exists to ensure this does not happen.
We stay until the system is running. Not until it is set up.
The adoption guarantee formalises what most implementers only imply. If your team is not using the configured system for daily operations within the agreed adoption period, we continue working with you at no additional cost until they are. This is our commitment, in writing, in the engagement contract.
If the team is not on primary modules at the agreed adoption milestone, work continues at no additional charge. The milestone is defined before work begins. It is in the contract.
What this looks like in practice.
Four engagements. Four sectors. Each one is documented in detail on Substack.
Configuration-only constraint forced a cleaner chart of accounts than the client had in their previous system. No custom fields required for full production order tracking.
Read on Substack →Multi-currency export operations configured entirely within ERPNext native functionality. Batch tracking for perishables required two checkboxes, not a developer.
Read on Substack →Process mapping was skipped under client pressure to begin configuration immediately. The system was technically live. It was not adopted. This case study is published because the lesson is more useful than a clean success.
Read on Substack →Intercompany eliminations and multi-currency reporting configured using ERPNext group company structure. No custom reporting required.
The questions we get most often.
If yours is not here, write to us and we will answer it directly.
Methodology is only useful if it produces a result.
The implementations show what it produces. The first conversation is 30 minutes.