Websites and browser applications
Many website projects begin with a mood board. We begin with the handful of things a visitor must be able to do, and the data that has to sit behind them. The look follows from that, and it is tested on ordinary phones rather than on the designer's screen.
Common assumptions
Several beliefs shape website budgets more than they should. Each one below sits beside what we usually find when we look closer.
Assumed
Actually
Enquiries usually stall on unclear wording, a form nobody answers, or a page that takes too long on mobile data. A new colour scheme fixes none of those. We look at the path to the contact button first.
Assumed
Actually
Thin pages written to fill a menu tend to dilute the ones that matter. We would rather build fewer pages that each answer something a customer genuinely wants to know.
Assumed
Actually
Office broadband and a new laptop hide almost everything. We test on a modest phone over a throttled connection, because that is closer to how many customers arrive.
Assumed
Actually
Accounts, roles and private data change how a site is structured underneath. If a portal is likely within the year, we plan the data for it now even if the screens wait.
Kinds of build
Most requests are one of these, or a combination. Naming the shape early tells both sides roughly what is involved.
What you do, where, for whom, and how to reach you, written so a stranger can quickly decide whether to get in touch. Editable by your own staff without a developer.
Forms that check input on the server, land somewhere a person actually reads, and confirm to the visitor what happens next. A form that silently drops messages is worse than none.
Availability, reminders and cancellations handled in one place, so the calendar on the site and the calendar at the desk cannot disagree.
Products, prices, stock and checkout, with payment and delivery handled by the providers you choose. Prices and tax rules are held once and read everywhere.
Internal screens for the people who process orders, approve requests or update records. Where this grows into a full system, it becomes custom software and is scoped as such.
Signed-in areas where outside users see their own orders, documents or requests, and nothing belonging to anyone else.
Baseline
These are not upgrades to negotiate. They are the minimum, and a site without them is unfinished.
Under the hood
One rule set, applied page by page. It keeps hosting bills small and keeps the parts that must be dynamic properly engineered.
Generated ahead of time and served from the edge. Cheapest to host and very hard to break.
Prices, stock and listings stay current without turning the whole site into an application.
Sessions, roles and per-user data need a server and a database, so we design those properly rather than squeezing them into a brochure site.
A single site often mixes all of the above, and choosing per page keeps it fast where it can be.
In the browser
On the server
Hosting
Delivery
Visitor tasks and content are settled first, so the design has something real to arrange. You can open and judge each step's output yourself.
We watch the work being done and write down what the software must handle. You correct that document until it matches reality.
The estimate is drawn from the agreed document and states what it leaves out, so a later change can be priced on its own.
Features arrive in pieces you can use and check, rather than all at once near the deadline.
Each release is tried on modest phones, slow connections and the awkward inputs real users type.
You receive the code, the accounts and the notes. Ongoing care continues only if you choose it.
Start here
Skip the reference sites and colour preferences for now. Tell us the few things a visitor should be able to do, and what the site has to connect to behind the scenes. We will come back with a page plan and our questions.
