The difference is what it holds
A website presents information. Someone arrives, reads, and acts — usually by getting in touch. The content changes occasionally; the visitor’s experience is essentially the same each time.
An application does work. It holds state, responds to what a particular person has done, and produces something that did not exist before the visit. A booking system, a customer portal, a calculator that takes inputs and returns a result, a tool that processes a document.
The line is not about complexity or budget. It is about whether the thing being built remembers, computes, or acts on behalf of a specific person.
Signs a website has been asked to do too much
Businesses rarely decide to build software. They discover they should have, usually after the same symptoms:
A spreadsheet is doing something critical. Often several, emailed between people, with version confusion and a person who is the only one who understands it. Spreadsheets that outgrow themselves are the most common precursor to custom software.
Staff are re-entering the same information. Data typed from one system into another is a workflow gap wearing a person’s time as a workaround.
Four tools are stitched together. Each does part of the job; the seams are held together manually, and something falls through them regularly.
The website has grown a maze of forms. Increasingly specific forms routing to increasingly specific inboxes is a workflow trying to become software.
You cannot answer a basic question about your own operation. How many of something are in progress, where they are, what is stalled. If answering requires assembling it by hand, the information exists but is not held anywhere.
Off-the-shelf software nearly fits. The most expensive situation: paying for a tool while working around it, because it was built for a neighbouring industry.
Do not build if you do not have to
Custom software is a commitment. It needs maintenance, it needs someone to own it, and it does not stop needing attention after launch.
Before building, exhaust the alternatives honestly:
- Does an existing product actually fit, if the process changed slightly?
- Can existing tools be connected rather than replaced?
- Is the problem a process problem wearing a technology costume?
- Is the volume high enough to justify the investment?
Custom software makes sense when the workflow is genuinely specific to the business, when the volume is high enough that inefficiency is expensive, when the process is a competitive advantage worth encoding, or when the alternative is paying people to compensate for a tool that does not fit.
It does not make sense to avoid a subscription, or because building software sounds like progress.
What building one actually involves
Understanding the workflow first. Not the desired software — the current process, including the parts people do not describe because they have stopped noticing. This is where most projects are won or lost.
Deciding what is in the first version. The first version should do the most valuable thing well rather than everything adequately. Scope discipline is the difference between a tool in use in three months and one still being built in eighteen.
Designing for the people who will use it. Internal tools are used daily by people who did not choose them. Friction that is tolerable once is intolerable forty times a day.
Handling data seriously. What is stored, who can see it, what happens when someone leaves, what the backups are, and what recovery looks like.
Planning for after launch. Software needs updating, hosting, and someone to call. A build without a maintenance plan is unfinished.
When the information is written, not tabulated
Some of the hardest workflows involve unstructured information — documents, notes, correspondence — where the useful content is written rather than sitting in rows and columns.
Software can help there, but only if it is built to turn that prose into structure a person can check. Built carelessly, it produces confident, wrong output at speed.
Anything where a wrong answer carries real consequence needs a person in the loop by design, not as a fallback.
VetCaseIQ is our own example of building across this line — a structured document-processing system rather than a website with a search box. The case study covers what that involved.
Where to start
Not with a specification. Start by writing down what actually happens today, step by step, including the workarounds. Most businesses find that the exercise itself clarifies whether they need software or a better process — and if it is software, that description is the most valuable input to the build.
That is where our custom application work begins.