On the business graph
A module reads and writes the same objects as everything else, so it inherits the permission model, the audit trail, and the dimensional reporting rather than sitting beside them.
Platform · platform & data
Every business has one process no vendor builds for. The usual answers are a spreadsheet, a script somebody wrote who has since left, or a consultancy engagement that ends with a codebase you now own the maintenance of. A hosted module is the fourth option and the one that stays governed.
Post a coded vendor bill automatically when all of these hold:
What it does
A module reads and writes the same objects as everything else, so it inherits the permission model, the audit trail, and the dimensional reporting rather than sitting beside them.
Screens, forms, and reports in the same design system, so it does not look like a bolted-on afterthought that people avoid using.
Scoped by actor, entity, and field like any other surface. A module cannot expose data the permission model would refuse elsewhere.
Actions in a custom module land in the same append-only log with the same schema. Your auditor sees one trail rather than one per module.
Maintained through platform changes rather than breaking at the next release, which is the failure mode of handed-over code.
Everything a module produces exports in open formats. The module is ours to run; the data it creates is yours.
The obvious alternative is to build it and give you the code, and customers occasionally ask for that. We decline, and the reason is not lock-in — it is that handed-over code stops being governed.
It falls outside the permission model as it evolves, outside the audit schema, outside the regression tests, and outside whoever maintains the platform it runs on. A year later nobody is certain it still behaves, and two years later the person who wrote it has left. That is the history of most custom ERP development and it is why upgrade projects are expensive.
The candidates that work are specific, structured, and recurring: a reconciliation against a bespoke settlement file, a compliance register with expiry rules, an allocation formula from a partnership agreement, a reorder catalogue for a distributor’s customers, a draw schedule with lien waivers attached.
The ones that do not work are attempts to rebuild something that exists — a CRM, a project tool, a payroll engine — or processes nobody can articulate the rules for. We will say which yours is at the scoping session rather than after a deposit.
Build is quoted at the published rate — API cost times five with a $5,000 floor — after scoping. Hosting runs $250 to $1,000 a month depending on volume and complexity. Most modules land between $8,000 and $25,000 to build.
We will also tell you when the answer is not a module. A process running twice a month rarely justifies one, and a rule that never changes is a policy — cheaper, more predictable, and it does not need maintaining.
Where a module turns out to be useful to other customers in the same industry, we productise it and the hosting fee usually falls. That is the mechanism by which industry depth arrives here — from real engagements rather than from a roadmap guess about a vertical edition.
Limits
We build modules; you do not build them yourself in a designer. If you want to build your own, the API and MCP server are the path.
Nothing that bypasses the policy engine, writes to the ledger directly, or logs separately — at any price. Those constraints are what make the rest defensible.
If you need a CRM, buy a CRM. Rebuilding a mature category as a custom module produces something worse and more expensive.
Questions
We will tell you whether a module fits, what it costs, and when something simpler would serve you better.