Built on the framework the ERP is built on.
The part of your business that is genuinely yours rarely fits a standard module — and bolting a separate application onto the side of an ERP creates the integration problem you were trying to avoid. We build it as an app on the same framework, sharing the ledger, the permissions, and the audit trail.
Same framework as the ERP·Yours under an open licence·Survives an upgrade
When a custom app is the right answer.
Often it is not. The first thing we do is check whether configuration, a workflow, or a report gets you there — because the cheapest custom app is the one you did not need.
Your record type does not exist
The thing your business actually tracks is not an invoice, an order, or a job, and forcing it into one of those has been costing you for years.
A separate system that should not be
A tool sitting beside the ERP holding data that belongs in it, with a person or a nightly file doing the integration.
Differentiating work in a spreadsheet
The process that is genuinely your advantage runs on a workbook that one person maintains and nobody else understands.
A surface your customers need
A portal, a calculator, a booking flow, or a field app that has to read and write the same records your staff use.
How a build runs.
Short cycles against working software. The first thing we try to prove is that you do not need the build at all.
- 01Week 1
Rule it out
Establish whether configuration, workflow, a custom field, or a report already does the job. If it does, we say so and the engagement stops there.
What exists at the end of it
- What the standard modules already do, demonstrated
- The genuine gap, stated precisely rather than broadly
- A build-or-configure recommendation in writing
- If build: the record types and relationships, sketched
- 02Weeks 1–2
Model
Design the record types, their relationships, their permissions, and where they touch the ledger. Getting this wrong is the expensive mistake, so it is done before any interface exists.
What exists at the end of it
- Record types, fields, and relationships defined
- Permission model, including row-level rules
- Where and how it posts to the ledger, if it does
- The reports and API surface it has to expose
- 03Two-week cycles
Build in the open
Working software every cycle, in your own environment, tested by the people who will use it. There is no phase where the build is invisible for a quarter.
What exists at the end of it
- Working software in your environment every cycle
- Tests written alongside, not retrofitted afterwards
- Source in your repository from the first commit
- Feedback from real users acted on within the cycle
- 04At the end, and meant
Hand over
Documentation, tests, and a walkthrough with whoever will maintain it — whether that is your team, us, or somebody else entirely.
What exists at the end of it
- Documented code and a documented data model
- A test suite that runs in your pipeline
- Deployment and upgrade procedure, written down
- A maintainer walkthrough, with your team present
What gets built, in what order.
The data model first, the interface last. Most custom projects fail because that order was reversed and the screens were agreed before anybody had decided what a record was.
Record types and permissions
The data model as first-class record types with their own permissions, workflow, and audit trail — inheriting everything the platform already enforces.
1 module in this wave
Where it meets the core
The links to the standard modules — what it reads, what it creates, and where it posts — so it shares one ledger rather than reconciling to one.
The interfaces
Screens for staff, a portal for customers or suppliers, and mobile where the work happens away from a desk — all on the same permission model.
Reporting and the API
Reports over the new records alongside the standard ones, and a documented REST surface so the next system that needs this data has somewhere to go.
What you own at the end.
The distinction that matters is between software you have bought access to and software you have. This list is the second one.
- The source, in your repository
- From the first commit, under an open licence, with the full history — not delivered as a zip at the end.
- An app that survives an upgrade
- Built as a proper app on the framework rather than as changes to the core, so the platform can be upgraded underneath it.
- The same permissions and audit trail
- Your custom records inherit row-level permissions, workflow, versioning, and the audit trail from the platform.
- One ledger, not an integration
- Where it touches finance, it posts into the same ledger — so there is nothing to reconcile between your app and the ERP.
- Tests and documentation
- A suite that runs in your pipeline, and a documented data model, because that is what makes the next developer cheap.
- No lock-in to us
- Any competent Frappe developer can pick it up. That is a deliberate property of how it is built, and we will say so in writing.
The terms this programme runs on
- First step
- Establish whether you need a build at all
- Framework
- The same one the ERP runs on — not a bolted-on app
- Ownership
- Source in your repository from the first commit
- Upgrades
- Built as an app, so the platform upgrades underneath it
- Cadence
- Working software in your environment every two weeks
- Maintenance
- Any Frappe developer can take it on — by design
What this programme is usually pointed at first.
Next step