Web performance: from four seconds to under one

Start with the problem, not the feature

Every engagement begins with a clear statement of the problem and the metric that proves it is solved — activation, retention, conversion, time saved. Features are then ranked by how directly they move that number, not by how impressive they look in a demo.

This sounds obvious, yet it is the step most often skipped. Without it, roadmaps fill up with nice-to-haves and launches arrive months late with little to show for them. Teams argue about solutions because they never agreed on the problem, and every stakeholder quietly measures success differently.

We write the problem statement in plain language and keep it to a single paragraph: who is struggling, with what, how often, and what it costs them. If we can’t fill that paragraph with evidence from interviews, analytics or support tickets, we aren’t ready to design anything yet — and that is a far cheaper discovery to make in week one than in month six.

Talk to users before you sketch a screen

Five conversations with real users will teach you more than fifty internal meetings. We aim to speak with people who match the target audience before any wireframe exists, and we listen for the workarounds they have already built: the spreadsheet next to the official system, the WhatsApp group that replaced a broken notification, the sticky note on the monitor.

Workarounds are the most honest product requirements you will ever find. They show exactly where existing tools fall short, and people have already proven they care enough to solve the problem themselves.

• Ask about the last time they did the task — not what they usually do or would like to do.
• Watch them do it if you can; what people show you is often very different from what they tell you.
• Note every tool, tab and person involved. Each hand-off is a place where things go wrong.
• End by asking what they would change first if they could change only one thing.

Ship small, measure honestly

We work in two-week sprints with a working demo at the end of each one. Small releases are cheaper to build, easier to test and far less risky to deploy — and they give you real user data instead of opinions.

The goal of an early release isn’t to impress; it is to learn. A narrow first version that solves one painful problem well will beat a broad one that solves five problems badly, every time. It also gives the team a real product to improve, instead of a growing pile of assumptions to defend.

Measuring honestly means deciding what success looks like before the release, not after. We agree on the number we expect to move, by how much, and over what period. When results come in below expectations, that isn’t failure — it is the most useful information the project will produce all month.

Design for change, not for the launch

Launch day is the beginning of a product’s life, not the end of the project. The decisions that matter most are the ones that make the next hundred changes easy: a clear data model, well-named modules, an API that hides its internals, and a design system that lets new screens be assembled rather than invented.

We deliberately avoid cleverness that only its author can maintain. Boring, well-documented technology chosen for the problem at hand will outlive the trendy stack every time. When a client’s own engineers inherit the codebase, we want them to feel relief, not dread.

Architecture follows the same principle. Most new products are best served by a well-structured monolith that can be split later along the seams that real usage reveals. Splitting too early multiplies infrastructure, deployment and debugging costs long before there is any scale to justify them.

Make quality a habit, not a phase

Automated tests, code review, CI/CD and monitoring are set up in week one, not the week before launch. The result is software you can change confidently for years — which is what separates a product from a project.

Quality that is bolted on at the end is expensive and incomplete. Testers find problems when they are hardest to fix, deadlines force compromises, and the team learns to fear releases. Quality that is built into every day is nearly invisible: each change is small, reviewed and tested automatically, and deploying is as routine as saving a file.

• Every pull request is reviewed by another engineer and runs the full automated test suite.
• Each feature ships behind a preview environment that designers and clients can try before it merges.
• Accessibility and performance budgets are checked automatically, so regressions are caught the day they happen.
• Production is monitored from the first release, with alerts that reach a person, not an inbox nobody reads.

Communicate like a partner, not a vendor

The technical side of a project is rarely what clients remember. They remember whether they knew what was happening, whether bad news arrived early, and whether they could reach the people actually doing the work.

We give every client direct access to their engineers and designers, a weekly written update, and a live demo every sprint. When an estimate is wrong — and some always are — we say so as soon as we know, explain why, and offer options rather than excuses. Trust is built far more by how a team handles surprises than by how it handles the plan.

Keep improving after launch

The first weeks after launch are when a product learns the most. Real users take paths no one predicted, edge cases appear at scale, and the metrics finally have enough data to mean something. Teams that disband on launch day waste the most valuable feedback they will ever receive.

We plan for a stabilisation period immediately after every release, followed by a regular rhythm of small improvements driven by analytics, support conversations and user interviews. A quarterly review then steps back to ask the bigger questions: is the product still solving the problem we started with, and what should we stop doing?

Key takeaways

None of these habits are new, and none of them are difficult on their own. What makes them powerful is doing all of them, consistently, on every project — especially when a deadline makes shortcuts tempting.

• Agree on the problem and the metric before discussing features.
• Learn from real users and the workarounds they have already built.
• Release small, measure against expectations set in advance, and adjust.
• Choose simple, well-understood technology and structure it for change.
• Build quality into every day instead of saving it for the end.
• Share bad news early and keep improving long after launch.