ENGINEERING · 5 MIN READ
Speed, security and maintenance: the invisible foundation of a good product
The quality of a digital product does not live in the interface alone. Performance, security, observability and maintainability decide whether a solution earns trust today and whether it can keep earning it in two years. They are also the first three things cut when the budget tightens.
Speed is a feeling before it is a metric
A website that appears without making you wait conveys focus and care. A slow one erodes trust before the content gets a chance to speak. The user does not think “this has a 4.2-second LCP”; they think “this is broken” and hit back.
That is why performance is a design decision from the first sketch, not an optimisation at the end. The decisions that weigh most are taken before any code is written: how many fonts get loaded, whether the content needs JavaScript to exist, how many third-party services are embedded.
| Metric | What it measures | Usual cause |
|---|---|---|
| LCP | How long the main element takes to appear | Unoptimised images and render-blocking CSS or fonts |
| CLS | How much content shifts while loading | Images without declared dimensions and late-injected ads |
| INP | How long it takes to respond to an interaction | Too much JavaScript running on the main thread |
A concrete and very common example: importing fonts with @import inside the CSS instead of a <link> tag in the <head>. The browser has to download and parse the stylesheet before it discovers it needs the fonts, chaining two waits where there could have been one. It takes a minute to fix and it shows.
RULE OF THUMB
Don't chase a perfect score in measurement tools. Chase performance no longer being an obstacle: content visible fast, nothing jumping while it loads, and an immediate response to the first click.
Security: the minimum that is not negotiable
Most incidents in small and mid-sized projects do not come from a sophisticated attack, but from basic hygiene nobody checked. This is the floor below which you should not accept a handover:
- HTTPS across the whole site, with redirection from HTTP and certificates that renew themselves.
- Dependencies updated and audited. A library unmaintained for three years is an open door with a date on it.
- Server-side data validation, not just in the browser. Client validation is convenience; server validation is security.
- Secrets out of the code. No API key in the repository, ever.
- Automatic and tested backups. A backup nobody has ever restored is not a backup, it is an assumption.
- Role-based permissions genuinely reviewed, not “everyone is an admin because it's faster”.
Observability: finding out before your customers do
A system that fails silently is worse than one that fails loudly. The reasonable minimum is centralised error logging, an automatic alert when the site stops responding, and a basic usage metric.
You do not need an expensive platform. You need someone to receive a notification when something breaks, and somewhere to look at what happened. The difference between finding out from an alert and finding out from an angry customer is the whole difference.
Maintainability: the cost that never appears in the quote
The development budget is visible; the maintenance one is not. And yet, across a project's multi-year life, the second usually exceeds the first.
What makes a project cheap to maintain is not mysterious:
- Standard, well-documented technology. If only three people in the world can maintain your stack, they set your maintenance cost.
- Few dependencies, chosen deliberately. Every library added is a commitment to keep updating it for years.
- Documented decisions, not just documented code. Knowing why something was done a certain way saves the next team weeks.
- A repeatable deployment process. If shipping is scary, you ship rarely — and the rarer you ship, the bigger and riskier each change becomes.
- Tests where it hurts if it breaks. You do not need to cover everything: you need to cover the money, data and access paths.
What to ask before accepting a handover
Five questions that reveal a lot about a project's real condition:
- When was a backup last restored to verify that it works?
- Who gets the alert if the site goes down on a Sunday?
- How long does it take to ship a one-line change?
- Which dependencies are on outdated versions, and why?
- If a new developer joined tomorrow, how long until they could touch the project?
Good engineering is noticeable precisely because it stops being a problem. It does not show up in the demo and cannot be screenshotted, but it determines whether in two years the project is still an asset or has become a liability.