The blank-repo tax nobody budgets for
Every from-scratch business application begins with the same unglamorous months. You build user accounts and sessions, then password resets and roles. You build a permission model, because business software always needs to control who sees which records. You build a REST or GraphQL API, an admin interface to inspect and edit data, an audit trail, background jobs for anything slow, and a reporting layer. Only after all of that do you start on the feature the client actually asked for.
We call this the blank-repo tax, and it is almost never in the estimate. It is invisible because it is not a feature; it is the floor a feature stands on. Building on ERPNext and Frappe means the floor already exists, tested by tens of thousands of production deployments, and you walk in and start on the interesting part.
What you get for free on day one
With a fresh Frappe site you already have a role-based permission engine, session and API-key authentication, a full REST API for every model, a background job system on Redis and RQ, a scheduler, an email engine, a report builder, and a configurable admin UI.
Add ERPNext and the list grows to include double-entry accounting, multi-currency, tax handling, inventory and stock ledgers, and purchasing and sales cycles. These are exactly the modules that are deceptively hard to build correctly. Accounting in particular is a trap: it looks simple and is full of edge cases around reversals, periods, and reconciliation that take years to get right. Inheriting a proven implementation is not laziness; it is risk management.
- Authentication, sessions, API keys, and password flows.
- Role-based and row-level permissions across every doctype.
- REST API, background jobs, scheduler, and email out of the box.
- From ERPNext: double-entry accounting, tax, inventory, and stock ledgers.
- An admin and reporting layer you would otherwise build and maintain forever.
Speed to a working system, not just a demo
The metadata-driven core changes the shape of delivery. When we define a doctype, we immediately have a table, an API endpoint, a form, list views, and permissions without writing them. That means we can put a working, permissioned, data-backed prototype in front of a client in days, then iterate on real feedback instead of on assumptions.
This matters most in the middle of a project, not the start. Change requests that would be expensive in a hand-rolled system, adding a field, a new linked record type, a workflow state, an approval step, are often configuration or a small controller change in Frappe. The framework absorbs a category of change that usually generates rework, which keeps momentum through the phase where most projects bog down.
Upgrade-safe customisation is the whole game
Building on a platform is only a win if you can customise without cutting yourself off from upstream updates. Frappe is designed for exactly this, and the discipline is non-negotiable in our shop.
Core apps, frappe and erpnext, are treated as read-only. Every line we write lives in a separate custom app. We add fields to core doctypes through Custom Fields and Customize Form, not by editing them. We change behaviour through hooks.py: doc_events to react to lifecycle events, method overrides for whitelisted endpoints, scheduler entries for periodic work, and permission query conditions for row-level rules.
Built this way, an ERPNext version upgrade is a controlled event, not a crisis. Our code observes and extends core; it never patches it. The team that ignores this and edits core to save an afternoon pays for it at every future upgrade, which is the most common way Frappe projects turn painful.
The community, security, and longevity dividend
A from-scratch codebase is an island. Every bug is yours to find, every security hole is yours to discover, and every piece of tribal knowledge lives in your team's heads. A mature open-source platform gives you leverage that no single team can match.
Security patches arrive from upstream and apply through a normal upgrade. The data model is documented and understood by a global community of developers, which means hiring and onboarding do not depend on one person's undocumented decisions. When you hit a problem, there is a strong chance someone already solved it and wrote it down.
Because the licence is GPLv3, none of this is rented. You self-host, you own the database, and you can read and modify every line of the platform if you ever need to. You get the dividend of a shared codebase without surrendering control of your system.
When from-scratch is genuinely the right call
Honesty matters here, because platforms are not universal. Building on Frappe is the wrong choice when your product is fundamentally not record-oriented: a real-time collaborative canvas, a high-traffic consumer app that is mostly cacheable content and needs edge delivery, a game, or a system whose core value is an unusual data structure or request lifecycle that fights the ORM.
In those cases the framework's assumptions become friction rather than leverage, and you are better served by a bare framework and full control. The engineering judgement is to look at the true shape of the problem. If it is forms, records, workflows, approvals, permissions, and reports, build on Frappe. If it is something else at its core, do not force it.
How Upeosoft applies this in Kenya
Most of the business software Kenyan organisations need is exactly the record-oriented, permission-heavy, report-driven kind that Frappe handles best. Licensing systems, field operations tools, member and asset management, service delivery tracking, and anything touching accounting or stock all map cleanly onto the platform.
So our default is to start from ERPNext and Frappe, build the client's unique logic into a dedicated custom app, and spend our engineering budget on the twenty percent that is genuinely theirs rather than the eighty percent that every system shares. That is how we deliver serious software on realistic Kenyan budgets and timelines: not by cutting corners, but by refusing to rebuild solved problems.
The result is systems that go live faster, cost less to run over their lifetime, and stay upgrade-safe against a platform with a global community behind it. When from-scratch is truly the right answer we say so, but for the work most of our clients need, standing on ERPNext and Frappe is simply the stronger engineering decision.
