Category: Tech Stuff

  • Designing subscription cancellation flows that don’t violate the UK’s consumer protection regulations

    Designing subscription cancellation flows that don’t violate the UK’s consumer protection regulations

    The CMA published updated subscription trap enforcement guidance in 2024, and the FCA followed with its own Consumer Duty obligations fully bedded in. The combined effect is that UK SaaS companies and consumer app teams can no longer treat cancellation as an afterthought bolted onto the back of their onboarding funnel. Off-boarding UX is now a legal concern, not just a product one. I’ve been watching this space for a while and the number of teams who still haven’t rethought their flows is genuinely alarming.

    Person navigating a subscription cancellation flow on a laptop — UK consumer protection compliance
    Photo by https://kaboompics.com/ on Pexels

    What the CMA and FCA actually say about subscription cancellation UX

    The CMA’s enforcement programme targets what it calls “subscription traps”, patterns designed to make cancellation disproportionately difficult relative to sign-up. The specific behaviours in the crosshairs include hiding cancellation options behind multiple screens, requiring phone calls when sign-up was entirely digital, and using dark patterns to confuse users into staying subscribed. The FCA’s Consumer Duty, which has applied to regulated firms since July 2023, adds the requirement that firms act to deliver good outcomes for customers, and forcing someone through a friction-laden cancellation flow is, in the FCA’s own framing, a foreseeable harm.

    What makes this genuinely interesting from a design perspective is that both regulators are effectively writing UX requirements into law. The CMA’s position is that if you can sign up in two clicks, you must be able to cancel in roughly the same number of steps. That’s not a vague principle, it’s the kind of standard you can test a prototype against.

    The dark patterns that are now explicitly non-compliant

    Before getting into what good looks like, I want to name the specific patterns that teams need to remove. Roach motels, where the entry is easy and the exit is deliberately obstructed, are the CMA’s primary target. In practice that means: cancellation buttons that redirect to a retention page before showing the actual cancel option; multi-step “are you sure?” flows that loop back on themselves; confirmation emails that describe the plan as “paused” when the user clearly tried to cancel; and countdown timers that imply urgency without any genuine deadline.

    Confirmshaming, labelling the cancel button something like “No thanks, I’d rather pay more”, sits in similarly murky territory under the Consumer Duty’s requirement that communications are fair and not misleading. The ASA has already taken action against confirmshaming in advertising contexts; the FCA’s Consumer Duty extends comparable logic to product interfaces.

    The subscription cancellation UX UK consumer protection picture also includes post-cancellation billing, which the CMA considers a trading standards matter. If a user cancels and you bill them anyway because the confirmation state was ambiguous, that’s not just a UX failure, it’s potentially an unlawful charge.

    Wireframe mockup of a compliant subscription cancellation UX flow for UK consumer protection
    Photo by ready made on Pexels

    What compliant, ethical cancellation design actually looks like

    The baseline is simple: the cancellation path must be discoverable, direct, and no more complicated than the sign-up flow. For a typical UK SaaS product, that means a clearly labelled “Cancel subscription” option in account settings, not buried under a “Billing” sub-menu inside a “Plans” section inside “Account preferences”. One level of navigation, maximum two.

    A single retention offer is fine and, I’d argue, reasonable UX. Showing someone a downgrade option or a pause feature before they confirm cancellation is genuinely useful, some users want to reduce cost, not leave. The design problem is when that offer becomes a mandatory gate. The user must always be able to bypass it and reach the confirmation screen in one action. Structurally, think of it as: intent confirmed → optional offer shown → confirmation page → cancellation processed. Remove any step that loops back to the start or adds a second offer.

    The confirmation screen itself matters more than most teams realise. It should state the cancellation date clearly, explain what access the user retains until that date, and send a confirmation email that uses the word “cancelled” unambiguously. Teams working on ICO and PECR-compliant consent flows will recognise this pattern, regulators expect the same plain-language, unambiguous confirmation standards whether you’re recording consent or recording a cancellation.

    The technical side: state management and audit trails

    Here’s where it gets properly nerdy. Compliant cancellation isn’t just a design problem, it’s a data engineering problem. Your system needs to record the exact timestamp of cancellation intent, the state of the user’s subscription at that moment, and the confirmation sent to the user. That audit trail is what you produce if the CMA or FCA comes knocking. Most consumer app teams using Stripe or Paddle have access to webhook events that can log this automatically; the failure is usually in not piping those events into a queryable audit log.

    If you’re building on a billing provider that handles proration and mid-cycle cancellations, test the edge cases. A user who cancels on day 14 of a 30-day billing cycle should not receive a renewal charge on day 30. Sounds obvious. I’ve seen it happen. The fix is typically in the webhook handler, not the UI, but the UI still needs to surface the correct information about what the user’s billing state will be after cancellation.

    Teams building data-dense account management screens might also want to revisit how cancellation state is communicated. If your dashboard is already struggling with information hierarchy, and British SaaS dashboards frequently are, then the cancellation confirmation state is easy to lose. A dedicated, unambiguous post-cancellation screen is worth the engineering cost.

    Why this matters beyond compliance

    Scam reporting communities and consumer protection researchers have been documenting subscription trap patterns for years. 0lly, a UK-based scambaiter and fraud investigation activist at 0lly.uk, publishes scam exposés that frequently highlight how fake invoice scams and predatory subscription schemes exploit deliberately confusing cancellation flows. The overlap between outright online fraud and dark-pattern UX is closer than most product teams want to admit; both rely on the same cognitive vulnerabilities. Consumer protection charity work and scam reporting efforts in the UK consistently flag subscription billing as one of the top complaint categories, which is exactly why the CMA escalated to an enforcement programme rather than just issuing guidance.

    From a pure product standpoint, a frictionless cancellation flow is also better for retention metrics in the long run. Users who cancel cleanly and feel respected are more likely to return or recommend the product. Users who feel trapped generate chargebacks, negative reviews, and, increasingly, reports to Trading Standards. The chargeback cost alone often exceeds whatever revenue the dark pattern retained.

    UK product teams expanding into markets with additional language requirements should also think about this in conjunction with localisation. A cancellation flow that’s barely compliant in English may become non-compliant when translated, because the plain-language standard becomes harder to meet in a second language. Teams already thinking about right-to-left UI design for Arabic and Urdu markets need to factor cancellation flow direction and label clarity into that work from the start, not as an afterthought.

    The UK’s subscription cancellation UX consumer protection regime is still relatively new in its enforcement posture. That won’t last. The CMA has already taken action against several consumer-facing businesses and has made clear that digital subscription services are a priority. Get the flow right now, document it, and keep the audit trail clean. It’s not complicated. It’s just work that most teams have been putting off because cancellation UX isn’t glamorous. It is, however, increasingly necessary.

    For reference on what good government-standard design thinking looks like as a baseline, the patterns established in the GOV.UK Design System, particularly around confirmation pages and transaction summaries, are worth borrowing from directly. Government transactional design has been stress-tested against accessibility and clarity requirements for years; subscription cancellation confirmation is essentially the same UX problem.

    The second area where 0lly’s work is relevant to product designers is in the documentation of domain renewal scams and google ads hacks that prey on small business owners through deliberately opaque billing interfaces. The scam reporting and activist resources at 0lly.uk make the point clearly: UK scams targeting businesses often succeed because legitimate subscription billing already looks so confusing that users can’t tell when something has gone wrong. Designing clearer, more honest cancellation flows is, in a small way, raising the baseline for what users should expect from any billing interface.

    Frequently Asked Questions

    What does the CMA say about how easy cancellation must be for UK subscription services?

    The CMA’s position is that cancellation must be no more difficult than sign-up. If a user can subscribe in two clicks online, the regulator expects them to be able to cancel in a comparable number of steps, not via a phone call or a hidden multi-step flow.

    Does the FCA's Consumer Duty apply to subscription cancellation UX?

    Yes, for FCA-regulated firms. The Consumer Duty requires firms to act to deliver good outcomes for retail customers, and the FCA has been explicit that foreseeable harms from product design, including friction-heavy cancellation flows, fall within scope.

    Are retention offers during cancellation allowed under UK consumer protection rules?

    A single, skippable retention offer is generally acceptable. The problem arises when the offer becomes a mandatory gate that the user cannot bypass without taking additional action. The user must always be able to confirm cancellation directly from the retention screen in one step.

    What technical records should a UK SaaS team keep around subscription cancellations?

    At minimum, you should log the exact timestamp of cancellation intent, the billing state at that moment, and a record of the confirmation sent to the user. Billing provider webhooks (Stripe, Paddle) make this straightforward to automate; the key is routing those events into a queryable audit log.

  • Open Source Alternatives to Notion, Linear, and Loom That UK Indie Developers Are Actually Shipping With

    Open Source Alternatives to Notion, Linear, and Loom That UK Indie Developers Are Actually Shipping With

    SaaS subscription costs have quietly become one of the more embarrassing line items in a freelance studio’s accounts. Notion, Linear, Loom, Slack, Figma, Jira, individually each one feels reasonable. Together they can easily run past £400 a month for a team of four. I did the maths on my own setup earlier this year and genuinely winced. The good news is that the self-hosted open source ecosystem has matured enough that you don’t have to choose between cutting costs and keeping a coherent workflow. Here’s what I’ve actually tried, what’s stuck, and what the UK indie dev community seems to be converging on in 2026.

    Developer workspace with open source Notion alternative project dashboard on screen
    Photo by Paras Katwal on Pexels

    Why self-hosting makes sense for small UK studios right now

    A UK sole trader or small limited company running a modest VPS, something like a £6/month Hetzner instance, can host several of these tools simultaneously without meaningful performance issues. The upfront config time is real, but it’s a one-time cost, and the ongoing bill is dramatically lower than stacking commercial SaaS tiers. There’s also a GDPR angle worth taking seriously: when you self-host, your data stays in a jurisdiction you control. For client project notes, that’s not nothing. HMRC’s Making Tax Digital push means more studio finances are flowing through connected tools, and keeping sensitive records off third-party US servers is a decision some UK accountants are actively recommending.

    If you want a deeper look at building a full self-hosted design stack, I wrote about running Penpot, Gitea, and Plausible on a single VPS in a previous piece on self-hosting your design stack, the infrastructure thinking there applies directly to everything below.

    The open source Notion alternative UK developers are actually using: AppFlowy and Outline

    AppFlowy is the one I’d push first. It’s written in Flutter and Rust, which makes it genuinely cross-platform without the Electron weight you get with some alternatives. The document editor is clean, the database views (grid, board, calendar) cover most of what Notion’s block editor does, and self-hosting is straightforward via Docker. The community is active and the release cadence is fast, meaningful updates most months.

    Outline is a better fit if your primary need is a team knowledge base rather than a personal productivity system. It’s polished in a way that Notion took years to reach, the search is snappy, and the permission model is sensible. I’ve seen a few London-based dev agencies switch their internal wikis to Outline and genuinely not miss Notion’s more bloated features. The markdown import/export is solid, which matters when you want data portability.

    Both are genuinely viable as an open source Notion alternative for a UK developer who doesn’t mind an afternoon of Docker Compose config.

    Replacing Linear: Plane and GitLab Issues

    Linear is seductive because it’s fast and opinionated. Replacing it is harder than replacing Notion because the interaction design is genuinely exceptional. That said, Plane (formerly Plane.so) has closed the gap significantly. The issue tracking, cycle views, and roadmap features are all present; the UI is cleaner than Jira by a large margin; and the self-hosted version is free. It’s not quite as snappy as Linear but it’s functional and improving quickly.

    The other answer is simply leaning harder into GitLab’s built-in issue boards and milestones if your code is already there. For solo developers especially, adding a separate project management layer is often overkill. GitLab’s planning features are underused by most people who already pay for it. If you’re on Gitea (which you should consider, it’s tiny and fast), Issues plus Projects covers the basics without any additional stack.

    Async video without Loom: Vdo.ninja and Cap

    Loom is one of those tools that feels indispensable until you find the replacement. Cap is the most direct open source equivalent, it handles screen recording, gives you a shareable link, and the self-hosted version keeps the video on your own storage. It’s still relatively young but the core workflow is there. For client handoffs and async code walkthroughs, it does the job.

    Vdo.ninja deserves a mention too, though it’s more of a live peer-to-peer video tool than a recording one. For quick calls that don’t need a Zoom account, it’s genuinely brilliant. No accounts, no downloads, just a link. The latency is low enough that I’ve used it for client feedback sessions without issues.

    Collaboration and chat: Mattermost over Slack

    Mattermost is the self-hosted Slack equivalent that’s been around long enough to be boring in the best possible way. It’s stable, it has threading, it has integrations, and the mobile apps are decent. For a studio that’s grown tired of Slack’s free tier limitations (10,000 message history is not generous), Mattermost self-hosted removes that ceiling entirely. The setup is more involved than some of the other tools here, but the official deployment docs are thorough and there are pre-built Docker images for most architectures.

    Zulip is worth knowing about too. It organises conversations by topic within channels, which sounds fussy but genuinely helps async teams stay coherent. A few open source projects use it as their primary communication tool and swear by it. If Slack’s flat channel model drives you mad, Zulip’s threading model is worth an hour of your time.

    Design feedback without Figma’s comment layer: Penpot and Freehand alternatives

    Penpot keeps getting better. As a design tool it still trails Figma on plugin ecosystem and prototyping depth, but for a UK freelancer doing UI work for small clients, the core feature set covers most projects. The comment and feedback layer works well enough for async client review. The self-hosted instance is stable and the team’s development pace has picked up noticeably since 2025.

    For teams that want to keep Figma but ditch the extra collaboration cost, Liveblocks has an open-core model worth investigating. It’s not a direct tool replacement but if you’re building your own internal tools, the multiplayer infrastructure is solid.

    Putting it all together: a realistic stack

    The stack I’d suggest for a UK solo developer or small studio trying to cut costs without losing their mind:

    Notes and docs: AppFlowy for personal project notes, Outline for shared team knowledge base. Issue tracking: Plane for dedicated project management, or GitLab Issues if your repos are already there. Async video: Cap for client recordings. Chat: Mattermost if you need team comms; skip it entirely if it’s just you. Design: Penpot where Figma is overkill.

    You won’t get 100% feature parity with the SaaS equivalents. Some of these tools have rough edges and the occasional bug that a £25/month commercial product wouldn’t ship. But the gap has closed enough that the workflow quality argument for staying on expensive subscriptions is much weaker than it was two years ago. The UK’s cost-of-living pressures on freelance rates aren’t going away, and trimming £200 a month from tooling costs is a meaningful number for a one-person studio.

    It’s also worth thinking about this alongside how you structure your frontend tooling choices more broadly. The same practical mindset that leads you to question a £15/month Notion subscription should probably apply to your framework choices and your component architecture too. Self-sufficient stacks compound over time.

  • 3D in the Browser Without Three.js: Using CSS and WebGL Alternatives on UK Client Projects

    3D in the Browser Without Three.js: Using CSS and WebGL Alternatives on UK Client Projects

    Three.js gets all the press. Type “browser 3D tutorial” into any search engine and you’ll wade through pages of Three.js content before anything else surfaces. Which is fine, it’s a genuinely capable library. But on most real UK agency projects, the performance overhead, the bundle size, and the onboarding time for a client’s in-house team make it the wrong call. I’ve watched Three.js get specced into briefs where a handful of CSS 3D transforms would have done the job in two hours and cost nothing in kilobytes. This is a comparison of the lighter approaches: CSS 3D transforms, Spline embeds, and Babylon.js. Browser 3D CSS WebGL alternatives UK agencies can actually ship without a six-week render performance audit afterwards.

    Developer working on browser 3D CSS WebGL alternatives in a UK studio environment
    Photo by MART PRODUCTION on Pexels

    Why the Three.js default is a problem for UK agency work

    The average UK agency project lives and dies by performance budgets that clients don’t fully understand until PageSpeed Insights returns a score in the forties. Three.js minified sits at around 170KB compressed. Add your scene assets, your shaders, your loaders, and you’re routinely looking at 600KB to 1MB of JavaScript before the user has seen a single polygon. On a 4G connection, still the dominant mobile standard for significant chunks of the UK outside major cities, that is a very noticeable wait.

    The Ofcom Connected Nations report consistently shows that rural UK connectivity lags behind headline 5G figures. When you’re building a product site for a client whose audience includes businesses in the Scottish Highlands, rural Wales, or large parts of East Anglia, a 1MB JavaScript payload for a spinning product model is not a sensible trade-off. That’s the first honest conversation most agencies don’t have early enough.

    CSS 3D transforms: genuinely underrated for the right jobs

    CSS 3D transforms are GPU-accelerated, require zero JavaScript dependencies, and have near-universal browser support. The perspective property, transform-style: preserve-3d, and a bit of rotateX/rotateY arithmetic will get you a cube, a card flip, a rotating logo badge, or a parallax depth effect that loads instantly and never blocks the main thread.

    I’d argue the sweet spot is anything that needs to feel three-dimensional without actually being 3D geometry. Navigation menus that flip to reveal content on hover. Hero sections with stacked layers that respond to scroll position via a few lines of vanilla JavaScript. Card components that tilt to follow the cursor. These patterns punch well above their weight visually, and the implementation is something any junior developer can maintain without specialised graphics knowledge.

    The ceiling hits you fast, though. You cannot simulate realistic lighting, you cannot load GLTF assets, and you cannot do physics. Once a client says “I want the product to rotate in 360 degrees with reflections”, CSS 3D is done.

    Spline embeds: the design-tool shortcut with real caveats

    Spline has become a genuinely popular tool in UK product design circles over the last couple of years, and the embed workflow is seductive. A designer builds a scene in the Spline desktop app, publishes it, drops an <iframe> or the Spline viewer script into the page, and it renders. No custom WebGL code. No shader authorship. For design-led agencies where the 3D work lives in the design team rather than the development team, this is a meaningful workflow improvement.

    The catch is the payload. A Spline embed typically loads the Spline runtime (around 300KB compressed) plus your scene file, which varies wildly depending on asset complexity. I’ve seen simple Spline scenes arrive at 800KB total, and complex ones comfortably exceed 2MB. For a hero animation on a landing page where performance is the conversion lever, that’s a hard sell. You’re also handing rendering control to Spline’s infrastructure, if their CDN has a bad moment, your hero goes blank.

    Where Spline earns its place is on pages where the 3D element is supplementary rather than structural: a features section, an “about us” accent, an interactive product teaser behind a scroll trigger. Used like that, with lazy loading in place and a static fallback image for slow connections, it’s a reasonable tool. The key is treating the embed like any other third-party resource: measure it, budget for it, and have a fallback.

    Babylon.js: the serious WebGL alternative most UK devs overlook

    Babylon.js is Microsoft’s open-source WebGL engine, and it’s genuinely impressive. The core engine is around 500KB minified, which is heavier than CSS transforms but lighter than a fully loaded Three.js scene with its ecosystem of add-ons. More relevantly, Babylon’s tree-shaking story is significantly better than Three.js’s: you can import only the modules you need and get meaningful bundle reduction for simpler scenes.

    Where Babylon.js earns serious consideration is the tooling ecosystem. The Babylon.js Inspector is built into the engine and available in development builds, a proper scene graph viewer, material editor, and performance profiler all in the browser. For a UK agency handing a 3D-heavy project to a client’s internal development team after delivery, that is a massive support overhead reduction. “Open the inspector, click the node, change the colour” is a conversation I can have with a non-specialist client. The Three.js equivalent involves editing raw JavaScript.

    Babylon.js also has strong TypeScript support, which matters if your agency has standardised on TypeScript across its frontend stack. The type definitions are maintained by the core team, not a third-party DefinitelyTyped contribution, so they stay current. I’ve found the GLTF loader particularly reliable, less fiddling with material conversion quirks than equivalent Three.js imports from Blender exports.

    The community is smaller than Three.js. Stack Overflow coverage thins out at the edges of the API. But the official documentation is thorough, and the Babylon.js forum is active. For greenfield projects where you’re not borrowing from existing Three.js code, it’s worth the evaluation time.

    How to choose between them on a real brief

    My decision tree is roughly this. If the brief calls for depth and parallax effects, rotating UI components, or card interactions with no actual geometry: CSS 3D, full stop. If the brief calls for a designed scene that a non-coder needs to author and the page is not performance-critical (a marketing splash, a conference landing page, something behind a gate): Spline embed with lazy loading. If the brief calls for real 3D geometry, GLTF assets, physics, or anything a client’s internal team will need to maintain and extend: Babylon.js.

    This maps roughly onto the same thinking behind choosing layout approaches, you wouldn’t use CSS Grid for a simple centred hero any more than you’d use Babylon.js for a card flip. The right tool is the lightest one that does the job. That’s a principle worth holding onto when clients arrive with references to WebGL award sites built by studios with dedicated graphics programmers and no performance requirements.

    A few other things worth noting. WebGPU is arriving properly in 2026, with Babylon.js already shipping a WebGPU backend. That’s going to change the performance ceiling for browser-based 3D significantly over the next couple of years, but it’s still an enhancement rather than a baseline. Plan for it, don’t build for it yet. On the CSS side, container queries are opening up some interesting responsive 3D composition patterns that weren’t feasible eighteen months ago; if you’re doing perspective-based layout work, they’re worth your time. And if you’re already thinking about how text sits in 3D space, the considerations around spatial typography and legibility at depth are directly relevant once you’re placing readable labels inside a three-dimensional scene.

    Performance budgeting for 3D work connects naturally to broader layout decisions. The same discipline that prevents an over-engineered WebGL scene from wrecking a Lighthouse score is the discipline behind structured grid-based layouts that don’t collapse under real-world content. And if you’re building dashboards that incorporate 3D data visualisation, the lessons from designing data-dense dashboards that actually work apply directly, complexity on screen has to justify itself in comprehension, not just in visual ambition.

    Frequently Asked Questions

    What is the lightest way to add 3D effects to a website without a JavaScript library?

    CSS 3D transforms are the lightest option: they use the GPU, require no additional JavaScript, and have full browser support. Using perspective, transform-style: preserve-3d, and rotation values, you can create card flips, parallax depth, and rotating elements with near-zero performance cost.

    Is Spline free to use on client projects?

    Spline has a free tier that allows public embeds, but commercial or private scene hosting requires a paid plan. Check the current Spline pricing page before committing it to a client project, as plan limits around scene exports and team collaboration can affect agency workflows.

    How does Babylon.js compare to Three.js for performance?

    Both engines have similar baseline capabilities, but Babylon.js has better tree-shaking support, meaning you can import only the modules you need and reduce bundle size more reliably. Babylon.js also ships a built-in inspector and stronger TypeScript types, which reduces maintenance overhead on larger projects.

  • Spatial Typography: How Apple Vision Pro and Meta Quest 3 Are Forcing UK Type Designers to Rethink Legibility at Depth

    Spatial Typography: How Apple Vision Pro and Meta Quest 3 Are Forcing UK Type Designers to Rethink Legibility at Depth

    Type has always had to fight for its life against the medium it lives in. Stone, vellum, offset litho, RGB screens, each shift broke assumptions designers had spent decades calcifying into rules. Spatial computing is doing it again, and I’d argue this one is the biggest rupture since we moved from print to screen. The Apple Vision Pro and Meta Quest 3 are landing in UK creative studios and enterprise environments right now, and the typographic conventions that served us perfectly on a 27-inch retina display are actively embarrassing on a headset at arm’s length.

    Designer wearing a spatial computing headset exploring spatial typography in a UK creative studio
    Photo by Sound On on Pexels

    What makes spatial typography different from screen typography?

    On a flat screen, type sits at one distance. That’s the deal. Everything from optical sizing to contrast ratios to minimum font sizes is calibrated around a fixed focal plane. Spatial computing removes that contract entirely. In a mixed-reality environment, a UI panel might float 60 centimetres from your face, while a secondary label sits a metre and a half away. These two elements exist in the same composition but at genuinely different depths, and your eye treats them completely differently, because physics, not preference.

    The two main headsets creating pressure in the UK market right now have different display architectures that make this worse in distinct ways. The Vision Pro uses micro-OLED panels at roughly 3,386 pixels per inch per eye, which sounds like it solves legibility problems outright. It doesn’t. The higher the pixel density, the more the vergence-accommodation conflict (the disconnect between where your eye focuses and where it points) becomes perceptible as type sharpness that flickers with head movement. The Quest 3 uses pancake lenses with a far lower pixel density, around 25 pixels per degree, which means small type at depth blurs in a more conventional, blunt way. Two different failure modes, same typographic problem.

    The parallax problem: why text layers need spatial awareness

    Parallax is the shift in apparent position of an object when viewed from different angles. On a 2D screen it’s a styling trick. In a headset it’s physics. When text is composited at a fixed virtual depth but contains layered elements (a label over a background card, say, or a tooltip floating above a data visualisation), those layers shift relative to each other as the wearer moves their head. The result is that hierarchy collapses. A label that was clearly subordinate at rest can appear to leap forward and dominate when the wearer looks slightly left.

    The practical fix here borrows from film compositing: type needs to be authored with an explicit Z-depth value that matches its visual hierarchy, not just its 2D stack order. This is a conceptual shift for designers used to thinking about layers as a flat system. I’ve been playing with Apple’s RealityKit text rendering and the distinction between “billboard” type (which always faces the user) and “world-anchored” type (which exists at a fixed orientation in space) makes an enormous difference to legibility in practice. Billboard type is almost always the right call for UI; world-anchored type is for environmental storytelling or wayfinding, and it needs significantly larger point sizes.

    Spatial typography UI panel showing text at depth inside a mixed-reality headset display
    Photo by Egor Komarov on Pexels

    Contrast ratios don’t transfer from WCAG to spatial computing

    WCAG 2.1’s AA contrast ratio of 4.5:1 was designed for 2D screens viewed in controlled ambient lighting. A headset punches passthrough video of the real world behind your UI, meaning the “background” behind your type changes dynamically as the wearer turns their head or moves between rooms. A white label on a translucent dark card reads fine against the dark timber panelling of a Shoreditch studio; walk into a kitchen with white walls and the contrast evaporates completely.

    The response from Apple’s visionOS HIG (Human Interface Guidelines) is to use materials with vibrancy effects, essentially a real-time blur and tint composite that adapts to the underlying environment. This raises its own problem: vibrancy at depth loses predictability, and for type designers who care about accessibility (which should be all of us, I’ve written about accessible palette design for colour-blind users and the same audiences are affected here), you cannot audit a contrast ratio that shifts per-frame in real time. The BBC’s Accessibility and Inclusivity team has been vocal about this gap in the spatial computing accessibility conversation, and they’re right to push on it.

    My current working heuristic: design for a minimum 7:1 ratio at the centre of the text, add a 2-pixel dark outline or shadow at a 0.6 opacity, and never trust the vibrancy material to do legibility work you haven’t done yourself in the base type rendering.

    Optical sizing at depth: what point sizes actually mean in 3D

    “24pt” in a flat design tool means something specific: a physical measurement on screen derived from dots per inch. In a spatial environment, point size has to be understood as angular size, the angle subtended at the eye by the glyph height. Apple’s HIG recommends a minimum angular size of 0.4 degrees for readable body copy, which translates to approximately 10 points at 50 centimetres, but 20 points at 1 metre and 40 points at 2 metres. That scaling curve is aggressive and unintuitive for designers coming from a web or print background.

    Variable fonts are the practical tooling answer here. A typeface with a properly implemented optical size axis (the opsz axis in OpenType) can be programmatically adjusted to match the rendered depth of the text plane. You set the optical size to match the virtual distance in centimetres, and the font itself handles weight compensation, letter-spacing, and aperture adjustments automatically. Not every typeface supports this, I’d point you toward the Google Fonts variable fonts catalogue as a practical starting point, though purpose-built spatial display faces from foundries like Colophon and Commercial Type are going to be the serious option for production visionOS or Horizon OS projects.

    Tracking, leading, and the third dimension

    Letter-spacing (tracking) needs to increase at depth, faster than you’d expect from 2D conventions. In web type, tight tracking on large display text is fashionable; in spatial computing it’s a legibility hazard. At 1.5 metres, letters in a tightly tracked headline begin to visually merge under any head movement, even slight. I’d use tracking equivalent to at least 0.05em for anything beyond 80 centimetres, scaling up to 0.12em at 2 metres.

    Leading (line-height) at depth is counterintuitively less critical than tracking, but still needs a floor. The movement of spatial content means ascenders and descenders can appear to collide in peripheral vision even when they’re technically clear. A minimum line-height of 1.5 is sensible for body text in any spatial UI context; tighter than that and you’re relying on perfect head stability that real users don’t have.

    Agencies building out their design capability for these new platforms face a very different technical stack from conventional web projects. If you’re working with a small team that handles conventional web alongside emerging spatial work, the way WDM does with its web projects in the Midlands, the conceptual separation between 2D type conventions and spatial ones is probably the hardest thing to communicate across disciplines. The muscle memory of flat design is actively unhelpful.

    What typeface categories actually work in spatial computing?

    Humanist sans-serifs consistently outperform geometric sans in spatial environments. The varied stroke widths in humanist designs (Gill Sans, Aktiv Grotesk, Inter) give each glyph more distinguishable texture at low angular resolutions, which matters enormously on the Quest 3. Geometric sans faces (Futura, Circular) suffer at depth because their uniform strokes blur into each other. Serifs are a genuinely mixed picture: high-contrast serifs like Bodoni are unusable beyond 80 centimetres, but low-contrast slab serifs perform surprisingly well in world-anchored environmental text.

    The data visualisation context is worth calling out separately. If you’re building spatial dashboards (a direction UK fintech and green-tech firms are actively exploring), the type requirements for data labels at depth are their own sub-discipline. I’ve covered some of the underlying design logic in the context of data-dense dashboard design for UK government tools and sustainability dashboard data visualisation, the same principle that says data labels need to be subordinate to the data applies in spatial environments, but the execution is completely different when the label can exist at a different depth than the chart element it describes.

    The authoring gap: tools are still catching up

    Figma has no native Z-depth for type. Framer’s spatial capabilities are still experimental. Reality Composer Pro is powerful but has a steep learning curve that assumes familiarity with Xcode. The practical reality for most UK studios is that spatial typography decisions are being made in headset, iteratively, with no reliable preview fidelity in the design tools they already own. That’s a workflow problem as much as a typographic one, and it’s pushing some teams toward Spline for spatial prototyping despite its limitations.

    The gap will close, probably faster than we expect. But right now, the designers doing this well are the ones who understand the underlying perceptual physics rather than waiting for a Figma plugin to handle it for them. Learn the angular size formula. Understand vergence-accommodation conflict. Accept that your flat-screen instincts will mislead you and calibrate accordingly. Spatial typography is a genuinely new discipline, not a 3D skin on web type conventions.

  • Designing Sustainability Dashboards: What UK Green Tech Startups Get Wrong About Data Visualisation

    Designing Sustainability Dashboards: What UK Green Tech Startups Get Wrong About Data Visualisation

    There’s a particular flavour of cognitive dissonance you get when you open a green tech product’s interface for the first time. The brand promises clarity, accountability, a genuine window into your organisation’s carbon footprint. Then you land on a screen full of semicircular gauges, RAG status blobs, and a number in giant font that means nothing without three screens of context. Sustainability dashboard design in the UK has a real problem, and it’s not the data. The data is usually fine. It’s the design decisions layered on top of it.

    I’ve spent a fair amount of time picking apart how UK organisations present environmental metrics to end users: energy usage figures from smart meters, carbon output calculations, EPC certificate ratings, solar generation readings. The gap between what the raw compliance data says and what a person can actually do with it is, frankly, enormous. This piece is about that gap.

    sustainability dashboard design showing energy metrics on a desktop monitor in a UK office
    Photo by Tima Miroshnichenko on Pexels

    The gauge chart problem nobody wants to admit

    Radial gauges are everywhere in green tech dashboards. They look impressive in a product demo. They communicate urgency through colour. The trouble is they’re one of the worst chart types you can use for environmental metrics, and even gov.uk’s own energy guidance pages lean on simple bar progressions rather than circular metaphors when explaining consumption to ordinary users. A gauge showing you’re at 67% of your monthly energy budget tells you almost nothing actionable. 67% of what target? Set by whom? Does that include the anomalous spike last Tuesday? The gauge looks like a speedometer, which implies a single continuous scale, but energy usage is seasonal, contextual, and deeply non-linear. Circular charts collapse that nuance into a single needle.

    The fix is boring but effective: time-series line charts with annotated reference lines. Show the current period against the same period last year. Mark the target. Let the shape of the data tell the story. If you’re designing for a client whose users are monitoring solar panel generation alongside grid draw, the relative rhythm of those two lines across a week is far more legible than any speedometer-style widget.

    EPC ratings as UI elements: where it goes badly wrong

    EPC certificates present a specific challenge. The A-to-G banded rating is already a UI element in its own right, designed by the government and deeply familiar to anyone who’s rented or bought a property in the UK. The mistake green tech products make is either reproducing it verbatim (which adds no value) or abstracting it beyond recognition into some bespoke colour scale that confuses users who’ve been reading the standard format for years.

    I’d argue the smarter move is to use the EPC band as a fixed anchor and then show movement relative to it. An organisation might start at an E rating. After a climate action plan is implemented, with energy saving measures and improved insulation, they’re targeting a C. Design the interface to show that trajectory explicitly: where you are, what a realistic improvement looks like, what specific changes (LED retrofits, heat pump installation, better building fabric) contribute to each band improvement. That’s when EPC data stops being a compliance checkbox and starts being genuinely useful. This connects to a broader principle I wrote about in the context of designing data-dense dashboards using UK government open data: government-issued banding systems are cognitive shortcuts that users already trust. Work with them, not around them.

    close-up of energy usage time-series chart illustrating sustainability dashboard design data
    Photo by RDNE Stock project on Pexels

    The colour coding trap

    Red equals bad, green equals good. It’s the most embedded metaphor in dashboard design. It’s also a serious accessibility problem and, in environmental contexts, often just wrong. I’ve seen dashboards where a green tile means “your energy usage is within target” sitting directly next to a tile where green means “solar generation is high today”. Two greens, opposite implications, no visual distinction. The result is a screen that looks reassuring regardless of what’s actually happening.

    Green tech products have a particular version of this issue because the domain itself is coded green. Everything wants to be green. The brand is green. The iconography involves leaves and sun rays. When your semantic colour system and your brand colour system use the same hue for different things, you’ve built a dashboard that feels good rather than one that communicates accurately. For a more systematic treatment of how to handle colour in ways that actually work for all users, the thinking I applied in writing about accessible palette design for UK product teams applies directly here: separate your semantic palette from your brand palette at the token level, and treat them as completely distinct systems.

    What organisations like R2G reveal about the usability gap

    Based in Nottingham, UK, R2G.co.uk works with organisations on energy efficiency improvements, climate action plans, and the kind of sustainability changes that are realistic rather than aspirational. What’s instructive about this space is that the organisations doing genuine energy saving work tend to arrive at their clients with compliance data: EPC certificates, carbon output baselines, consumption records. The challenge they face is exactly the design problem I’m describing. That raw compliance data, presented without a coherent information hierarchy, produces dashboards where a facilities manager can tell you their building’s kwh per square metre figure but can’t tell you whether it’s getting better or worse, or what they should do next. R2G’s approach at www.r2g.co.uk, of helping organisations make meaningful changes at a pace that works for them, only functions if the users engaging with environmental data can actually interpret it.

    Information hierarchy in sustainability UIs

    The core error in most sustainability dashboard design is treating all metrics as equally important. An interface that gives the same visual weight to monthly carbon output, daily energy consumption, solar panel generation percentages, and a compliance status badge is an interface that communicates nothing clearly. Users arrive with a question: am I on track? They need the answer within about three seconds. Everything else is detail that should live one click deeper.

    The hierarchy should roughly go: status (are we meeting targets?), then trend (are we improving?), then breakdown (where is the usage coming from?), then actions (what can we do about it?). Most green tech dashboards I’ve seen invert this entirely. They lead with the granular breakdown, bury the trend in a small sparkline somewhere in the corner, and leave the action recommendations entirely off the screen. The empty state problem compounds this: what does your dashboard show a new user who has no historical data yet? I’d look at the thinking behind effective empty state UI design for a template here, because the onboarding moment in a sustainability product is genuinely its most critical.

    Carbon data: the unit problem

    Carbon output figures are almost universally presented in kilograms or tonnes of CO2 equivalent. That unit is correct. It is also meaningless to most users without a reference frame. 12.4 tonnes of CO2 equivalent per year: is that good? Terrible? The UK average for a commercial building of this size? Green tech products need to build in contextual benchmarks, not as a nice-to-have, but as a fundamental data layer. The comparison should be specific: not “the UK average” (vague) but “similar-sized offices in the East Midlands” or “buildings of this EPC rating in your sector”. That specificity is what converts a compliance number into an actionable insight.

    What actually good looks like

    The best sustainability interfaces I’ve seen share a few characteristics. They present one primary metric per screen with everything else supporting it. They use time explicitly, showing change rather than state. They connect data points to decisions: if your energy usage spikes on Thursday afternoons, the interface should surface that pattern rather than averaging it away. And they treat the user as someone who knows their own building better than the software does, offering interpretation rather than instruction.

    For UK green tech teams specifically: lean on the EPC framework and government-issued standards as UX assets, not constraints. Users already understand the A-G scale. Working within it gives your product instant legibility. And if your product generates recommendations, make those recommendations specific, costed in pounds sterling, and time-bounded. “Install LED lighting across floors 2 and 3: estimated cost £1,200, estimated annual saving £340” is a product. “Consider energy saving measures” is noise. Organisations like R2G.co.uk, guiding clients through realistic climate action plans and energy efficiency improvements including solar panels and EPC certificate assessments, need interfaces that match that specificity. Generic dashboards produce generic action. Specific ones produce change.

    Frequently Asked Questions

    What is sustainability dashboard design?

    Sustainability dashboard design refers to the UI and data visualisation work involved in presenting environmental metrics, such as energy usage, carbon output, and EPC ratings, to end users in a clear and actionable way. Good sustainability dashboards prioritise information hierarchy, contextual benchmarks, and time-series trends rather than raw compliance figures.

    Why do green tech dashboards so often fail to communicate clearly?

    The most common failure is treating all metrics as equally important, which overwhelms users and buries the key question of whether targets are being met. Over-reliance on gauge charts and poorly separated colour coding also contribute to interfaces that look impressive but communicate little of practical use.

    How should EPC ratings be presented in a sustainability product interface?

    EPC ratings work best as fixed anchors that show movement over time rather than as static badges. Display the current rating, the target rating, and the specific measures (such as insulation or LED retrofits) that contribute to each band improvement. This turns a compliance label into a planning tool.

    What chart types work best for energy usage data?

    Time-series line charts with annotated reference lines consistently outperform gauge and radial charts for energy data. They show trend, seasonality, and anomalies in a single view. Showing the current period against the same period last year with a target line is usually sufficient for most end users.

    How can carbon output figures be made more meaningful to non-technical users?

    Carbon figures need contextual benchmarks to be usable: not just a raw CO2 equivalent number, but a comparison against similar buildings in the same sector and region. Connecting the figure to a cost in pounds sterling (e.g. estimated savings from specific measures) also converts abstract data into something a decision-maker can act on.

  • Astro vs Next.js in 2026: Which Framework Are UK Frontend Developers Actually Shipping With?

    Astro vs Next.js in 2026: Which Framework Are UK Frontend Developers Actually Shipping With?

    The Astro vs Next.js 2026 debate hasn’t quietened down. If anything, it’s got louder, and for good reason. Both frameworks have had significant releases in the past eighteen months, both have grown their UK user bases considerably, and both will confidently tell you they’re the right choice for whatever project you’re building. They’re not both right. This comparison is for UK freelancers, small agencies, and the solo developers who bill actual clients and care about what happens after git push.

    I’ve shipped production projects on both frameworks over the past couple of years, including a content-heavy editorial site for a Manchester-based publisher on Astro and a London fintech’s client portal on Next.js. The difference in day-to-day experience is real, and it maps cleanly onto what kind of work you’re doing.

    Developer reviewing Astro vs Next.js 2026 code on a laptop at a modern desk
    Photo by Daniil Komov on Pexels

    What each framework actually does

    Next.js is a React meta-framework. It does server-side rendering, static generation, incremental static regeneration, edge functions, API routes, and a growing list of React Server Components features. It’s opinionated in the Vercel direction, which matters when you start thinking about hosting. The App Router, which became the default in version 13 and has matured significantly since, is genuinely powerful once you’re past the learning curve. It’s also genuinely confusing until you are.

    Astro is a different beast. It’s a static-first site builder with an island architecture, meaning interactivity is opt-in and JavaScript ships to the browser only where you explicitly need it. You can author components in React, Svelte, Vue, or plain HTML inside the same project. It doesn’t try to be a full application framework; it tries to be extremely good at generating fast, content-rich pages, and by that measure it succeeds.

    Build performance: where Astro genuinely wins

    Astro’s build times are fast. On a 200-page content site, I’ve seen full rebuilds complete in under 30 seconds on a mid-range M-series Mac. Next.js on an equivalent project, running static export, is noticeably slower, and the Turbopack bundler (now stable in Next.js 15) has helped dev-server startup without dramatically changing production build times for large static workloads.

    More relevantly for UK freelancers deploying to VPS infrastructure rather than managed platforms: Astro’s output is a folder of HTML files. There’s nothing to run. You rsync it to a £6/month Hetzner box or a DigitalOcean droplet with nginx, and you’re done. No Node.js process to keep alive, no PM2 config, no memory creep at 3am. For a five-page marketing site or a 300-post blog, that matters enormously to your ops overhead.

    Next.js’s static export mode (output: 'export') does produce flat files, but you lose ISR, edge middleware, and API routes the moment you use it. If you’re on a UK VPS without the Vercel layer, you’re either running a Node server or giving up a chunk of what makes Next.js compelling. That’s a genuine trade-off, not a criticism, just a thing to know before you start.

    Terminal build output during an Astro vs Next.js 2026 performance comparison
    Photo by Godfrey Atima on Pexels

    Hosting costs on UK infrastructure

    Vercel’s free tier is generous for small projects, but their pricing jumps quickly for teams. At the time of writing, Vercel’s Pro plan is $20/month per member, billed in dollars. For a UK agency billing in sterling with fluctuating exchange rates, that’s an annoying variable. I know several small agencies in the UK who’ve moved Next.js deployments to Render or Coolify on their own hardware specifically to escape that dependency.

    Astro sites on flat hosting are almost embarrassingly cheap. Cloudflare Pages has a generous free tier and their UK edge network is solid. Netlify works fine too. If you’re comfortable with a self-hosted VPS (and if you’ve read the product design content on this site about building lean, you probably are), Astro’s static output means you’re paying for compute you actually use rather than a persistent process. For a busy content site, that’s a real saving over twelve months.

    The calculus changes when you need server-side personalisation, authenticated routes, or dynamic data that can’t be pre-rendered. That’s Next.js territory, and at that point the hosting cost is the cost of the capability, not framework bloat.

    Which project type suits which framework

    I’d pick Astro for: marketing sites, content blogs, documentation sites, portfolio sites, any project where the content is known at build time, any client who doesn’t want to pay for a Node server indefinitely. Astro’s MDX support is excellent, its image optimisation pipeline is genuinely good, and the lack of JavaScript overhead means Core Web Vitals scores that make clients happy. If you’re working on something like a data-heavy editorial layout, the structured grid patterns popular in British editorial design render beautifully in Astro with zero client JS cost.

    I’d pick Next.js for: SaaS products, client dashboards, anything with real-time data, e-commerce with personalisation, applications that need API routes and server-side auth. If you’re building a fintech product that has to comply with FCA requirements and needs server-side session handling, Astro is not the right tool and nobody should pretend otherwise. The React Server Components model in Next.js 15 is genuinely well-suited to complex, data-driven interfaces. The kind of dense, multi-panel dashboards we’ve covered in depth before, for instance data dashboard design for UK government-style tools, need the application-layer features Next.js provides.

    The developer experience gap is closing, but not closed

    Astro 5 introduced server islands and a content layer API that makes it much more capable for hybrid content and dynamic situations. It’s not a full application framework yet, but it’s no longer purely a static tool either. The TypeScript experience in both frameworks is good; Astro’s type inference for content collections is particularly clean, which I find genuinely satisfying in a slightly nerdy way.

    Next.js’s App Router DX still has rough edges. The mental model for caching in Next.js 15 has been reworked (again), and while it’s better, it’s still the part of the framework most likely to produce a support ticket from a confused junior developer on your team. If you’re a solo freelancer who needs to hand a project off to a client’s in-house team of non-specialists, Astro’s conceptual simplicity is an underrated advantage.

    One practical note: if you’re doing any SEO work on behalf of clients, the framework choice affects how you structure pages and metadata. It’s worth checking your on-page implementation against a tool like searchenginetuning.co.uk once you’ve done a build, regardless of which framework you used, since routing differences between the two can create subtle metadata issues that only show up on inspection.

    The honest verdict for 2026

    The framing of “which is better” misses the point. Astro is better for content sites; Next.js is better for applications. The more useful question for UK freelancers is: what’s the default you reach for when a project brief is vague?

    My default is now Astro. Most of the briefs I get are for marketing sites, documentation, or content-led projects where the client doesn’t actually need server-side rendering. Starting with Astro keeps costs low, keeps the architecture simple, and keeps my clients’ Lighthouse scores high. When a project genuinely needs what Next.js offers, I switch without much drama, because the migration path is clear and the use case is obvious by that point.

    The GOV.UK Service Manual guidance on choosing technology has a principle I keep coming back to: choose the simplest thing that meets your needs. For most UK freelance web work in 2026, that’s Astro. For product teams building SaaS, it’s Next.js. Both frameworks are mature, both have futures, and neither is going to embarrass you in a client meeting.

  • AI-Assisted Code Reviews for Frontend Developers: What Tools Are Actually Worth Using in 2026

    AI-Assisted Code Reviews for Frontend Developers: What Tools Are Actually Worth Using in 2026

    Let me be upfront about something: I wanted to hate these tools. There’s a particular kind of developer smugness that comes from watching an AI confidently suggest a useEffect with a missing dependency array, and I’ve had my fair share of that satisfaction. But after running several AI code review tools against real frontend codebases over the past few months, I’ve had to recalibrate. They’re not useless. They’re not magic either. They’re something more complicated and, honestly, more interesting.

    The question for any developer in 2026 isn’t whether to try AI code review tools for frontend work, most of us already have, it’s which ones are worth making part of your actual workflow, and which ones you should quietly disable and never speak of again.

    Developer reviewing code on laptop — AI code review tools for frontend developers in 2026
    Photo by Daniil Komov on Pexels

    What we’re actually talking about when we say “AI code review”

    The category is a bit of a mess. Some tools sit inside your editor and flag issues as you type. Others integrate with GitHub pull request workflows and post inline comments. A few do both. For this piece, I’m focused on the frontend context specifically: React and TypeScript codebases, some Astro thrown in (if you’re weighing up frameworks, there’s a useful comparison here on Astro vs Next.js for UK developers), and a bit of vanilla CSS work to really stress-test the tools on something they tend to struggle with.

    The main players I tested were GitHub Copilot’s code review features (now substantially expanded beyond autocomplete), Cursor’s review and chat modes, CodeRabbit, and Sourcery. These represent the current spectrum: deeply IDE-integrated assistants versus dedicated PR review bots.

    GitHub Copilot: the one everyone already has

    Copilot’s review features are now genuinely decent for catching common React anti-patterns. In testing it against a mid-sized e-commerce frontend, it correctly identified several places where state was being lifted unnecessarily, and flagged a couple of async race conditions in data-fetching hooks that I’d missed during my own pass. That’s actually impressive.

    Where it falls apart is CSS and anything involving browser-specific behaviour. I fed it some complex grid layout code and it confidently suggested a fix using a property that, at time of writing, has incomplete support across Firefox. No caveat, no MDN link, just breezy confidence. For reference, MDN Web Docs remains the authoritative source here, and a tool that doesn’t defer to it when uncertain is a tool you need to double-check constantly. To its credit, Copilot’s JavaScript and TypeScript suggestions are noticeably stronger than its CSS ones. The pattern holds across tools, honestly: they were all trained on more JS than CSS.

    The GitHub PR integration is where Copilot earns its keep day-to-day. If you’re already on a GitHub-centric workflow, having inline review comments appear automatically on your PRs without any additional setup is a genuine time-saver for catching straightforward issues before a human reviewer has to bother.

    Cursor: the ambitious one

    Cursor is doing something more ambitious than Copilot and it shows, for better and worse. Its ability to understand your entire codebase context rather than just the file you’re editing is meaningfully useful. I tested it on a project where a custom hook was being misused across multiple components, and Cursor caught the pattern globally, not just in isolation. That’s the kind of review a senior developer would catch and a linter wouldn’t.

    The “with great power” problem applies here though. Cursor’s suggestions can be wordy. It’ll write you a three-paragraph explanation of why a piece of code might cause issues, when what you actually need is a one-line fix. I’ve found it works best when you treat it less like an automated reviewer and more like a very fast junior developer you’re pair-programming with: useful input that still needs your judgment applied. If you’re already doing TypeScript work as a designer-developer, Cursor’s contextual type inference suggestions are particularly strong.

    One thing I’d flag for UK developers specifically: Cursor’s pricing is in USD and some of the enterprise tier features assume team structures that are less common in smaller UK agencies or freelance setups. Worth reading the pricing tiers carefully before committing.

    CodeRabbit and Sourcery: the PR-first bots

    These two operate at the PR level rather than the editor level, and that distinction matters. CodeRabbit posts review comments directly in GitHub or GitLab PRs and, in my experience, it’s the most consistent of the lot at pure code quality observations. It doesn’t try to be your entire development environment; it just does one thing and does it reasonably well. Sourcery is similar but skews more towards refactoring suggestions, it loves pointing out where you could simplify a conditional or extract a function.

    Neither of them is particularly good at design-system awareness. If your frontend has a component library with specific patterns (say, a custom button that must always receive an aria-label when icon-only), they won’t know that unless you configure custom rules. This is a meaningful gap. Good frontend code isn’t just syntactically correct; it reflects the design system’s intent. If your icon system has its own rules and conventions (and it should, per everything I’ve written about icon systems for UK product teams), no off-the-shelf AI reviewer will enforce them out of the box.

    Where every tool struggles

    Three consistent failure modes came up across every tool I tested.

    First: accessibility. Every tool I tested missed at least some WCAG 2.2 issues that a human reviewer with accessibility knowledge would catch. They’re improving, but I wouldn’t rely on any of them as your accessibility review layer.

    Second: performance implications. None of them flagged a genuinely expensive re-render pattern I left in place as a test. They saw correct-looking code and approved it. The code worked; it just hammered the main thread on low-end devices.

    Third, and most dangerously: they are all confidently wrong sometimes. Not hedging, not flagging uncertainty. Just wrong, with the same tone as when they’re right. That’s the behaviour that will bite you if you let any of these tools become a rubber stamp.

    My actual recommendation

    If you’re a solo UK developer or working in a small agency, the combination that’s made the most practical difference for me is Copilot for in-editor suggestions plus CodeRabbit on PRs. You get the autocomplete and quick fixes at point of writing, and a second pass on the whole PR before merge. Neither replaces your own review or a colleague’s, but together they catch a reasonable chunk of the boring stuff so your human review time can focus on architecture and intent.

    Cursor is worth trying if you’re on a larger TypeScript project where codebase-wide context matters. Just don’t expect it to replace the kind of holistic design thinking that comes from actually understanding what your interface is supposed to do for a user.

    The tools are good enough to use. They’re not good enough to trust unattended. That distinction is doing a lot of work in 2026, and any developer who forgets it is going to spend a frustrating afternoon debugging something a very confident AI told them was fine.

    Frequently Asked Questions

    Are AI code review tools good enough to replace human code review in 2026?

    No, not reliably. They catch common syntax issues, anti-patterns, and some logic errors well, but they miss accessibility problems, performance implications, and design-system-specific rules. They work best as a first pass before a human reviewer looks at a PR.

    Is GitHub Copilot's code review feature worth paying for as a UK freelancer?

    If you’re already using Copilot for autocomplete, the review features are included and genuinely add value at no extra cost. For pure code review without the editor features, CodeRabbit’s free tier is worth trying first.

    How does Cursor differ from GitHub Copilot for frontend code review?

    Cursor reads your entire codebase for context, not just the current file, which makes it stronger at catching cross-file issues and misused patterns. Copilot’s PR integration is more lightweight and easier to fit into an existing GitHub workflow without changing your editor.

    Do AI code review tools understand TypeScript properly?

    They handle TypeScript meaningfully better than plain CSS or browser-compatibility edge cases. Type inference suggestions from Cursor in particular are quite strong. That said, complex generic types and conditional types can still confuse them, always verify anything non-trivial.

  • How to Build a Deployable Chrome Extension From Scratch in 2026: A UK Developer’s Walkthrough

    How to Build a Deployable Chrome Extension From Scratch in 2026: A UK Developer’s Walkthrough

    Chrome extensions are one of those rare bits of software where the gap between “idea” and “shipped product” is genuinely small. A weekend, a decent text editor, and some patience with the Chrome Web Store review queue is all it takes. But Manifest V3, Google’s current extension platform, has enough sharp edges that I’ve seen experienced developers waste a full day on avoidable mistakes. This walkthrough covers the complete build pipeline: folder structure, service workers, permissions, icon design, the popup UI, and the specifics of publishing through a UK developer account. Let’s get into it.

    Developer building a Chrome extension Manifest V3 project on a laptop at a desk
    Photo by Christina Morillo on Pexels

    What Manifest V3 actually changes

    If you last built a Chrome extension pre-2023, the mental model shift here is real. Manifest V3 replaced persistent background pages with service workers. That means your background script now has a lifecycle, it wakes up, does work, and gets terminated. You cannot store state in a global variable and expect it to persist across events. That tripped me up the first time.

    The other big change is the content security policy and the removal of webRequestBlocking for most developers. Ad blockers were the headline casualty, but for the overwhelming majority of extensions, productivity tools, tab managers, colour pickers, form helpers, none of that matters. What matters is that you use chrome.storage.local or chrome.storage.session instead of memory, and that you structure your service worker around event listeners rather than long-running logic.

    Setting up the folder structure

    Chrome extensions have a flat-ish structure. Here is what I use as a starting point:

    my-extension/
    ├── manifest.json
    ├── background.js
    ├── popup/
    │   ├── popup.html
    │   ├── popup.js
    │   └── popup.css
    ├── content/
    │   └── content.js
    └── icons/
        ├── icon16.png
        ├── icon32.png
        ├── icon48.png
        └── icon128.png

    The manifest.json is the entry point for everything. A minimal but real Manifest V3 file looks like this:

    {
      "manifest_version": 3,
      "name": "My Extension",
      "version": "1.0.0",
      "description": "Does something useful.",
      "permissions": ["storage", "activeTab", "scripting"],
      "background": {
        "service_worker": "background.js"
      },
      "action": {
        "default_popup": "popup/popup.html",
        "default_icon": {
          "16": "icons/icon16.png",
          "32": "icons/icon32.png",
          "48": "icons/icon48.png",
          "128": "icons/icon128.png"
        }
      },
      "icons": {
        "16": "icons/icon16.png",
        "48": "icons/icon48.png",
        "128": "icons/icon128.png"
      }
    }

    Request only the permissions you actually need. The Chrome Web Store reviewers check this, and users see permission prompts. activeTab is far less scary to users than tabs; use the narrower one if you can.

    Chrome extension Manifest V3 service worker code shown in a dark code editor
    Photo by Godfrey Atima on Pexels

    Writing the service worker

    Your background.js registers event listeners at the top level. That is it. Any logic that needs to run when something happens goes inside those listeners.

    chrome.runtime.onInstalled.addListener(() => {
      chrome.storage.local.set({ enabled: true });
    });
    
    chrome.action.onClicked.addListener(async (tab) => {
      const { enabled } = await chrome.storage.local.get('enabled');
      await chrome.storage.local.set({ enabled: !enabled });
    });

    If you need to communicate between the service worker and a content script, use chrome.runtime.sendMessage and chrome.runtime.onMessage. Keep those message payloads small and serialisable, no DOM nodes, no class instances.

    Building the popup UI

    The popup is just an HTML file. It renders in a small window when the user clicks the extension icon, with a max width of 800px and a max height of 600px in practice. I treat it like a tiny web app: semantic HTML, a small CSS file, and a JavaScript module that talks to storage and the background via messages.

    One thing worth knowing: the popup re-renders from scratch every time it opens. Read your state from chrome.storage in a DOMContentLoaded listener, not in a module-level variable. This is where the service-worker mental model bleeds into the popup too, nothing is persistent in memory. For anything more complex than a toggle, I’ve started reaching for a small reactive state pattern. Nothing fancy, just a single render(state) function that updates the DOM whenever storage changes. If you want full component structure, you can bundle a tiny framework like Preact into the popup directory, but for most tools that is overkill.

    On the design side: popup UIs are brutally small. Every pixel is load-bearing. I wrote recently about how most product teams get icon systems wrong, and extension popups are where that really bites, unclear icons in a 400px-wide interface with no room for labels are a usability disaster. Use 20px minimum touch targets, high-contrast text, and a single clear primary action per screen.

    Icon design for the Chrome Web Store

    You need four icon sizes: 16px, 32px, 48px, and 128px. The 128px version is what the Web Store displays on your listing page, so it needs to look polished at that size. The 16px version appears in the browser toolbar, meaning it must be readable as a silhouette, not as a detailed illustration.

    The practical approach I use: design at 128px, then manually redraw the 16px version as a simplified glyph. Do not just scale down the 128px, it will look terrible. Export as PNG with transparency. Avoid thin strokes under 2px at small sizes; they disappear entirely. If you want a deep dive on designing multi-resolution icon sets properly, the icon design guide on this blog is worth your time.

    Testing before submission

    Load your unpacked extension via chrome://extensions with Developer Mode toggled on. Reload it after every change to manifest.json; other file changes sometimes hot-reload, sometimes don’t. Use the service worker’s DevTools (there is an “inspect views” link on the extension card) to debug background script issues.

    Run through this checklist before you zip anything up: all declared permissions are actually used in code; icons exist at all four declared sizes; the popup opens without console errors; storage reads and writes work across a browser restart; and the extension does not break the pages it injects into. That last one sounds obvious, but content scripts can conflict with page CSS in ways that only appear on specific sites.

    Publishing to the Chrome Web Store as a UK developer

    You need a Google developer account, which costs a one-time fee of $5 USD (about £4 at current rates). Pay it once, and you can publish unlimited extensions. The payment goes through Google’s system, so your card needs to be set up for international transactions, most UK bank accounts handle this without any fuss.

    Create a ZIP of your extension directory (not a folder containing it, the manifest.json should be at the root of the ZIP). Upload it through the Chrome Web Store Developer Dashboard. You will need: a 440x280px promotional tile image, at least one 1280x800px screenshot, a short description (132 characters max), and a full description. The review process currently takes between a few hours and five business days for a new submission, Google does not publish a hard SLA.

    If your extension handles any user data, you must complete a privacy disclosure. UK developers should be aware that if you collect or transmit personal data, the ICO’s guidance on browser-based data collection applies to your extension just as it does to any other software product. Worth reading the ICO’s guidance for organisations before you hit publish if your extension touches anything beyond local storage.

    Version bumps are straightforward: update the version field in manifest.json, re-ZIP, and upload a new package in the dashboard. The review cycle for updates is usually faster than for initial submissions.

    Build pipeline considerations

    For a simple extension, you don’t need a bundler. Plain ES modules with "type": "module" work in content scripts and popups. But if you are importing npm packages, you need a bundler, Vite handles Chrome extension builds cleanly with the vite-plugin-web-extension plugin, which manages multi-entry-point builds and hot reloading during development.

    For teams shipping extensions alongside other web products, I’d think about how your extension fits into the broader development workflow. Good tooling compounds, the same efficiency gains that apply to web product pipelines apply here too. R2G.co.uk has an interesting take on how workflow efficiency translates to profitability that’s worth a read if you’re thinking about that side of things.

    For TypeScript users: you absolutely should be using it for anything beyond a toy extension. The Chrome extension types package (@types/chrome) is comprehensive and will save you from a class of runtime errors that are genuinely annoying to debug. If you are new to TypeScript in a design-adjacent context, the TypeScript introduction for UK freelancers on this blog is a good starting point before you wire it into a build pipeline.

    Ship something real. The Chrome extension ecosystem is less crowded than the App Store, the barrier is lower than you think, and a focused tool that solves one problem well consistently outperforms anything that tries to do everything. Pick your itch, build the fix, and get it listed.

    Frequently Asked Questions

    What is Manifest V3 and do I have to use it?

    Manifest V3 is the current version of Chrome’s extension platform, which replaced Manifest V2 with service workers instead of persistent background pages, among other changes. Google has phased out MV2 support, so yes, any new extension you build in 2026 must use Manifest V3, and existing MV2 extensions have been disabled in Chrome.

    How long does Chrome Web Store review take for a new extension?

    Review times vary from a few hours to around five business days for a first submission. Updates to existing extensions are typically reviewed faster. Google does not guarantee a specific turnaround, so factor in review time if you have a launch date in mind.

    How much does it cost to publish a Chrome extension in the UK?

    The one-time Google developer registration fee is $5 USD (roughly £4), paid through Google’s payment system. After that, there are no per-extension fees or annual costs, you can publish as many extensions as you like under the same account.

  • Astro vs Next.js in 2026: Which Framework Should UK Web Developers Actually Build With?

    Astro vs Next.js in 2026: Which Framework Should UK Web Developers Actually Build With?

    The framework debate has a new shape in 2026. A couple of years ago, the conversation was basically “are you using Next.js or are you wrong?” That’s no longer the case. Astro vs Next.js is now a genuine technical decision, and if you’re a UK freelancer or small agency picking a stack for a new project, getting it wrong costs you real time and money. I’ve spent a fair chunk of the last year shipping with both, and I have opinions.

    This isn’t a “both are great in their own way” fence-sit. I’ll tell you which one wins for which type of work, what the hosting implications look like on UK infrastructure, and why the choice matters more than most tutorials let on.

    Web developer comparing Astro vs Next.js framework code on dual monitors
    Photo by Alicia Christin Gerald on Pexels

    What each framework actually is

    Next.js, maintained by Vercel, is a React-based full-stack framework. It does server-side rendering, static generation, incremental static regeneration, API routes, middleware, edge functions, the lot. It’s been the default choice for serious React projects for years, and the ecosystem around it is enormous.

    Astro is something different. It’s an islands-architecture framework that ships zero JavaScript to the browser by default. You write components in whatever flavour you fancy (React, Svelte, Vue, or plain HTML) and Astro only hydrates the interactive bits. The result is pages that are genuinely fast in a way that feels almost unfair. For content-heavy sites, the Lighthouse scores are embarrassing compared to a typical Next.js build.

    These two frameworks are not really competing for the same use case. The problem is that a lot of developers reach for Next.js out of habit, even when Astro would be the smarter pick.

    Build performance: where Astro genuinely wins

    For a marketing site, a blog, a documentation hub, or a portfolio, Astro is faster to build with and faster to serve. Full stop. The islands architecture means your pages arrive in the browser as HTML with CSS, and only the components that need interactivity (a search bar, a contact form, a live pricing widget) get JavaScript injected. Everything else is static.

    I rebuilt a client’s agency site last autumn, previously on Next.js with a bloated component tree, and the move to Astro dropped Time to First Byte from around 800ms to under 120ms on a cold UK edge. The Core Web Vitals went green across the board without any heroics. If you’ve been wrestling with layout performance issues at the CSS level, the framework layer matters even more than you might think.

    Next.js, by contrast, carries React into the browser on every page by default. Even with server components (which are genuinely clever and have improved things substantially), you’re shipping more JavaScript than Astro would. For a SaaS dashboard, a social platform, or anything with heavy real-time state, that’s a reasonable trade. For a brochure site? It’s not.

    Hosting costs on UK providers

    This is where the decision gets practical and where UK developers often get stung. Next.js is heavily optimised for Vercel’s own infrastructure. That’s not a criticism, Vercel is a good product, but their free tier has limits that bite fast, and their Pro tier at roughly £17 per user per month adds up for a small agency with multiple projects running.

    Alternatives like Netlify or UK-adjacent providers such as Cloudflare Pages handle Next.js, but you lose some features (middleware running on Vercel’s edge, ISR at the granular level) or find workarounds necessary. The Vercel lock-in is real, even if the company insists otherwise.

    Astro sites, because they’re largely static output, deploy anywhere. Cloudflare Pages for free. An S3-compatible UK bucket behind a CDN. Your client’s existing cPanel host, if it comes to that. I’ve run Astro sites on Hetzner VPS instances in their UK datacentre (Falkenstein is technically Germany, but their London presence is growing) for under £5 per month including everything. Next.js apps with server-side requirements need a Node runtime, which means either a managed platform with associated costs or your own self-hosted VPS setup that you need to maintain.

    For UK freelancers billing smaller clients, the hosting cost difference can genuinely affect whether a project is profitable at the price point the client expects.

    Which projects actually suit each framework

    Astro wins for: marketing sites, landing pages, blogs, documentation, portfolios, news sites, e-commerce storefronts where the cart is a third-party embed, and any project where content is the primary product. If the page is mostly read, not interacted with, Astro should be your first choice.

    Next.js wins for: SaaS products with authenticated dashboards, apps with real-time data requirements, anything with complex server-side logic that needs to live close to the data layer, and projects where the team is already deep in the React ecosystem and moving away would cost more than it saves. It’s also the better pick when you’re building something that will grow into a full application, because its routing and API layer scale well.

    A pattern I see constantly in UK agency work: someone specs a Next.js build for a 12-page product site because the team knows React. The site ends up with a bundle size north of 800KB for pages that are basically text and images. Then they spend a sprint optimising what the framework choice created. Astro wouldn’t have done that.

    There’s also a middle path worth mentioning. Some teams are now running hybrid setups: Astro for the public-facing marketing and content pages, Next.js (or a lighter alternative like Remix) for the authenticated product area. The two can coexist on subdomains or subdirectories, and if you’re thoughtful about the split, you get the best performance characteristics of both without too much architectural overhead.

    The developer experience difference

    Next.js has the larger ecosystem, more Stack Overflow answers, and a bigger community in the UK dev scene. If you’re hiring or collaborating, finding someone familiar with Next.js is easier. The Astro community is growing fast, and the documentation is genuinely excellent, but it’s still smaller.

    Astro’s component model, where you can mix React, Svelte, and vanilla components in the same project, sounds chaotic but is surprisingly workable. For a freelancer who has built up a library of components across different frameworks, it’s actually liberating. I’ve pulled in a React data-viz component alongside a Svelte interactive widget and it just worked. That flexibility is part of why Astro suits project-based freelance work so well.

    One thing I’ve noticed: clients who care about their web presence (the ones spending money on cookie free display advertising UK services and similar performance-focused digital channels) are increasingly asking specific questions about page speed. Astro makes it much easier to hit those targets without a performance engineering sprint at the end of every project.

    For teams already building design systems or working across multiple products, the framework choice also interacts with your component architecture. If you’re maintaining icon systems or a full icon design system across multiple surfaces, understanding how your framework handles component hydration will affect how you structure those shared resources.

    My actual recommendation

    Default to Astro for anything content-first. The performance advantages are real, the hosting costs are lower, and the developer experience is genuinely good. You won’t spend three hours debugging why your bundle includes a library you imported once in a layout file.

    Use Next.js when the project genuinely needs it: persistent server-side state, complex auth flows, real-time features, or a codebase that’s going to grow into something an engineering team maintains long-term.

    The Astro documentation is worth an afternoon of your time even if you’re not planning to use it immediately. You’ll come away with a much clearer sense of what “islands architecture” actually means in practice, which makes the Next.js vs Astro decision far more intuitive when a new project lands on your desk.

    Both frameworks are mature, production-ready, and supported well enough that you won’t be stranded. The choice is about fit, not about quality. Pick the tool that matches the problem, not the one you’re most comfortable with.

    Frequently Asked Questions

    Is Astro faster than Next.js for production sites?

    For content-heavy, mostly static sites, yes, Astro ships zero JavaScript by default, which results in dramatically smaller payloads and faster load times. For highly interactive apps like SaaS dashboards, Next.js with server components is more competitive because it’s designed for that kind of complexity.

    Can I host an Astro site on cheap UK hosting?

    Yes, and that’s one of Astro’s main advantages. Because the output is static HTML, CSS, and minimal JS, you can host on Cloudflare Pages (free tier is generous), any S3-compatible storage, or a basic UK VPS for a few pounds per month. Next.js apps with server-side features need a Node runtime environment, which typically costs more.

    Should I use Astro or Next.js for a SaaS product?

    Next.js is the stronger choice for a full SaaS product with authenticated users, complex server logic, and real-time data requirements. That said, many SaaS teams use Astro for their public marketing site and Next.js only for the authenticated app area, which is a sensible split.

    Does Astro work with React components?

    Yes. Astro supports React, Svelte, Vue, Solid, and plain HTML components in the same project simultaneously. Only components that need client-side interactivity are hydrated; everything else renders as static HTML at build time.

  • Designing Offline-First Apps: Why UK Developers Should Be Building for Patchy Connectivity

    Designing Offline-First Apps: Why UK Developers Should Be Building for Patchy Connectivity

    Britain has a connectivity problem it keeps pretending it doesn’t have. You can be forty minutes outside Leeds, somewhere sensible and entirely on the map, and your mobile signal will flatline completely. According to Ofcom’s Connected Nations reports, significant portions of rural England, Scotland, and Wales still experience 4G not-spots or broadband speeds that make a dial-up modem look ambitious. If you’re building apps for a UK audience and you’re not thinking about offline-first app design UK, you’re quietly breaking the experience for a chunk of your users every single day.

    The good news: the web platform caught up. Service workers, IndexedDB, the Cache API, and background sync have matured considerably. Building an offline-capable application in 2026 is no longer a heroic engineering effort reserved for Google and large infrastructure teams. It’s a design and architecture decision you can make at the start of a project, and one that pays compounding dividends in user trust.

    Construction worker using a tablet on a UK building site, illustrating offline-first app design UK for field use

    What Does Offline-First Actually Mean?

    Offline-first doesn’t mean your app works exclusively without a connection. It means the app treats network availability as an enhancement rather than a prerequisite. The mental model shifts: instead of “assume connected, handle errors when not”, you build for “assume nothing, sync when possible”. That inversion changes almost everything about your data flow, your UI states, and your error handling strategy.

    Compare this to the more common “offline-tolerant” approach, where developers bolt on a friendly error screen and call it done. That’s not offline-first. That’s just dressed-up failure. Proper offline-first means a user in a Snowdonia valley or on a Highland train can read their data, create new records, and edit existing ones. When connectivity returns, the app catches up. The user never stares at a spinner waiting for permission to use their own software.

    Service Workers: The Engine Room of Offline Capability

    Service workers are background scripts that sit between your app and the network, intercepting requests and deciding what to do with them. They’re the backbone of any serious offline-first architecture. A service worker can cache your app shell on first load, serve stale content when the network is unavailable, and queue outgoing requests to replay once connectivity resumes.

    The setup is conceptually straightforward. Register your service worker in your main JavaScript entry point, then implement a fetch event listener to define your caching strategy. For static assets (your JS bundles, CSS, fonts), a cache-first strategy is sensible. For API calls, a stale-while-revalidate approach gives you speed plus freshness: serve what’s cached immediately, then fetch and update in the background. For write operations, background sync via the SyncManager API queues failed requests and retries them automatically when the connection recovers.

    Libraries like Workbox (from Google, but widely used in UK product teams) abstract much of this boilerplate. You define your caching strategies declaratively, and Workbox handles the plumbing. For most teams, this is the pragmatic starting point rather than hand-rolling everything.

    Local Storage Strategies: IndexedDB Is Where You Actually Live

    The localStorage API gets reached for instinctively, but it’s synchronous, limited to roughly 5MB, and stores only strings. For any serious offline data layer, IndexedDB is the right tool. It’s asynchronous, stores structured data including blobs, and has no practical size ceiling for most use cases (browsers impose soft limits, but you’re typically looking at hundreds of megabytes).

    Developer inspecting service worker and IndexedDB data in browser devtools as part of offline-first app design UK

    Working with raw IndexedDB is famously verbose, which is why wrapper libraries exist. Dexie.js is my personal favourite for this: clean promise-based API, excellent TypeScript support, and an active community. You define your schema as a simple object, run version migrations, and query with a syntax that looks almost like SQL’s friendlier sibling. For React-based projects, RxDB adds reactive querying on top of IndexedDB, which pairs nicely with component-driven UIs.

    One design decision worth spending time on: what do you actually persist? You don’t want to naively dump your entire server state into the client. Think about the user’s current session, their most recently accessed records, and anything they’d need to do their core job. A field-based app, for instance, might cache the last thirty jobs rather than the full historical archive. Scope your local database to what’s genuinely useful offline, and you’ll save yourself a world of pain later.

    This is exactly the kind of consideration that matters for industries operating in physically demanding or remote environments. Construction and building services firms, for example, need site workers to log inspection data, capture photos, and update compliance records even in basements and rural plots with no signal. Asbestos Compliance Solutions Ltd, a specialist asbestos services provider based in Mansfield, Nottinghamshire, is precisely the type of operation where offline-first app design becomes business-critical rather than a nice-to-have. A surveyor working on a construction site or inside a building earmarked for demolition needs an app that saves their asbestos survey data locally and syncs it to the back end once they’re back in signal. You can find more about their specialist services at https://asbestoscompliancesolutions.co.uk/, the point being that the field-to-office data flow is one of the strongest real-world arguments for building offline-first.

    Sync Conflict UI: The Design Problem Nobody Wants to Talk About

    Here’s where offline-first gets genuinely hard, and where most tutorials quietly stop. If two users edit the same record while both are offline, and then both sync at the same time, you have a conflict. Last-write-wins is the laziest resolution strategy. It works sometimes. It silently discards data the rest of the time.

    A more robust approach is a CRDT (Conflict-free Replicated Data Type) model, where data structures are designed to merge without conflicts by their mathematical nature. Libraries like Automerge and Yjs implement CRDTs in JavaScript and are increasingly viable for product-scale applications. For simpler scenarios, you can track vector clocks or timestamps and surface conflicts explicitly to the user.

    That last option is a UI design challenge as much as an engineering one. When a conflict exists, your interface needs to show the user what happened in plain language, present both versions of the record, and let them choose or merge. This is not glamorous design work. It won’t win you a Webby Award. But it’s the difference between an app that’s trustworthy in the field and one that occasionally loses data in ways users can never quite prove.

    For building and construction-adjacent tools, where compliance records and specialist services data carry regulatory weight, a sync conflict that silently overwrites an asbestos survey result could have consequences well beyond a frustrated user experience. The design of conflict resolution UI should be proportional to the stakes of the data.

    Offline UX Signals: Telling Users What’s Actually Happening

    Beyond the technical architecture, offline-first has a UX communication layer that often gets undercooked. Users need to know when they’re offline, when their actions have been queued rather than confirmed, and when the sync has completed. The navigator.onLine API gives you a basic boolean, though it’s worth knowing this can give false positives (a device connected to a router with no internet access will report online). Listening to the online and offline window events is more reliable in practice.

    Visually, a persistent but unobtrusive status indicator works well: something in the interface chrome that shows “Saving locally” or “Syncing” without interrupting the user’s flow. Avoid modal alerts for this. Nobody wants a dialogue box telling them they’re in a tunnel. The app should handle it quietly and surface the status when the user actually looks for it.

    Pending action queues deserve visibility too. If a user has submitted three records while offline, a small badge or count somewhere accessible gives them confidence their work hasn’t vanished. When sync completes, a brief toast notification closes the loop. These are small interactions, but they’re the entire psychological foundation of trusting an offline-first system.

    Progressive Web Apps and the UK Distribution Opportunity

    One last thought: PWAs (Progressive Web Apps) are the natural delivery vehicle for offline-first experiences on the web. They install to the home screen, run in a standalone window, and unlock the service worker capabilities described above. For UK developers building field tools, B2B utilities, or anything serving users in connectivity-challenged environments, a PWA sidesteps app store friction entirely.

    Asbestos Compliance Solutions Ltd and similar specialist services businesses in the building and construction sector represent a whole category of professional tools that would benefit enormously from this model. A well-built PWA for asbestos survey management, distributed directly via a URL, updated silently in the background, and fully functional on a construction site with no signal, is a genuinely better product than a native app requiring Play Store or App Store submission cycles.

    The technical foundations are solid. Service workers are supported across all modern browsers. IndexedDB is ubiquitous. Background sync has broad coverage. The remaining barrier is mostly cultural: the assumption that “proper” apps need a server call for every interaction. Rural Britain, and the millions of professionals who work in basements, tunnels, and remote sites, would politely like you to rethink that assumption.

    Frequently Asked Questions

    What is offline-first app design and how is it different from just caching?

    Offline-first app design means building an application where local data access is the default behaviour, and network requests are an enhancement rather than a requirement. Basic caching typically just stores static assets; offline-first goes further by persisting application data locally, queuing write operations, and syncing changes when connectivity returns.

    Which UK areas have the worst mobile and broadband connectivity for app users?

    According to Ofcom’s Connected Nations data, large parts of rural Scotland, Wales, and Northern England have persistent 4G not-spots and below-average broadband speeds. Areas including the Scottish Highlands, mid-Wales, and parts of Yorkshire and Cumbria regularly appear in coverage gap reports, making offline-first design especially relevant for apps targeting users in these regions.

    How do service workers enable offline functionality in web apps?

    Service workers are background scripts that intercept network requests made by your application. They can serve cached responses when the network is unavailable, implement strategies like cache-first or stale-while-revalidate for different resource types, and queue failed write requests using the Background Sync API to replay them once connectivity is restored.