Websites and web applications
Websites and Web Applications You Can Keep Changing
Whether you need a handful of pages explaining your business or a browser application your team uses all day, the same few questions decide whether it is still quick and easy to edit next year. This page sets out the problems we usually help with, how we answer those questions, and the tools involved.
Where you might be starting
What Is Your Website Meant to Fix?
A web project is far easier to plan once you name the problem it exists to solve. These are the ones people bring to us most often, and many projects combine two of them.
Customers cannot tell what you do
If your current site, or the lack of one, leaves visitors unsure what you offer or how to reach you, a clear company site is the answer. We arrange it so your own staff can change the wording without needing a developer for every paragraph.
Customers want to order without phoning
An online shop needs a catalogue, a basket, a checkout and the order handling behind them, linked to payment and delivery services through their published interfaces. Prices, stock and tax rules sit in one place, so the shop never quietly contradicts itself.
Your staff live in a browser tab all day
Admin screens, dashboards and internal web tools are used for hours at a stretch, so search, saved filters, bulk actions and an audit trail matter far more than decoration. We shape them around how the work really happens, awkward cases included.
Other software needs to reach your data
When an app, a partner or another system has to read from or write to your platform, it needs an interface that does not shift under it. We build versioned endpoints, check every request where it arrives, and document them clearly enough for an outside developer to work alone.
The site you have is slow and fragile
A site that crawls on a phone or breaks whenever someone edits it can usually be rebuilt piece by piece. After launch we can carry on with dependency updates, fixes and small improvements, using the same version control and review as the original build.
Delivery
How Does a Web Project Get From Idea to Live?
A small company site and a platform with an admin panel behind it pass through the same stages here. At the end of every stage there is something concrete for you to open and judge.
- 01
Questions First
Before anything is estimated, we find out who will use the software, what they do today and what has to be different afterwards. The answers are written up for you to correct, and the estimate is built on that document.
- 02
Working Software, Early
You see real screens in small, regular instalments instead of one large reveal at the end. Each instalment is tested on ordinary devices and slow connections before you are asked to review it.
- 03
After Release
Once it is live you receive the code, the account access and notes that explain how it fits together. We remain available for fixes and for whatever you decide to add next.
Questions worth asking
What Should You Ask Whoever Builds Your Site?
Launch day reveals very little about a website. Its quality shows a year later, when content has built up and someone new has to change it. These are the questions we think you should put to any developer, with our own answers.
How small a screen will it handle?
We lay pages out from the narrowest width upwards, so a phone gets a layout intended for it. Each build is checked at 320, 375, 430, 768, 1024, 1280 and 1440 pixels and wider, tap targets are sized for fingers, and wide tables scroll inside their own frame instead of pushing the page sideways.
Will it stay quick as pages and features pile up?
Speed is treated as a limit to stay inside from the first week. Each page loads only the code it needs, images use modern formats, rendering is decided page by page, and a slip in Core Web Vitals during development is handled like any other bug.
Where is the information people type in checked?
On the server, at every point where data enters, and never in the browser alone. Sign-in relies on established libraries, each service is given only the access it needs, secrets are kept out of the repository, and HTTPS and security headers cover the whole site.
Could a different developer take it over?
That is the test we build against. The code is written in TypeScript, screens are assembled from shared components, every change goes through Git with a history you can follow, and setup and deployment are written down so you are never tied to us.
Technology
What Will Your Site Run On?
We choose the tools for each project from what it has to do, how its data is shaped, and who will look after it later. A typical web build draws on some of these.
In the browser
- Next.js
- React
- TypeScript
Server and storage
- Node.js
- Laravel
- MySQL
- PostgreSQL
- Firebase
Hosting
- AWS
- Google Cloud
Getting started
What Does Your Site Need to Do?
Send us a note on who will use it, what it has to do and what it must connect to. We will come back with the questions that shape the plan, and then with the plan itself.