For where no product fits the work.
A custom application is worth building when the work has a shape no product matches and the business is paying for that mismatch every week. Built properly it captures the job where the job happens, validates it against the rules of the system that owns the money, and posts it there with nothing re-typed.
Personal reply from Andrew within one business day.
What is a custom app, and when is one justified?
A custom app is a small piece of software built for one business, covering a step in its work that no product it already owns covers properly — and it is justified only when the gap is being paid for repeatedly.
The usual sign is a spreadsheet that has become load-bearing. It started as somebody keeping track, it acquired columns, then formulas, then a second sheet, and now it sits between two proper systems doing work neither of them was asked to do. Everybody knows it is fragile. Nobody can remove it, because the process genuinely depends on it and no product on the market has quite the right shape.
The honest starting position is that most of these do not need a custom app. A good proportion are solved by configuring a product the business already pays for, by a report that removes the reason the sheet exists, or by connecting two systems so the copying stops. Those answers are cheaper to build, cheaper to keep, and do not leave the business owning something only one person understands. Reaching for a build first is how a small annoyance becomes a permanent maintenance obligation.
Where a build does earn its place, it is almost always at the point of capture. The pattern that repeats is work happening away from a desk — on a site, in a vehicle, on a warehouse floor, in front of a customer — and being written on paper or into a phone, then typed into a system hours later by somebody who was not there. Every hour between the two is a chance for the detail to be lost, and the person doing the typing is guessing at what the note meant. An app that captures the job where it happens removes both problems at once, and that is worth more than any feature list.
The second rule is that the app must not become a system of record. It owns the workflow — who is doing what, in what state, with what attached — and it posts the result into the product that owns the ledger, the stock or the customer file. The moment a custom app starts holding the only copy of something financial, the business has quietly acquired a second set of books, along with an obligation to back it up, audit it and keep it running for as long as the records are needed. That obligation is rarely priced in and it never goes away.
The field service case study is a worked example of both rules: the module owns scheduling and field capture, and the ERP still owns the invoice. The Accredo Saturn pages cover the other side of the same question — when the right answer is not a new app at all, but making the system you already run do the specific thing your business does.
How does work get from the field to the ledger?
Five stages between something happening and it being a record somebody can rely on. Each one fails differently, and the failures are more instructive than the successes.
-
01
The work happens
A job is completed, a delivery signed for, an inspection carried out — away from a desk, usually by somebody with one hand free.
breaks here if: the app asks for more than the moment allows -
02
Captured once
Entered where it happened, on the device already in their hand, and held locally if there is no signal until there is.
breaks here if: coverage was assumed and the day is spent out of range -
03
Validated
Checked against the rules of the system that will receive it — the code exists, the account is open, the quantity is possible — before anybody is told it worked.
breaks here if: validation happens later, and rejections arrive after the crew has gone home -
04
Posted
Written into the system of record through a supported interface, once, carrying a reference that makes a repeat harmless.
breaks here if: a retry creates a second invoice and trust is gone in a week -
05
Visible
The office sees the result where it expects to see it, and anything that did not post sits in a queue with a reason attached.
breaks here if: failures are logged rather than shown, so nobody chases them
Stage one decides whether the whole thing is used. An application that asks for fourteen fields from somebody standing in the rain will be filled in at the end of the week from memory, which is exactly the situation it was built to replace — except now the business has paid for it. The design question is not what would be useful to know; it is what can honestly be captured in the time and posture the work allows. Everything else is either derived, defaulted, or asked for later at a desk.
Stage three is the one most often postponed, and postponing it is expensive. Validating against the receiving system while the person is still on site means a problem is fixed by the one who can fix it, in the ten seconds available. Validating overnight means a rejection queue that somebody in the office works through the next morning, phoning people who have moved on to other jobs and are reconstructing from memory. The technical difference is small. The operational difference is most of the value.
Stage two is where honesty about coverage matters. If the work genuinely happens where there is no signal, the app must be built to hold records locally and post them when it reconnects — and that is a real design decision with consequences, not a checkbox. It means deciding what the person is allowed to do without validation, what the app promises them, and how a conflict is resolved when two queued records disagree. Building for offline when it is not needed adds complexity; assuming connectivity when it is not there produces an app that is abandoned in the first fortnight.
Build, buy, or configure what you already own?
Four routes out of the same spreadsheet. Three of them are cheaper than a build, and one of those three is usually right.
| Keep the spreadsheet | Buy a product | Configure what you own | Build something | |
|---|---|---|---|---|
| What it is | The sheet that grew into a process, maintained by whoever built it. | A product bought for this job, configured to fit as closely as it will. | Making an existing system cover the gap through its own extension points. | A small application written around the way this business actually works. |
| Where it wins | Genuinely low volume, or a process still changing shape month to month. | Common problems. Somebody has solved scheduling, timesheets and expenses already. | When the gap is a report, a field, a document or a rule rather than a whole workflow. | When the process is the business, and no product respects how it runs. |
| What it costs | Nothing visible. A person, a risk, and a ceiling on how large the business gets. | A subscription per user, forever, plus the work of bending the process to fit. | The least of the four in most cases, because the platform already exists. | The most to build, and an ongoing obligation to keep it maintained. |
| How it fails | Quietly, and then all at once when the person who owns it leaves. | By fitting eighty per cent, with the remaining twenty handled in a spreadsheet again. | By hitting a limit in the platform that no amount of configuration passes. | By becoming a second system of record, or by nobody being able to change it later. |
| Who maintains it | One person, informally, and usually not in their job description. | The vendor, on their roadmap and their timeline. | Whoever supports that platform, using skills the market has. | You do — which is why the code, the documentation and the plain technology choices matter. |
The column that deserves more attention than it gets is the third. A large share of what arrives described as a custom app requirement turns out to be a report that does not exist, a document that needs different logic on it, or a rule that should be enforced when a record is saved rather than checked by a person afterwards. Systems that offer proper extension points — Accredo Saturn among them — can absorb a great deal of that without a new application, and the result is something any competent practitioner in that ecosystem can maintain.
The last row is the one to weigh hardest before committing to the fourth column. A custom app is an asset while somebody can change it and a liability the moment nobody can. That is a decision made at build time, in the choice of ordinary technologies over fashionable ones, in whether the thing is documented, and in whether the source is genuinely yours.
What does one look like when it is built?
The field service module is the fullest example on this site, and it is written up in detail rather than summarised into a claim.
A multi-branch services operation was scheduling field work on a whiteboard and re-keying completed jobs into its ERP afterwards. The module that replaced it holds the schedule and the field capture; the ERP still holds the invoice. That division is the whole design, and the case study covers the part that decided whether it would work at all — which data could travel the supported API and which had to be posted natively, and why splitting it that way was the right call rather than a compromise.
It also covers the honest section: the circumstances in which a build like that is not worth doing. That section is there because it is the part a prospect should read before commissioning anything, and it is the same reasoning applied on this page under when a custom app is the wrong answer.
Field service, captured on site and posted to the ledger
The full write-up covers the two-path integration decision behind it, the three design decisions that shaped the module, the interactive demonstration of the scheduling and job views, and an account of when a build like this is not worth doing.
How does a build actually run?
Three phases, and the first one is allowed to end with a recommendation not to build anything.
Watch the work, then decide
- The process observed, not described
- What the existing systems could cover
- Products that already solve this
- An honest build-or-buy recommendation
Processes are always tidier in the telling than in the doing, and the exceptions are the design. This phase frequently ends with a cheaper answer than a build, which is the point of running it before anything is committed.
One real path, end to end
- One job type, captured and posted
- Real users, real records, early
- Supported interfaces into the system of record
- Changed on what is learned, not on the plan
A narrow slice that reaches the ledger proves the parts that carry risk — capture, validation, posting, failure handling — while the design can still be changed cheaply. Breadth added before depth is how a project discovers a fundamental problem in month four.
Leave it maintainable
- Source code and documentation to you
- Ordinary technologies, deliberately
- Written runbook for the routine failures
- No dependency on one person being available
The measure of a custom build is whether somebody else can pick it up. Ordinary tools and written documentation cost a little at build time and are the difference between an asset and something the business is stuck with.
Got a spreadsheet holding a process together? The audit says whether it needs a build, a product, or a setting changed.
Book a free process auditWhen is a custom app the wrong answer?
More often than not, which is an awkward thing to publish on a page that offers to build them. Four tests decide it.
A product already does this. Scheduling, timesheets, expenses, quoting, job tracking — these are solved problems with mature products behind them, and a build competing with one starts years behind and stays there. The gap has to be genuinely specific to how this business works, not merely unfamiliar to the person evaluating the options.
The process is still moving. If how the work is done will be different in six months, building software around this month's version fixes it in place. The honest sequence is to let the process settle, or to change it deliberately first, and to build only once the shape is stable enough to be worth encoding.
Nobody will maintain it. Every custom application is a standing commitment — an operating system update, a vendor API change, a browser deprecation. A business with no appetite for that commitment is better served by a subscription, because the vendor absorbs it. Saying this before a build, rather than three years afterwards, is the difference between an asset and a grievance.
The gap is a report, a document or a rule. A great deal of what feels like missing software is a query nobody has written, a form that needs different logic, or a validation that should happen when a record is saved. Where the system in use offers real extension points, that is a smaller, cheaper and more maintainable answer — see scripting inside the system for what that looks like in practice.
Questions about custom applications.
Should we buy a product instead of building one?
Usually, yes. If the problem is one many businesses have — scheduling, timesheets, expenses, quoting — a product exists, it has been refined against thousands of users, and the subscription buys you a vendor who handles the maintenance. A build is the right answer when the process is specific to how your business competes, when a product would fit closely enough that the remaining twenty per cent lands back in a spreadsheet, or when the licence cost across your headcount exceeds what a small application would cost to own outright. The first phase of any engagement here is that assessment, and it is allowed to end with a product recommendation.
Who owns the code?
You do. Source code, documentation and the ability to hand the whole thing to another developer belong to the business that paid for it, and that should be written down at the start rather than assumed. It matters for a reason beyond principle: a custom application is only an asset for as long as somebody can change it, and an arrangement where the code sits with the builder converts a one-off cost into a permanent dependency. The same reasoning drives the choice of ordinary, widely known technologies over anything that narrows the pool of people able to pick it up.
What happens if you are not available later?
This is the right question to ask any independent consultant, and the answer has to be structural rather than reassuring. Builds here use common technologies rather than novel ones, the source and documentation are yours, the routine failure modes are written down in a runbook, and nothing depends on undocumented knowledge held in one head. The test applied is whether a competent developer who has never seen the system could take it over from what exists in writing. Where an engagement is large enough that the answer matters commercially, it is worth agreeing a support arrangement in writing rather than relying on goodwill.
Does it need to work offline or on a phone?
That depends entirely on where the work happens, and it is a question worth answering honestly rather than optimistically. If the job is done in a building with coverage, an ordinary web application on a phone browser is simpler to build, simpler to update and has no app store between you and a fix. If crews genuinely spend the day out of range, the app has to hold records locally and post them when it reconnects — which brings real decisions about what can be validated offline, what the app promises the user, and how conflicting queued records are resolved. Building offline capability that is not needed adds cost and complexity; assuming coverage that is not there produces something abandoned within a fortnight.
How is this different from customising the system we already have?
It is a question of where the work lives. Customising an existing system — a validation rule, a document layout, a scheduled report, an extension field — keeps everything inside a platform that is already backed up, already audited and already supported by people other than the person who wrote the change. A custom app is a separate piece of software with its own hosting, its own updates and its own maintenance obligation. The rule of thumb is to extend first and build only when the workflow genuinely sits outside what the platform models, which is most commonly the case for work that happens away from a desk. The Accredo Saturn pages cover the extend-first route in depth.