Build it with AI
Build the software your process needs instead of buying another almost-right tool.
Create purpose-built business software for records, workflows, dashboards, portals, and actions using a plain-language brief.
Introduction
What custom business software has to hold.
Most teams end up with custom business software the same way: off-the-shelf software bent to fit, with the gap covered by spreadsheets and effort. Buying is right for anything undifferentiated, and it stays right until the configuration required to make a tool fit exceeds the cost of building the part that does not. That crossover is real, and it arrives quietly rather than as a decision.
The package handles eighty per cent, and the remaining twenty is where the differentiating work happens. There is no honest accounting of what the workarounds cost, no owner for the gap between what was bought and what the process needs, and no record of the decisions the configuration encodes.
What follows covers building custom business software: the records it holds (the entities the business actually operates on, in the shape the business uses them), the systems it reads (CRM and Email), and what it does not fix.
The problem
Every tool is almost right and the gap is a person’s job.
Off-the-shelf software encodes a median process and is excellent where your process should be median. The trouble is that the parts where you genuinely differ are the parts that matter commercially, and those are exactly the parts a bought tool models worst.
The records are the entities the business actually operates on, in the shape the business uses them, and the authoritative copy of most of them already lives in CRM or Email. The tool holds the official process, the spreadsheet holds the real one, and the reconciliation between them is somebody’s recurring job that appears in no budget.
The cost is not the inconvenience: the process that differentiates the business is the one run on spreadsheets.
You're likely here because
- A person exists mainly to bridge two tools
- The package handles eighty per cent, and the remaining twenty is where the differentiating work happens.
- When it is wrong, the process that differentiates the business is the one run on spreadsheets
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Custom application
- • Role-specific views
- • Business workflows
Operated through Grow
- • Revenue actions
- • Follow-up
- • Connected execution
Systems it reads
- • CRM
- • Collaboration tools
The record model
What the build-versus-buy decision needs.
- Workaround inventory with its cost
- Including the reconciliation time nobody counts. This list decides what is worth building and usually shortens the ambition considerably.
- Differentiated versus undifferentiated split
- Written down. Rebuilding undifferentiated capability is the standard way these projects overrun, and it always looks locally reasonable.
- Bought-system boundary
- What stays authoritative where. Keeping the built part small around a genuine gap is what keeps the decision reversible.
- Maintenance owner and budget
- Custom software has a running cost that a subscription hides. The failure is not the build, it is year two.
- Export path and documented model
- Custom software you cannot leave is a worse lock-in than any vendor, because there is not even a competitor to migrate to.
- Scope boundary
- So expansion is a decision rather than a drift. Every individual case for building one more piece is reasonable.
- Removed workaround cost
- Measured against build and maintenance. This is the test the decision has to pass and the one most often left implicit.
How it runs
From configuring around a gap to building for it.
Step 01
Describe what custom business software has to do
Separate what is undifferentiated from what is genuinely specific to this business. Build the second, buy the first, and be honest about which is which.
Step 02
Connect the systems of record
The bought systems stay authoritative for what they own, and the built software reads them. Building on top rather than instead is what keeps the decision reversible.
Step 03
Build the operating surface
The records, workflows, and interfaces the process actually needs — as an application rather than as configuration stretched past what it was designed for.
Step 04
Start narrow
The gap costing the most in workarounds. One closed gap tests the approach and pays for itself, whereas a full custom platform commits before anything is known.
Step 05
Route the exceptions
Anything the bought system does adequately stays there. Rebuilding what already works is the most common way a custom build overruns.
Step 06
Measure manual effort spent bridging the gap the package leaves
Measure the workaround cost you removed — hours, errors, reconciliation — against build and maintenance. Custom software has a running cost that bought software hides inside a subscription.
Implementation path
Deciding what to build and what to keep buying.
- 01
List the workarounds and cost them honestly, including the reconciliation time nobody counts. That list decides what is worth building and usually shortens the ambition.
- 02
Build only what is genuinely specific. Rebuilding undifferentiated capability is how custom software projects become the thing they were meant to replace.
- 03
Keep the bought systems authoritative for what they own, so the built part stays small and the decision stays reversible.
- 04
Budget for maintenance from the start. Custom software has an ongoing cost that a subscription hides, and pretending otherwise is why the second year is harder than the first.
- 05
Build the narrowest useful version first: the part the package cannot model, built properly and connected to the package for the rest.
- 06
Costing the workarounds honestly is a day and frequently changes what gets built. Closing the single most expensive gap is a matter of weeks rather than months if the boundary holds. Budget maintenance from the start as a line rather than an assumption — the second year is where unbudgeted custom software becomes a liability.
- 07
Once the first gap is closed and the maintenance cost is real rather than theoretical, evaluate the second against the same test. Most businesses find the list is shorter than they expected.
Controls
Controls that matter.
Control 01
A written boundary between what is built and what stays bought, so scope creep is a decision rather than a drift
Control 02
An export path and documented data model, since custom software with no exit is a worse lock-in than any vendor
Control 03
A named owner and a maintenance budget, because unowned custom software degrades faster than unowned configuration
Examples
Three gaps worth closing.
The person who bridges two tools
Building the bridge as software rather than as a role removes a recurring cost that appears in nobody’s budget and disappears entirely when that person leaves.
The configuration nobody understands
A tool configured past its design produces logic that is neither documented nor readable. Expressing that logic in software makes it inspectable, which is worth more than the flexibility it replaces.
The fourth almost-right tool
When the evaluation keeps ending in the same gap, the gap is the thing to build — and the accumulated evaluation effort is itself a cost worth counting.
How it goes wrong
Three ways custom builds become the problem.
The build expands into accounting, payments, or identity because those were nearby.
Buy the undifferentiated. These are solved, regulated, and boring, and effort spent rebuilding them is effort not spent on the part that is actually yours.
Year two arrives, the person who built it has moved on, and nobody was allocated to maintain it.
Name an owner and fund maintenance before the build starts. This is the failure pattern for custom software and it is entirely predictable.
There is no export path or documented model, and the business is now locked into something with no supplier.
Maintain both from the start. Custom lock-in is the only form with no alternative vendor to escape to, which makes it the most complete kind.
Limitations and considerations
What building takes on that buying does not.
- Custom software carries a maintenance obligation that a subscription hides. Budget for it explicitly; the second year is where unbudgeted custom software becomes a liability.
- Building undifferentiated capability is the standard way these projects overrun. Accounting, payments, email delivery, and identity are bought, and the temptation to build them is a warning sign rather than an opportunity.
- Custom software with no export path and no documented model is a worse lock-in than any vendor, because there is not even a competitor to migrate to.
- If the process is undifferentiated, buy. If the workarounds cost less than building and maintaining the gap, buy. If nobody will own the result, buy — an unowned custom system degrades faster than an unowned subscription and costs more to leave.
- Connector coverage varies: CRM, Email, Collaboration tools are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build custom business software with AI: common questions.
When is building actually the right call?
When the process is genuinely specific to how this business competes, and the workarounds around a bought tool cost more than building and maintaining the part that does not fit. Both halves of that test matter, and the second is usually skipped.
What should never be built?
Anything undifferentiated — accounting, payments, email delivery, identity. These are solved, regulated, and boring, and the effort spent rebuilding them is effort not spent on the part that is actually yours.
What does maintenance actually cost?
Enough that it needs a named owner and a budget line. The failure pattern is not the build; it is year two, when the person who built it has moved on and nobody was allocated to keep it current.
How do we keep the decision reversible?
Keep bought systems authoritative for what they own, keep the built part small and focused on the gap, and maintain an export path with a documented model. Custom software you cannot leave is the one form of lock-in with no alternative supplier.
What should the first version contain?
The part the package cannot model, built properly and connected to the package for the rest. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure manual effort spent bridging the gap the package leaves against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build custom business software around the process you actually run.
Cost the workarounds honestly, build only what is genuinely specific, and budget for the second year.