Business
Software built around your workflow.
When off-the-shelf software nearly fits, the gap gets filled by spreadsheets and people. Sometimes that is fine. Sometimes the gap is the most expensive part of the operation.
At a glance
- Built only where off-the-shelf genuinely does not fit
- Starts with the smallest useful version
- You own the code and the accounts
- Documented for handover from the start
The spreadsheet is telling you something.
Almost every business has one: the file that tracks the thing no system tracks properly, maintained by one or two people, opened daily, and quietly holding the operation together. It is not a failure of discipline. It is a precise description of where your software does not fit your process.
That does not automatically justify custom software. Sometimes the right answer is a better configuration of what you have, or an integration between two existing tools. But when the gap involves work that is specific to how you operate — and that specificity is part of why customers choose you — building for it is often cheaper than continuing to work around it.
Worth considering when
- A critical spreadsheet has become a system
- You pay for software and use a tenth of it
- Staff keep the same data in three places
- Your process is a competitive advantage
- Customers ask for visibility you cannot give
- Reporting takes a day to assemble each month
What it covers
What gets built
- Internal tools and dashboards
- The screen your team actually needs, showing live information from the systems it already lives in.
- Customer and contractor portals
- Somewhere for clients or subcontractors to check status, submit documents and find what they need without emailing to ask.
- Job, asset and inventory tracking
- Purpose-built tracking for the specific thing your business moves through a process, rather than a generic tool bent into shape.
- Reporting on your own data
- Consolidated reporting across systems that do not talk, so the monthly numbers are not assembled by hand.
- Forms and intake
- Intake that validates as it goes and lands directly in your workflow, replacing PDFs emailed back and forth.
- Replacing the critical spreadsheet
- Turning the file everyone depends on into something with permissions, history and no risk of someone sorting one column.
When not to build
If an existing product does the job at a reasonable price, that is the recommendation — even though it means less work here. Custom software you have to maintain is a long-term commitment and should only be taken on when it is genuinely warranted.
No lock-in
You own the code, the repository and the hosting accounts. Ongoing support is available and frequently sensible, but it is a choice rather than a dependency engineered into the project.
Built to be maintained
Boring, well-documented technology chosen over interesting technology, because in three years the question is who can maintain it — not how clever it was.
How it works
How a build runs
- 01
Watch the actual process
Including the workarounds. What people really do differs from the documented procedure, and the difference is usually the requirement.
- 02
Scope the smallest useful version
The narrowest thing that delivers real value, deliberately. Large first releases are how custom software projects go wrong.
- 03
Build, with you using it
Delivered in stages you can actually use, so feedback arrives while it is still cheap to act on.
- 04
Hand over properly
Code, accounts and documentation are yours. Another developer should be able to take over without starting again.
Is custom software expensive?
It costs more upfront than a subscription and less than most people expect when scoped narrowly. The honest comparison is against what the current workaround costs in staff time each month, which is often the larger number.
What if our needs change?
That is assumed. Building the smallest useful version first means changing direction is normal rather than expensive, and the architecture is chosen so extending it does not mean rewriting it.
Who owns what gets built?
You do — the code, the data and the accounts it runs on. There is no arrangement where leaving means losing the software.
What happens if Ketweb is unavailable later?
It is documented so another developer can pick it up, using mainstream technology rather than anything exotic. That is deliberate: software that only one person can maintain is a liability regardless of who that person is.
Related
Often needed alongside this
Is a spreadsheet running part of your business?
Tell us what it tracks and who depends on it. You will get an honest view on whether custom software is justified — or whether something simpler would do.