Four things worth knowing before you build anything

Four questions, in order

What the business offers. Not a slogan — the actual thing you can buy, book or ask for. If the offer is hard to write in one sentence, the site is not ready and the offer needs work first.

Who it is for. Naming who the work is meant for tells a visitor whether to keep reading, and it removes the need for a paragraph of hedging.

What a visitor should do next. One clear next step, above the fold, that matches what most visitors want. A business whose main job is enquiries needs the enquiry to be the obvious path, not the contact page three clicks away.

How to get in touch. A real address or number that a person reads, plus a route to start a conversation. A contact form nobody monitors is worse than no form, because it looks like the business is easy to reach and then is not.

What usually gets added that should not be

Filler pages. A team page with no team, a careers page with no roles, or an awards page nobody can evidence. An empty page is a promise the site cannot keep, and it is easier to leave out than to maintain.

Motion that gets in the way. A visitor on a phone, on a slow connection, or using reduced motion still has to reach the same information. Animation that delays the offer is decoration with a cost.

A sitemap of services nobody actually offers. Long service lists read as a catalogue; short ones with real detail read as a business that knows what it does.

Practical sequencing

Start with the pages the four questions need. Usually that is one strong page that does all four, and it is frequently enough. Extra pages earn their place once the first ones work and the business can say what people still cannot find.

Then write the text, because the text is the site. Design cannot rescue unclear wording, and rewriting a finished site is more expensive than writing it properly first.

The shape that justifies building something

A custom web app earns its cost when a workflow is recurring, important to the business, and handled awkwardly by the generic tools already in use. All three, not one of them.

Recurring matters because a custom app carries an ongoing cost: someone has to run it, update it, and understand it. A process that happens twice a year rarely justifies that. Important matters because the cost of doing this task badly is real — money, time, or a customer who gives up.

Awkward is the one people skip, and it is the decisive one. If a spreadsheet, a form and an email already do the job reliably, a custom app adds a system to maintain and a place for things to go wrong, in exchange for nothing.

The counter-signals

It feels repetitive. Repetition is cheap to automate. Repetition is not, by itself, a reason to build an application — a rule or an integration often removes it for a fraction of the effort.

It needs reporting. Usually a query and a scheduled summary solve it before an interface does.

Only one person understands it. A custom app that nobody else can operate becomes a liability the moment something goes wrong. If the workflow is that fragile, fixing the process first is the real work.

The process is still changing weekly. Build the thing you know; formalise the process first, then automate it.

What to decide before building

Who uses it, and what do they need to see and do? A customer portal and an internal tool have almost nothing in common beyond both being web apps.

What does the app not do? An explicit boundary prevents the slow drift where a small tool quietly becomes a system nobody scoped.

Who operates it, and where does it live? Hosting, updates and access all need an owner before the first screen is designed.

What happens when it is wrong? If the answer is "somebody notices", the app needs the kind of mistake that is noticeable — a validation message, a confirmation, a visible state.

1. What exactly is the task?

One task, written as a sentence with a verb. "Answer questions about our returns policy" is a task. "Help with customer service" is a direction, and directions produce software that never knows when it is finished.

If the task cannot be written in a sentence, it is not ready to be given to an agent.

2. What information is it permitted to use?

List the sources. Selected documents, one folder, one system of record. The narrower this list, the more predictable the behaviour and the easier it is to explain to everyone whose data it is.

Anything the agent should never read is as important as anything it should. Write that down too — it is usually the more useful half of the list.

3. Who reviews the output, and before what?

An agent that produces a draft a person reads before it matters is a different proposition from one that acts directly. Decide which one you are building, because the interface, the safeguards and the cost all follow from it.

Consequential actions (anything financial, contractual, or visible to a customer) should keep a human in charge. That is not a limitation to design around; it is the design.

4. What happens when it is wrong?

Every agent will be wrong sometimes. Decide in advance what the failure looks like: does it refuse, does it pass to a person, does it show the source so a reader can check, or does it quietly produce something plausible and wrong?

The quiet option is the dangerous one. It should be an explicit decision, never an accident.

5. Would a simpler tool do it?

A form, a filter, a rule or an integration is more predictable, cheaper and easier to hand over. If it solves the task, it wins — not because it is less impressive, but because it will still work in two years.

1. The business need is understood, not restated

The most expensive projects are the ones where the brief was agreed before anyone worked out what the business actually needed. The work gets built correctly and still does not help, because the problem was never the thing being solved.

Understanding means knowing who uses it, what they are trying to do, what happens today, and what should become easier. It takes conversation, and it is cheaper than the alternative.

2. The proof can be inspected

If the claim cannot be checked, it is not proof. A cited source someone can open, a build someone can run, a screen someone can see — those are worth something. A confident sentence is not.

This applies to the person selling the work too. A case study that lists unverified metrics is worse than no case study, because it teaches a reader to discount everything else.

3. The scope is written down

What is included, what is not, what it depends on, and what the quote covers. Written before the build, so both sides mean the same thing by "done".

It also protects the work. Without a written scope, every new request is an argument about whether it was ever part of the job.

4. The review is useful

Review only works when there is something concrete to look at and a way to say what is wrong with it. Agreeing how feedback happens, and what a sensible cadence looks like, is part of the scope, not an afterthought.

What value is not

Not an arbitrary price or page count. Ten pages of good content are worth more than forty pages nobody reads, and the page count says nothing about either.

Not a promised revenue result. What a business earns depends on its offer, its audience, its traffic, its follow-up and a dozen factors that have nothing to do with the website. Anyone who guarantees an outcome is guessing, and you can decide for yourself how much to trust a guess.