BUILD SOFTWARE THAT SHIPS

WordPress runs a little over 40% of the web, and that scale is both its greatest strength and the source of its worst reputation. The platform is not slow. Badly assembled WordPress sites are slow, and there are a great many of them.

Where the speed actually goes

A WordPress install is a small, fast application. What slows it down is almost always something added afterwards: a page builder rendering nested wrappers ten levels deep, a slider plugin loading its own jQuery build, six plugins each registering a font stylesheet, uncompressed hero images served at 4000 pixels wide to a phone.

• Every active plugin is code that runs on every request — audit them quarterly and delete rather than deactivate
• Serve WebP or AVIF, size images to their display dimensions, and lazy-load everything below the fold
• Object caching and a CDN do more for real-world speed than any optimisation plugin
• Measure with Lighthouse and field data, not with a plugin's own score

What you get in return

You own the database, the files and the content. There is no per-seat pricing, no platform that can change its terms, and no export process to negotiate if you move hosts. For a business that intends to still be publishing in ten years, that ownership matters more than any single feature.

When to choose something else

WordPress is a content management system. If the thing you are building is primarily an application — a booking engine, a dashboard, a product with user accounts and complex state — you will spend more time fighting the CMS than using it. We build those on Node or Next.js instead, and we will tell you when that is the honest answer.

Choosing a platform is a ten-year decision disguised as a ten-minute one. The question is not which builder produces the nicest homepage this month — it is which one you can still afford, staff and extend when your business looks different.

Cost over time, not cost today

Hosted builders look cheaper at the start. The bill arrives later, as per-seat fees, transaction percentages, paid apps for functions that should be standard, and the cost of rebuilding entirely when you outgrow the platform. WordPress has hosting and maintenance costs that stay broadly flat as you grow.

Growth without replatforming

• Start with a brochure site and add commerce later without rebuilding
• Add multilingual content, memberships or a booking system as separate concerns
• Connect a CRM, an ERP or your own internal API through REST endpoints
• Move hosts, agencies or developers without asking anyone's permission

You are not locked to one agency

This is the part most agencies will not tell you: because WordPress skills are common, you are never trapped with the people who built your site. We think that is a feature. Work that has to be maintained by someone else eventually is work that gets written properly the first time.

The honest caveat

WordPress requires maintenance. Core, themes and plugins need updating, backups need testing, and an abandoned install becomes a security liability within months. Budget for upkeep from day one, or buy it as a monthly service — but do not pretend it is optional.

Building a successful website goes beyond aesthetics. It requires a structured approach balancing user experience, performance and long-term maintainability. The practices that matter in 2026 emphasise speed, accessibility and decisions made from data rather than taste.

Planning and architecture

The foundation is clear planning. Before a line of code is written, define the project goals, identify the audience and outline the features required.

• Analyse real user needs to guide design and functionality decisions
• Produce wireframes and user flow diagrams before visual design begins
• Agree success metrics at the start — conversion rate, bounce rate, load time
• Plan the information architecture so navigation is intuitive rather than improvised

Code organisation

Separate concerns: HTML for structure, CSS for presentation, JavaScript for behaviour. Use consistent naming and modular components. A codebase organised this way is easier to test, debug and hand over — and handover always happens eventually.

Performance

Page speed directly affects retention, rankings and conversion. Sub-two-second loads are now the baseline expectation, not an achievement.

• Images: serve WebP or AVIF, compress aggressively, lazy-load anything below the fold
• Scripts: defer non-critical JavaScript, preload essential assets, inline critical CSS
• Caching: combine browser caching, server-side caching and a CDN to cut latency
• Monitoring: audit with Lighthouse and track Core Web Vitals from real users, not lab tests alone

Mobile-first and accessible

Most traffic is on a phone, so mobile is the primary design target rather than an adaptation. Touch targets of at least 44×44 pixels, body text no smaller than 16px, sufficient contrast, no hover-only interactions, and a visible keyboard focus state throughout. Accessibility and SEO want the same things — semantic HTML, clear heading order, descriptive links — so doing one well tends to deliver the other.

Most trend lists are a catalogue of effects. The shifts that actually matter this year are quieter, and they are mostly corrections to the excesses of the last five.

Typography is doing the work again

Large, confident type with real hierarchy has replaced the era of identical cards and identical gradients. Variable fonts made this practical: one file, many weights, no extra requests. Sites are beginning to look like they were designed rather than assembled.

Motion with restraint

Scroll-triggered animation is everywhere, which is precisely why it has stopped being impressive. The pages that feel expensive now use one orchestrated moment — a considered load sequence, a single reveal — and leave everything else still. Every effect should also respect prefers-reduced-motion; a significant number of people have it enabled, and a page that ignores it can genuinely make them unwell.

Accessibility as an aesthetic constraint

• Contrast requirements are pushing designers away from grey-on-grey minimalism
• Visible focus states are being designed rather than removed
• Dark and light are treated as two designs, not one inverted

What is fading

Purple-to-blue gradient heroes. Rounded cards in threes. Stock illustration of people pointing at floating charts. Autoplaying video backgrounds that cost two megabytes before a word is read. None of it was ever wrong, exactly — it simply stopped saying anything, because everyone was saying it.

Most business software is written on fast office wifi and then used in a warehouse, a basement shop, a delivery van or a market stall. The connection is not absent — it is intermittent, which is considerably harder to handle. Offline-first means the app writes locally first and treats the network as an optimisation, not a prerequisite.

The local store is the source of truth

Every write goes to a local database — IndexedDB in the browser, SQLite on mobile — and returns immediately. The interface never waits for a server. A queue of pending changes drains in the background whenever a connection appears, and the user is never blocked by something they cannot control.

• Writes confirm instantly, so the app feels fast even on a good connection
• A dropped signal mid-invoice loses nothing
• The same code path handles online and offline, so offline is not a rarely-tested branch

Sync is where the real difficulty is

Two devices edit the same record while both are offline. When they reconnect, something has to decide what the truth is. Last-write-wins on a timestamp is simple and usually acceptable for business documents; per-field merging is better but considerably more work. What is not acceptable is silently discarding one side and telling nobody.

Deletes need tombstones

This is the failure that catches everyone. A record deleted on one device is simply absent when the other device syncs — and absence is indistinguishable from "not created yet", so the record comes back. A delete has to be recorded as an explicit tombstone that outlives the record it removed. We learned this the hard way in our own product, watching deleted items reappear after every restart.

Design for the reconnection, not the outage

Show clear state: what is saved locally, what is pending, what has synced. Users tolerate a slow connection perfectly well. What they will not tolerate is uncertainty about whether their work still exists.

For a great many businesses, WhatsApp is the customer relationship. Email goes unread, SMS looks like spam, but a WhatsApp message gets opened. The Cloud API makes that reachable programmatically — with a set of constraints the documentation describes only loosely.

You cannot message first, freely

Outside a 24-hour window opened by the customer contacting you, you may only send pre-approved message templates. Templates are submitted to Meta for review, take time to approve, and are rejected for reasons that are not always obvious. Plan template content early — it is not something to discover a week before launch.

Inbound media is a reference, not a file

When a customer sends an image, the webhook does not contain the image. It contains a media ID. Retrieving the actual file is a second authenticated request, and the URL you get back is short-lived. Any system that only stores the webhook payload will appear to receive empty messages.

Sanitise identifiers before storing them

Message IDs from Meta contain characters — dots among them — that several databases forbid in key paths. Firebase Realtime Database is one. Written naively, every inbound message is silently rejected, no error surfaces, and the inbox simply stays empty. Encode or hash the ID before using it as a key, and never use a third-party identifier as a path segment unchanged.

• Verify the webhook signature on every request — the endpoint is public
• Acknowledge with a 200 immediately, then process asynchronously; Meta retries on timeouts and you will get duplicates
• Store the message status callbacks — sent, delivered, read — they are the only delivery proof you get
• Attach documents as a proper PDF with a filename; a link gets fewer opens

Test with a real phone

Template rendering, document previews and link handling all behave differently on actual devices than in any simulator. Budget for real-device testing on both Android and iOS before you promise a client a delivery date.

Somebody will delete the wrong invoice. Not might — will. It is a question of when, and of what your software does about it. An application that removes the row immediately has made that mistake permanent and has made it your emergency.

Move, then remove

A soft delete marks a record as deleted and moves it into a recoverable area rather than destroying it. The user sees it disappear; the data is still there. A thirty-day window is a reasonable default — long enough to cover the realistic gap between a mistake and its discovery, short enough that storage stays sane.

• Record who deleted it and when, which resolves disputes later
• Keep deleted items out of every list, report and total, without exception
• Purge on a schedule, not on a timer at the moment of deletion
• Make restoring a single action, because it will be used under stress

The order of operations matters

Copy the record into the trash before removing it from the live collection. Reverse those two steps and any failure between them destroys the data permanently — the exact outcome the feature exists to prevent.

A tombstone must outlive the record

In any system with caching or multi-device sync, the deletion itself has to be stored as a durable fact. If deletion is represented only by absence, another device — or a stale local cache — will helpfully restore the record it still remembers. The tombstone is what tells the rest of the system that the absence is deliberate.

Regulated data is a separate question

Tax documents frequently may not be deleted at all within a statutory retention period. Understand the obligation before you build the feature — in some jurisdictions the correct behaviour is to cancel a document and keep it, never to remove it.

Speed scores are widely misunderstood. A site can report 98 in a lab test and still feel sluggish to real users, because the lab runs on a fast machine with a clean cache and no third-party scripts. What matters is field data: what actually happened on real devices.

The three measurements that count

• LCP — Largest Contentful Paint. How long until the main thing appears. Usually the hero image or headline. Target under 2.5 seconds.
• CLS — Cumulative Layout Shift. How much the page jumps around while loading. Caused by images without dimensions, late-loading fonts and injected banners. Target under 0.1.
• INP — Interaction to Next Paint. How long the page takes to respond when tapped. This replaced First Input Delay and is considerably harder to satisfy, because it measures every interaction rather than the first.

What moves them, in order of effect

Images. Almost always the largest thing on the page and almost always oversized. Serve WebP or AVIF, size to display dimensions, always set width and height attributes — that last one alone fixes most layout shift.

Third-party scripts. Chat widgets, analytics, ad tags and pixels are frequently the single biggest cause of poor INP, and they are the easiest to remove because nobody remembers why half of them were added.

Fonts. Use font-display: swap, preload the one face you need above the fold, and subset to the characters actually used. A full weight family can cost more than your hero image.

Measure honestly

Test on a mid-range Android phone over a throttled connection, not on the machine you built it on. Use Search Console's Core Web Vitals report for field data — it reflects real visitors, which is the only audience whose experience counts.