Services

Built for the process only you have

Every business has one workflow that no vendor builds for. It is usually the one that differentiates them, it is currently a spreadsheet, and the person who understands it has been meaning to document it for four years.

Describe the process

Tell us what you need that nobody builds. We will say whether a module fits and what it costs.

1 / 3
$8,000–$25,000 typicalThree to six weeksWe host and maintain it
policy · ap_autopostdraft v5

Post a coded vendor bill automatically when all of these hold:

Simulated against your last quarter — 1,284 bills
603 posted automatically
681 held
Balanced. Most customers settle around here.
Simulation runs before the policy is enabled. You see what it would have done last quarter, not what it might do next.

The situation

What a module is and is not

A first-class part of the system, on your data, governed like everything else — not a script bolted to the side.

On the business graph

It reads and writes the same objects as everything else, so it inherits permissions, audit, and dimensional reporting rather than needing its own version of each.

Real interfaces

Screens and reports in the same design system, because a module that looks bolted on is a module people avoid using.

Same governance

Permissions, policy engine, and audit trail apply identically. There is no module-shaped hole in the control framework.

Maintained through upgrades

Versioned and carried forward as the platform changes, which is the specific thing handed-over code never gets.

Priced from actual cost

Build quoted at API cost times five with a $5,000 floor, after scoping rather than before. Hosting $250 to $1,000 a month by volume.

Productised if it generalises

Where a module turns out to be useful to others in your industry, we productise it and your hosting fee usually falls.

What actually gets built

The modules that work are specific, structured, and recurring. A reconciliation against a bespoke settlement file from an industry clearing house. A compliance register with expiry rules and evidence attached. An allocation formula from a partnership agreement that eleven people currently interpret slightly differently.

A draw schedule with lien waivers. A commission calculation with tiers, clawbacks, and splits. A reorder catalogue that a distributor’s customers use directly. Each of those is a real engagement, and each replaced a spreadsheet that one person maintained.

The best candidate for a module is the spreadsheet everyone depends on and one person understands.

What does not work

Attempts to rebuild a mature category. If you need a CRM, buy a CRM — a custom one will be worse, cost more, and never catch up. The same applies to payroll, project management, and document storage.

Also: processes nobody can state the rules for. If four people describe the calculation differently, the module is not the first problem. We will say that at the scoping session rather than after a deposit, and the session frequently ends with a recommendation to settle the rules first.

Why we host rather than hand over

Customers occasionally ask for the source. We decline, and the reason is not commercial — handed-over code stops being governed. It falls outside the permission model as that evolves, outside the audit schema, outside the regression suite, and outside whoever maintains the platform underneath it.

A year later nobody is sure it still behaves correctly. Two years later the person who wrote it has gone. That is the history of custom ERP development and it is why upgrade projects cost what they do.

When a policy is the better answer

A rule that never changes is a policy, not a module. Policies are configured rather than built, cost nothing to host, and do not need maintaining. A surprising share of module enquiries resolve into two policies and a report.

Similarly, a process that runs twice a month with low volume rarely justifies a module. We will tell you when the honest answer is a better spreadsheet with a scheduled export behind it.

Where to start

How it runs

01

Scoping session

Ninety minutes with whoever actually runs the process. Free. It ends with a written recommendation, which is sometimes that you do not need a module.

02

Specification and quote

Rules written down, edge cases named, fixed price and hosting fee stated. Ambiguities are resolved here rather than discovered in build.

03

Build and review

Three to six weeks, with a working version in front of your team at the halfway point rather than at the end.

04

Live and maintained

Deployed, monitored, versioned through platform changes. Maintenance is the hosting fee, not a change-order relationship.

Questions

What people ask.

What does a module cost?
Build is API cost times five with a $5,000 floor, quoted after scoping. Most land between $8,000 and $25,000. Hosting is $250 to $1,000 a month.
Can we have the source code?
No, and it is a governance decision rather than a commercial one. Handed-over code falls outside the permission model, audit schema, and tests within a year.
How long does it take?
Three to six weeks from specification to live, longer where the underlying data work is substantial.
Will you build anything?
No. Nothing that bypasses the policy engine, writes to the ledger directly, or logs separately — at any price. And we decline rebuilds of mature categories.
What if it stops being useful?
Cancel the hosting. The data it produced stays yours and exports in open formats like everything else.

Tell us about the spreadsheet.

The one everyone depends on and one person understands. That is usually the module.