Discovery & Data Model
1-2 weeksWe model the objects, relationships and permissions before writing code, because a wrong data model is the one thing refactoring cannot cheaply fix later.
Frappe is a full web framework, and ERPNext is just the best-known thing built on it. We build standalone apps and ERPNext extensions on the same stack - installed alongside, never patched into, and handed over as code you own.
An app is a bigger commitment than a customisation - it has its own deployment, its own upgrade path and its own maintenance. Here is how we tell the two apart, and we will say so plainly if you are on the wrong side of the line.
If most of your list falls on the right, you want ERPNext customization instead - cheaper, faster, and less to carry.
Data model, business logic, API, front end and deployment - all in the same codebase, which is why a Frappe app takes a fraction of the time a comparable stack would.
DocTypes with links, child tables, naming series and permissions - a real relational model, not a spreadsheet in a browser.
Server-side controllers, scheduled jobs and background workers, so rules hold regardless of how a record is created.
Every DocType is a REST endpoint by default. Token auth, webhooks and rate limiting for whatever you connect.
Query and script reports, number cards and charts built on live data rather than an overnight extract.
Customer, vendor or field-team portals with their own login, their own views and nothing else visible.
Frappe UI, Vue or React front ends where the standard desk interface is not the right tool for the job.
Bench setup, supervisor, nginx, Redis and background queues, tuned and monitored for the load you actually have.
Role and permission design, field-level access, versioning and a complete audit trail on every document.
Nothing exotic, nothing you cannot hire for. That matters more than novelty when the app has to outlive whoever built it.
Frappe v15 on Python 3, the same framework ERPNext itself is built on.
Relational storage with proper indexing, migrations and backups.
Caching, queues and background jobs for anything that should not block a user.
Modern front ends where the desk interface is not the right fit.
Code can be refactored cheaply. A wrong data model cannot, so it gets signed off before anyone writes a controller.
We model the objects, relationships and permissions before writing code, because a wrong data model is the one thing refactoring cannot cheaply fix later.
Two-week sprints on a staging instance, in your repository, with a working demo at the end of each one rather than a percentage in a status report.
ERPNext hooks, third-party APIs and your UAT on real data. Findings return to the same branch instead of becoming a second project.
Production deployment, bench and supervisor configured, plus documentation and a repository walkthrough so your team or another partner can take it on.
Quoted against a signed data model and scope, not an hourly guess.
One clear job, done properly
A system in its own right
Multi-tenant, or business-critical
Typical starting points rather than a price list. Object count, integrations and whether it is multi-tenant all move the number - which is why we quote after the data-modelling stage rather than before it.
Including whether it should be an app at all. You get a data model, a scope and a milestone-based quotation before any code is written.