Category: Tech Stuff

  • 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.

  • How to Self-Host Your Design Stack on a UK VPS: Penpot, Gitea, and Plausible Without the SaaS Bill

    How to Self-Host Your Design Stack on a UK VPS: Penpot, Gitea, and Plausible Without the SaaS Bill

    Figma’s pricing has crept up year on year. GitHub’s free tier comes with caveats. Google Analytics 4 remains a GDPR headache that most UK studios are quietly sweating over. If you’ve been running a small design or development practice and watching your SaaS subscriptions quietly devour your margin, there’s a genuinely viable escape hatch: self-hosting your core stack on a UK-based virtual private server. This guide walks through how to self host design tools on a UK VPS, specifically Penpot (your Figma replacement), Gitea (your GitHub replacement), and Plausible (your GA4 replacement), with enough technical detail to actually get you moving.

    The total monthly outlay for a mid-spec VPS from a UK provider like Mythic Beasts, Memset, or Hetzner’s UK edge nodes typically runs between £8 and £25 depending on RAM. Compare that to Figma’s Organisation tier at roughly £40 per editor per month, GitHub Team at around £3.50 per user, and GA4’s 360 tier when you outgrow the free limits. The maths tilts hard in favour of self-hosting once you have more than two or three people on a team.

    Developer setting up self host design tools on UK VPS with Penpot in a London office

    Choosing Your UK VPS Provider

    Where your server physically lives matters for two reasons: latency for your UK team, and data residency under UK GDPR. The ICO’s guidance is clear that personal data should remain in jurisdictions with adequate protections, and keeping it on UK soil is the simplest way to stay compliant without writing a lengthy transfer impact assessment.

    For this walkthrough, assume a VPS with 4GB RAM, 2 vCPUs, and 80GB SSD storage. That comfortably runs all three services simultaneously. You’ll want Ubuntu 24.04 LTS as your base OS, Docker and Docker Compose installed, and a domain with DNS pointing at your server’s IP. Nginx will act as a reverse proxy in front of everything, with Let’s Encrypt handling SSL via Certbot.

    Once your VPS is provisioned, update the system and install Docker:

    sudo apt update && sudo apt upgrade -y
sudo apt install -y docker.io docker-compose-v2 nginx certbot python3-certbot-nginx
sudo systemctl enable docker
sudo usermod -aG docker $USER

    Setting Up Penpot on Your VPS

    Penpot is the open-source design and prototyping tool from the Spanish studio Kaleidos. It’s browser-based, handles vector work and component libraries, and supports real-time collaboration. It won’t do everything Figma does, but for most UI design workflows it’s genuinely solid. The ICO would be pleased: no data leaving your server.

    Penpot ships an official Docker Compose configuration. Grab it:

    mkdir ~/penpot && cd ~/penpot
wget https://raw.githubusercontent.com/penpot/penpot/main/docker/images/docker-compose.yaml
wget https://raw.githubusercontent.com/penpot/penpot/main/docker/images/config.env

    Open config.env and set the PENPOT_PUBLIC_URI to your subdomain, something like https://design.yourdomain.co.uk. Also set PENPOT_FLAGS to include enable-registration initially so you can create your admin account, then flip it to disable-registration afterwards. Run it:

    docker compose -f docker-compose.yaml up -d

    Penpot binds to port 3449 by default. Your Nginx config for this subdomain should proxy to that port, with SSL terminated at the Nginx layer. Once Certbot has issued your certificate and you’ve reloaded Nginx, your design.yourdomain.co.uk should show the Penpot login screen. Create your admin account, invite your team, and you’re running a fully functional self host design tools UK VPS setup in under an hour.

    Deploying Gitea as Your Private Git Host

    Gitea is a lightweight, self-hosted Git service written in Go. It’s fast, it uses minimal resources, and it has a web interface that feels close enough to GitHub that your team won’t mutiny. It handles repositories, issues, pull requests, webhooks, and CI integration with Gitea Actions.

    Create a compose file at ~/gitea/docker-compose.yml:

    version: "3"
services:
  gitea:
    image: gitea/gitea:latest
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=sqlite3
    volumes:
      - ./data:/data
    ports:
      - "3000:3000"
      - "222:22"
    restart: always

    SQLite works fine for teams under about 20 users. If you’re running something bigger, swap to PostgreSQL. The SSH port mapping (222:22) means your team will push with git remote add origin ssh://[email protected]:222/yourorg/repo.git. Nginx proxies HTTP traffic on port 3000 under its own subdomain. Run docker compose up -d, navigate to the web installer at your subdomain, and configure your instance. Disable public registration immediately.

    Installing Plausible Analytics

    Plausible is the privacy-first, GDPR-compliant analytics tool that’s been winning converts from Google Analytics for a few years now. The self-hosted version is functionally identical to the cloud product. For UK studios with clients asking about cookie banners and data processing agreements, hosting Plausible on your own UK VPS means the conversation becomes dramatically simpler: the analytics data never leaves your infrastructure.

    According to the ICO’s UK GDPR guidance, analytics tools that collect personal data without consent require explicit opt-in. Plausible’s cookieless approach sidesteps most of this entirely, but self-hosting adds another layer of confidence for clients.

    Clone the Plausible hosting repo:

    git clone https://github.com/plausible/community-edition ~/plausible
cd ~/plausible
cp plausible-conf.env.example plausible-conf.env

    Edit plausible-conf.env. Set BASE_URL to your analytics subdomain, generate a SECRET_KEY_BASE using openssl rand -base64 48, and configure your SMTP details for email verification. Then:

    docker compose up -d

    Plausible runs on port 8000. Nginx proxy config follows the same pattern as the others. Once it’s live, embed the lightweight tracking script (<script defer data-domain="yourclient.co.uk" src="https://analytics.yourdomain.co.uk/js/script.js"></script>) in your clients’ sites and you’re collecting privacy-respecting, UK-hosted analytics.

    Nginx Reverse Proxy Config Pattern

    Each service follows the same Nginx block structure. Here’s the template:

    server {
    listen 443 ssl;
    server_name service.yourdomain.co.uk;

    ssl_certificate /etc/letsencrypt/live/service.yourdomain.co.uk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/service.yourdomain.co.uk/privkey.pem;

    location / {
        proxy_pass http://localhost:PORT;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name service.yourdomain.co.uk;
    return 301 https://$host$request_uri;
}

    Replace PORT with 3449 for Penpot, 3000 for Gitea, and 8000 for Plausible. Run sudo certbot --nginx -d service.yourdomain.co.uk for each subdomain. Certbot will modify the block automatically to include the certificate paths. Reload Nginx after each one.

    Backups and Maintenance

    Self-hosting means you own the failure. Set up a daily cron job to dump Docker volumes to a compressed archive and rsync it off-server to a separate UK storage bucket or a second VPS. Mythic Beasts and Bytemark (now part of IONOS UK) both offer object storage with UK data residency. A backup that lives on the same physical host as your data is not a backup.

    Docker image updates are the other recurring task. A monthly docker compose pull && docker compose up -d across all three services keeps you on current releases without much fuss. Subscribe to the Penpot, Gitea, and Plausible release channels on their respective Git hosts so you catch security patches promptly.

    The total monthly compute bill for this three-service stack on a decent UK VPS sits somewhere around £12 to £20. For a small studio of four or five people, you’re almost certainly saving north of £100 per month compared to the equivalent SaaS tiers, and you’ve got full data sovereignty to boot. The setup overhead is a few hours, and the maintenance overhead is genuinely low once it’s running.

  • Figma vs Framer in 2026: Which Design Tool Wins for Modern Web Projects?

    Figma vs Framer in 2026: Which Design Tool Wins for Modern Web Projects?

    Right, let’s settle this properly. The Figma vs Framer 2026 debate has been simmering in design Slack channels, Twitter threads, and conference hallways for a while now, and I think it’s finally reached the point where a proper, no-nonsense comparison is overdue. Both tools have evolved dramatically. Both have serious AI features. Both claim to be the one tool to rule them all. Spoiler: neither is perfect, but the right choice depends enormously on how you work and what you’re actually building.

    I’ve spent a good chunk of time in both environments this year, switching between them on different projects, and the experience is genuinely illuminating. So let’s get into it.

    Designer comparing Figma vs Framer 2026 on dual monitors in a modern UK design studio
    Designer comparing Figma vs Framer 2026 on dual monitors in a modern UK design studio

    The Core Difference: Design Tool vs Website Builder

    Here’s the thing most comparison articles gloss over. Figma and Framer are not really the same type of tool wearing different hats. Figma is, at its core, a collaborative design and prototyping environment. Framer is increasingly a website builder with a very design-forward interface. That distinction matters enormously when you’re deciding which one belongs in your workflow.

    Figma excels at being the single source of truth for a design team. Design systems, component libraries, variables, multi-file branching, granular permissions, and a dev mode that engineers actually want to open. It’s built for teams. It’s built for handoff. It’s built for scale.

    Framer, meanwhile, has leant hard into the idea that your design should be the product. Build in Framer, publish from Framer, and the prototype IS the website. There’s a real seductiveness to that pitch. No handoff. No translation loss. No developer going “I can’t replicate that blur” at 11pm on a Monday.

    Prototyping: Where Each Tool Actually Shines

    Figma’s prototyping has improved substantially with the introduction of proper variables and conditional logic. You can now build flows that actually respond to user input, remember state between screens, and simulate real app behaviour without touching a line of code. For UX researchers doing usability testing, this is a genuine step change. It’s still not quite as fluid as some dedicated prototyping tools, but it’s good enough for the vast majority of product design workflows.

    Framer’s prototyping feels different because it is different. When you add an animation in Framer, you’re writing (or generating) actual CSS and JavaScript under the hood. Scroll animations, parallax effects, hover states with spring physics, these all feel eerily real because they basically are real. If your job involves building landing pages or marketing sites that need to impress, Framer’s motion capabilities are genuinely ahead. The gap closes when you look at complex app flows with lots of conditional logic, where Figma’s variable system is more structured and easier to audit.

    AI Features in 2026: Clever Tricks or Actual Workflow Shifts?

    Both tools have gone fairly hard on AI this year, and it’s worth being honest about what’s useful versus what’s just a feature checkbox.

    Figma’s AI additions, including the generate UI from text, auto-layout suggestions, and the renamed Make Designs feature, are genuinely handy for rough exploration. The AI rename layers function alone has saved me more time than I care to admit. The AI feels like a set of useful accelerators woven into an existing workflow rather than a fundamental reinvention of how the tool works.

    Close-up of UI prototyping workflow relevant to Figma vs Framer 2026 comparison
    Close-up of UI prototyping workflow relevant to Figma vs Framer 2026 comparison

    Framer’s AI is more theatrical, but in a good way. The ability to generate entire responsive sections from a text prompt and have them publish-ready is remarkable. It’s not always right, and you’ll spend time cleaning up generated components, but for solo designers or small studios spinning up quick client prototypes, it’s a legitimate time-saver. The AI CMS features, where you can auto-populate content blocks from structured data prompts, are also genuinely novel.

    The honest take: Figma’s AI helps you design faster. Framer’s AI helps you ship faster. Those are different problems.

    Developer Handoff: The Bit That Actually Determines If Anyone Loves You

    This is where the tools diverge most sharply, and where your choice might be made for you by the engineering team rather than by you.

    Figma’s Dev Mode is properly excellent now. Developers get computed CSS, annotated specs, asset exports, variable references, and the ability to compare designs against live implementation. Major UK agencies and in-house product teams at companies like Monzo, Deliveroo, and Babylon Health have been running Figma-centred design systems precisely because the handoff story is robust and repeatable at scale. For anyone working inside a product team where designers and engineers collaborate daily, Figma’s handoff pipeline is currently the most mature in the industry.

    Framer’s answer to handoff is, essentially, to make it irrelevant. If you’re publishing from Framer, there’s nothing to hand off. That works brilliantly when a designer has full ownership of the front end, which is more common in agency and freelance contexts than in product teams. It breaks down when an engineer needs to integrate your work into a React or Next.js codebase, or when you’re working on a design system shared across multiple products. Framer’s generated code is… acceptable, but it’s not the clean, maintainable output an engineering team wants to build on.

    Pricing and the Real Cost of Commitment

    Figma’s pricing in 2026 sits at around £12 per editor per month for the Professional plan, with the Organisation plan climbing significantly higher. Since Adobe’s acquisition attempt fell through (still a wild saga), Figma has remained independent and has actually been fairly reasonable about pricing relative to what it delivers. For teams already paying for it, there’s rarely a compelling reason to leave.

    Framer’s free tier is generous for personal projects, with paid plans starting around £14 per month per site on the Mini plan. For agencies publishing multiple client sites, the costs can stack up, though the per-site model does mean costs stay somewhat predictable. You can read more about how web tools are classified for business use over at HMRC’s guidance on allowable business expenses, which is relevant if you’re a UK freelancer writing these costs off.

    Which Tool Should You Actually Use?

    Here’s my genuinely considered take after living in both tools. The Figma vs Framer 2026 debate doesn’t have a universal winner, but it does have contextual winners.

    Use Figma if you’re in a product team, working with engineers regularly, managing a design system, or your organisation has more than five designers who need to collaborate. The tooling, the handoff, the design system infrastructure, it’s simply more mature for that context.

    Use Framer if you’re a solo designer, part of a small agency, building marketing sites or landing pages, or you want the ability to go from concept to published URL without involving a developer. The motion capabilities alone are worth it for that use case.

    And honestly? The most interesting designers I know are using both. Figma for product design and systems work. Framer for pitching, prototyping high-fidelity motion concepts, and spinning up client-facing demos that actually move. That’s not a cop-out answer, it’s just the reality of a field where the tools have genuinely diverged into different niches while appearing to compete in the same space.

    The Figma vs Framer 2026 conversation is ultimately a question about where your output lives. If it lives in a codebase, use Figma. If it lives on a URL, seriously consider Framer.

    Frequently Asked Questions

    Is Framer better than Figma for building websites in 2026?

    Framer is arguably better if you want to go directly from design to a published website without developer involvement, particularly for marketing sites and landing pages. Figma remains superior for complex product design, team collaboration, and developer handoff into existing codebases.

    Can Figma and Framer be used together in the same workflow?

    Yes, and many professional designers do exactly this. A common approach is to use Figma for design systems, component libraries, and developer handoff, then use Framer for high-fidelity motion prototypes and client-facing demos.

    Which tool has better AI features in 2026, Figma or Framer?

    Both have meaningful AI features, but they serve different purposes. Figma’s AI accelerates the design process with things like auto-renaming layers and generating UI components. Framer’s AI goes further by generating publish-ready responsive sections and populating CMS content, making it more useful for rapid deployment.

    How does Framer handle developer handoff compared to Figma?

    Framer largely sidesteps handoff by making the design the deployable product. Figma has a dedicated Dev Mode that outputs computed CSS, annotations, and asset specs for engineers. For teams working in existing codebases, Figma’s handoff is considerably more practical.

    Is Figma still free to use in 2026?

    Figma offers a free starter tier with limited features and file history. Professional plans start at approximately £12 per editor per month. Framer also has a free tier, with paid plans starting around £14 per month per published site.

  • Why Your Website’s Core Web Vitals Are Still Broken in 2026 (And How to Actually Fix Them)

    Why Your Website’s Core Web Vitals Are Still Broken in 2026 (And How to Actually Fix Them)

    Right. You’ve run PageSpeed Insights, stared at a wall of amber and red scores, and muttered something unprintable at your screen. Welcome to the club. Despite Google making Core Web Vitals a ranking signal years ago, a staggering proportion of UK small business and e-commerce sites are still failing at least one metric. According to the ONS data on UK internet industry, the number of UK businesses trading online continues to grow, which makes it all the more baffling that so many of them are haemorrhaging rankings because of fixable performance issues. This is your technically grounded guide to the core web vitals fix your UK website actually needs in 2026.

    Developer analysing core web vitals fix for a UK website in 2026 on multiple monitors
    Developer analysing core web vitals fix for a UK website in 2026 on multiple monitors

    What Are Core Web Vitals and Why Do They Still Matter in 2026?

    Three metrics. That’s all Google is officially measuring under Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). INP replaced First Input Delay in early 2024 and it’s been quietly brutalising sites ever since. These aren’t abstract benchmarks invented by committee; they map directly to how a real human being experiences loading a page on a 4G connection on the Tube.

    LCP measures how fast your biggest visible element renders. INP measures how snappy your site feels when someone taps, clicks, or types. CLS measures whether your page jumps around like a nervous ferret while it loads. Fail any of them and you’re not just annoying your users; you’re handing a quiet ranking penalty to competitors who bothered to sort theirs out.

    Why UK SME and E-Commerce Sites Fail More Than They Should

    I’ve looked at a lot of UK business sites over the years and the failure patterns are almost always the same. It’s rarely one catastrophic problem. It’s death by a thousand cuts: a bloated WooCommerce theme, render-blocking Google Tag Manager scripts, hero images served without modern compression, third-party chat widgets loading synchronously. Each one adds a few hundred milliseconds. Collectively they torpedo your LCP.

    UK e-commerce sites in particular tend to inherit technical debt from theme marketplaces. Themes built on Bootstrap 4, autoloading twelve Google Fonts variants, carousels powered by jQuery plugins from 2019. The stacking effect is brutal. A site that looks fine on a developer’s M3 MacBook Pro over fibre will absolutely fall apart for someone browsing on an iPhone SE in a post office queue in Wolverhampton.

    Fixing LCP: The Largest Contentful Paint Problem

    Your LCP target is under 2.5 seconds. Most failing UK sites are sitting between 3.5 and 6 seconds. The biggest culprits are almost always images and render-blocking resources.

    Start with your hero image. If it’s a JPEG or PNG being loaded via a CSS background, that’s two problems at once. Switch to WebP or AVIF (AVIF compression is genuinely remarkable at this point), serve it as an <img> element with proper dimensions declared, and add fetchpriority="high" to the tag. That single attribute tells the browser this image is critical and to fetch it immediately rather than queuing it behind other resources.

    <img
  src="hero.avif"
  width="1200"
  height="630"
  fetchpriority="high"
  alt="Your descriptive alt text"
>

    Next: preload your LCP image in the <head>. This is still criminally underused on UK sites.

    <link rel="preload" as="image" href="hero.avif" fetchpriority="high">

    Finally, audit your render-blocking scripts. Google Tag Manager firing synchronously in the <head> is an LCP killer. Move third-party scripts to load with defer or async wherever possible. GTM itself should load asynchronously; if it isn’t, something has gone wrong with your implementation.

    Chrome DevTools performance panel showing long tasks relevant to core web vitals fix
    Chrome DevTools performance panel showing long tasks relevant to core web vitals fix

    Fixing INP: Interaction to Next Paint Is the Hard One

    INP is the metric that’s caught the most sites off-guard since it replaced FID. The threshold for a good score is under 200 milliseconds. Poor is anything over 500ms. The nuance here is that INP measures the worst interaction across an entire page session, not just the first one. That means a sluggish dropdown menu or a heavy on-click handler buried in a product filter can tank your entire score.

    The main culprit for high INP on UK e-commerce sites is long tasks on the main thread. JavaScript that runs for more than 50ms without yielding blocks the browser from responding to user input. Here’s the pattern to break it up:

    // Instead of one long synchronous function:
function heavyTask() {
  // ...200ms of work...
}

// Yield to the browser between chunks:
async function yieldingTask() {
  for (const chunk of dataChunks) {
    processChunk(chunk);
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

    The scheduler.postTask() API is worth exploring if you’re on a modern stack; it gives you fine-grained control over task priority. For WordPress and WooCommerce sites, the quickest win is usually auditing which plugins are registering event listeners on every page. WooCommerce cart fragments, live chat scripts, cookie consent managers; each one adds JavaScript weight that the browser has to process before it can respond to the next click.

    Use Chrome DevTools’ Performance panel (or the slightly more accessible Web Vitals extension) to identify which interactions are generating the longest tasks. Look for the red triangles. Then work backwards to the script responsible.

    Fixing CLS: Stop Your Page Jumping Around

    Cumulative Layout Shift should be under 0.1. It’s the most visually obvious failure and often the easiest to fix, yet plenty of UK sites are still shipping CLS scores of 0.3 or worse.

    The classic cause: images without declared dimensions. When the browser doesn’t know how tall an image is before it loads, it reserves no space. Then the image appears and shunts everything down the page. The fix is a single line of CSS that’s been good practice for years but somehow still gets skipped:

    img, video {
  aspect-ratio: attr(width) / attr(height);
  height: auto;
  width: 100%;
}

    Always declare explicit width and height attributes on your <img> tags too. The browser uses these to calculate space before the image loads.

    Web fonts are the other sneaky CLS source. When your custom font loads and swaps in, text reflows and shifts the layout. The fix is font-display: optional for non-critical fonts, or font-display: swap combined with a closely matched system font fallback using the size-adjust CSS descriptor. The font matching tools from Malte Ubl’s Fontaine project are genuinely useful here for generating fallback metrics automatically.

    Ad slots, banners, and dynamically injected content are the third category. Reserve space for them explicitly with CSS. A banner that loads after the DOM has painted and pushes your content down by 60 pixels will absolutely destroy your CLS score.

    Measuring the Right Way: Real User Data vs Lab Data

    PageSpeed Insights shows you two sets of data: lab data (simulated, consistent, useful for debugging) and field data from the Chrome User Experience Report (CrUX). Google’s ranking decisions are based on CrUX field data, not lab scores. A site can score 95 in PageSpeed lab conditions and still fail Core Web Vitals in the field if real users on real networks and devices are having a different experience.

    If your site doesn’t yet have enough traffic to appear in CrUX, you’re assessed at the origin level or not at all. But you should still optimise; you’re building the performance foundation for when the data does accumulate. Use the Google Search Console Core Web Vitals report to see page-group level field data for your actual UK users.

    The bottom line for a core web vitals fix on a UK website in 2026 is this: it’s almost never one thing. It’s the compound effect of images, scripts, fonts, and layout choices that were each fine in isolation but terrible together. Audit methodically, fix the highest-impact items first (LCP image delivery and render-blocking scripts will move the needle fastest), and measure with field data, not just lab scores. Your rankings, and your users, will thank you for it.

    Frequently Asked Questions

    What is a good Core Web Vitals score in 2026?

    Google defines ‘good’ as LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. All three thresholds need to be met at the 75th percentile of real user page loads to pass. Hitting two out of three still counts as a partial failure.

    How do I check my Core Web Vitals for free?

    Google Search Console gives you real-user field data grouped by page type, which is the most valuable report for UK site owners. PageSpeed Insights (pagespeed.web.dev) gives you both lab and field data for individual URLs. The Chrome Web Vitals browser extension lets you measure in real time as you browse.

    Does fixing Core Web Vitals actually improve Google rankings?

    Yes, though it’s one signal among many. Google uses Core Web Vitals as a tiebreaker when content quality is broadly similar between competing pages. For competitive UK e-commerce and local search queries, the difference between a passing and failing score can visibly shift rankings. More importantly, faster sites convert better.

    Why is my WordPress site failing INP?

    WordPress and WooCommerce sites typically accumulate JavaScript from multiple plugins all registering event listeners and running tasks on the main thread simultaneously. Cart fragment scripts, live chat widgets, cookie consent managers, and page builder scripts are common culprits. Audit your loaded scripts with Chrome DevTools and remove or defer anything not critical to the initial interaction.

    How long does it take to fix Core Web Vitals?

    Technical fixes can be implemented in a day or two for a developer who knows what they’re looking for. However, Google’s CrUX field data updates on a rolling 28-day window, so you won’t see improvements reflected in Search Console immediately. Expect three to four weeks before field data catches up to your fixes.

  • The Best Graphic Design Software in 2026: Figma vs Adobe vs the New Challengers

    The Best Graphic Design Software in 2026: Figma vs Adobe vs the New Challengers

    The graphic design software landscape has shifted more in the past two years than it did in the previous decade. That’s not hyperbole. Between Adobe’s aggressive AI push, Figma surviving its blocked acquisition and coming back swingier than ever, and a wave of genuinely capable AI-native tools muscling into the market, designers in 2026 have more choice than at any point in the industry’s history. Which is brilliant, slightly overwhelming, and occasionally maddening depending on which way you’re leaning on any given Tuesday.

    This is a proper rundown of the best graphic design software 2026 has on offer, from the incumbents defending their territory to the scrappy newcomers that are actually worth your time. Whether you’re a freelancer watching your pennies or an agency looking to standardise a team toolkit, there’s something here for you.

    Designer working with best graphic design software 2026 on a large studio monitor setup
    Designer working with best graphic design software 2026 on a large studio monitor setup

    Figma: Still the Collaborative Powerhouse

    Figma remains the go-to for UI and product design, and with good reason. The browser-based model is just sensible, your team is always on the same version, branching keeps workflows clean, and the component system is genuinely excellent once you’ve invested the time to build it properly. In 2026, Figma has doubled down on its AI features, with smart layout suggestions, auto-generated component variants, and a reasonably impressive natural language design prompt that lets you sketch ideas before committing pixels.

    Pricing sits at around £12 per editor per month on the Professional plan, with organisations paying significantly more for enterprise compliance features. Free tier is still generous, which matters a lot for indie designers just building their process. The one genuine criticism? Figma is still not great for print work. If your output ever ends up on a physical page, Figma is going to leave you a bit cold.

    Adobe Creative Cloud: The Bloated Empire That Still Wins on Raw Power

    Say what you want about Adobe’s pricing strategy (and people do, loudly), the Creative Cloud suite is still unmatched for certain workflows. Photoshop’s generative fill has gone from novelty to actually-useful in the span of eighteen months. Illustrator’s vector tools are still the industry benchmark. InDesign remains the only sensible option for anything involving long-form print layout. And Premiere Pro, if you’re doing motion work, is still the professional standard.

    The all-apps subscription sits at roughly £60 per month for individuals as of 2026, which is the number that makes every freelancer re-examine their life choices. It’s a lot. Adobe knows it’s a lot. They’re betting that Firefly’s AI features and deep integration across apps will justify the cost, and for studios doing varied, high-volume work across print and digital, that bet probably lands. For someone who only needs one or two apps? The maths doesn’t hold up as neatly.

    Adobe Express, their lighter browser-based tool aimed at social and marketing content, has improved substantially and is worth a look if you’re not doing complex work. It’s not Photoshop, but it’s not trying to be.

    Close-up of graphic design tools and tablet used with best graphic design software 2026
    Close-up of graphic design tools and tablet used with best graphic design software 2026

    Canva Pro: The Tool Professionals Love to Dismiss and Keep Using

    The design community’s complicated relationship with Canva is fascinating to watch. Every six months someone writes a serious piece about how it’s ruining the profession; every six months it gains another ten million users. Canva in 2026 is a genuinely capable tool for a specific class of work: fast-turnaround social assets, presentation decks, simple brand collateral, and anything that needs to be handed off to a non-designer without causing chaos.

    At around £13 per month for Pro, the template library, brand kit functionality, and Magic Studio AI tools are all included. It’s not built for pixel-perfect UI work or complex illustration, but for marketing and communications output it’s extremely efficient. Agencies handling content-heavy clients often maintain Canva alongside their heavier tools precisely because it removes the bottleneck of routing every quick social post through a senior designer.

    Businesses in the UK that invest in proper web design and brand software tend to see compounding returns on their marketing efficiency. Mansfield, Nottinghamshire-based digital agency dijitul, which specialises in web design, SEO, and website hosting for businesses across the East Midlands, has noted this pattern consistently across client work. The right software stack (dijitul.uk works with a range of tools depending on client need) reduces friction across the whole business efficiency chain, from brand creation through to published web pages. Their specialism in web design means software choices have a direct bearing on project delivery speed and output quality.

    The AI Challengers: Midjourney, Runway, and Adobe Firefly’s Rivals

    This is where things get genuinely interesting. The best graphic design software in 2026 no longer sits in a tidy bracket of traditional vector and raster tools. A clutch of AI-native platforms are doing real work now, not just demo-reel work.

    Midjourney v7 has reached a level of photographic fidelity and stylistic range that makes it a legitimate part of concepting and mood-boarding workflows. It’s not going to replace a skilled illustrator for anything requiring brand consistency, but for rapid ideation and client presentations where you need to communicate a visual direction quickly, it’s extraordinary. Pricing is around £8–£25 per month depending on usage tier.

    Runway Gen-3 is the motion design wildcard. If you’re doing video content or animated assets for web and social, Runway’s text-to-video and image-to-video capabilities have moved well past the uncanny valley stage for short-form content. Agencies producing branded content have started factoring it seriously into their estimates.

    Recraft is the sleeper pick few people outside the design community are talking about yet. It’s a vector-first AI image tool, proper SVG output, editable paths, brand colour locking, and it solves a genuine problem that Midjourney can’t: getting AI-generated visuals that fit inside a design system. Worth watching closely.

    Affinity Designer 2: The Serious Alternative for Price-Conscious Pros

    Serif’s Affinity suite continues to hold a very solid position as the sensible, one-time-purchase alternative to Adobe. Affinity Designer 2 handles both vector and raster work in a single environment, the performance on Apple Silicon is genuinely quick, and the £69.99 one-off licence (or £16.99/month for the whole suite) is a different conversation entirely to Adobe’s subscription. It lacks some of the ecosystem depth and third-party plugin support of the Adobe suite, but for freelancers doing brand and print work who don’t need the full CC stack, it’s a completely professional-grade option. According to BBC Technology coverage of the indie software market, tools like Affinity have genuinely disrupted the assumption that Adobe is the only credible option.

    Which Tool Actually Wins in 2026?

    There isn’t a clean answer, and anyone who gives you one is probably trying to sell you something. The best graphic design software 2026 has on offer depends almost entirely on what you’re actually building.

    UI and product design: Figma. Print and complex image editing: Adobe CC. Fast marketing content: Canva. Budget-conscious brand and print work: Affinity. AI-assisted concepting: Midjourney. Motion and video assets: Runway. Vector AI output: Recraft. These aren’t arbitrary recommendations; they reflect where each tool genuinely excels rather than where the marketing says it should.

    Agencies and freelancers making software decisions in 2026 increasingly treat their tool stack as an infrastructure choice. The shift matters because, as web design work has grown to encompass content systems, brand assets, and digital marketing material under one roof, the software used upstream affects everything downstream. Teams at digital agencies, the kind of operation handling SEO, web design, and business efficiency for multiple clients simultaneously, often run three or four tools in parallel rather than trying to force a single platform to cover every use case. That’s not inefficiency; it’s the right call given how specialised each tool has become.

    Pick the right tool for the actual job. Audit what you’re actually producing week to week. And probably stop paying for the full Adobe CC stack if you’re only ever opening Photoshop.

    Frequently Asked Questions

    What is the best graphic design software for beginners in 2026?

    Canva Pro is the most accessible starting point for beginners, with an intuitive interface and a massive template library. For those who want to progress toward professional-grade tools, Affinity Designer 2 offers a one-off purchase and a lower learning curve than Adobe Illustrator.

    Is Figma still worth using in 2026 or have competitors caught up?

    Figma remains the strongest option for collaborative UI and web design work. Its browser-based model, shared component libraries, and improved AI layout tools keep it ahead for teams working on digital products. Competitors have narrowed the gap in some areas, but nothing has overtaken it for collaborative interface design.

    How much does Adobe Creative Cloud cost in the UK in 2026?

    Adobe Creative Cloud’s all-apps plan costs approximately £60 per month for individuals in the UK. Single-app plans are cheaper, typically around £23–£28 per month. Adobe also offers discounted plans for students, teachers, and businesses on multi-seat licences.

    Are AI graphic design tools like Midjourney good enough for professional work?

    For specific tasks, mood boarding, concept art, social media visuals, and rapid ideation, AI tools like Midjourney v7 are genuinely professional-grade in 2026. However, they still require human oversight for brand consistency, accuracy, and anything needing precise editable assets. Most professionals use them alongside traditional tools rather than instead of them.

    What is the best graphic design software for freelancers on a budget?

    Affinity Designer 2 offers a one-off licence at £69.99, making it the strongest value option for freelancers who need professional vector and raster tools without a monthly subscription. Figma’s free tier also covers a lot of ground for UI-focused work, and Canva Pro at around £13 per month suits those doing primarily marketing and social content.

  • Spatial Design for UI Designers: How to Adapt Your Skills for Mixed Reality

    Spatial Design for UI Designers: How to Adapt Your Skills for Mixed Reality

    Right, so the headsets are no longer just a tech demo at trade shows. Apple’s Vision Pro has been in people’s living rooms, Meta Quest 3 is being handed out at Christmas, and developers across the UK are quietly panicking because their entire skill set is built around a flat rectangle. If you’ve spent years perfecting pixel-perfect layouts on 1440p screens, the shift to volumetric, three-dimensional interface design feels like someone changed the rules mid-game. Which, to be fair, they have.

    Spatial design for UI designers isn’t some distant futurism anymore. It’s a present-tense career skill. And the good news is that your existing knowledge doesn’t get binned. It gets extended, sometimes stretched uncomfortably, but extended nonetheless.

    Designer using a mixed reality headset to explore spatial design for UI designers in a London studio
    Designer using a mixed reality headset to explore spatial design for UI designers in a London studio

    What Spatial Design Actually Means (Not the Buzzword Version)

    Let’s be precise. Spatial design, in the context of mixed reality and extended reality (XR), refers to the practice of designing interfaces, information, and interactive elements that exist within three-dimensional space, rather than constrained to a flat screen surface. Instead of a canvas with X and Y axes, you’re working with X, Y, and Z. Depth is now a design variable.

    In a mixed reality headset like Vision Pro, a UI panel doesn’t sit inside a monitor. It floats in your kitchen. Users can walk around it, look at it from an angle, or physically reach out to interact. That changes almost everything about hierarchy, readability, affordance, and spatial audio as a design layer. The BBC’s technology coverage has tracked how these devices are moving from novelty to genuine productivity tools, which tells you the design profession needs to catch up quickly.

    The Core Principles That Actually Transfer From Screen Design

    Here’s what I’d tell any screen-based UI designer who’s feeling overwhelmed: your instincts about hierarchy, contrast, and cognitive load are still completely valid. Spatial design doesn’t throw those out. It complicates them.

    Visual hierarchy still matters enormously. In fact, it matters more, because users can now look in any direction. You can’t assume their gaze is somewhere in the centre-top third of a fixed canvas. Designing for spatial environments means thinking about where attention naturally falls in three-dimensional space, which ties directly to concepts from environmental design and wayfinding, disciplines that graphic designers have largely ignored until now.

    Typography principles carry over too, but with major caveats. Text rendering in XR headsets is improving fast, but legibility at distance and from off-angles is genuinely different from screen typography. Font weights that work at 16px on a Retina display can fall apart when a text panel is floating 1.2 metres away from a user’s face. You need to think in angular resolution, not pixels. That’s a mindset shift.

    Colour and contrast remain critical. In passthrough mixed reality, your UI layers over a real physical environment that you can’t control. That cream-coloured wall behind a floating button might destroy your contrast ratio entirely. Designing for spatial contexts requires building in far more contrast tolerance than you’d typically use on a screen.

    Floating spatial UI panels demonstrating depth and hierarchy principles in spatial design for UI designers
    Floating spatial UI panels demonstrating depth and hierarchy principles in spatial design for UI designers

    What Doesn’t Transfer and What You Need to Learn Fresh

    Scrolling is mostly dead, and that’s going to take some unlearning. The entire paradigm of infinite scroll, long-form vertical layouts, sticky navigation, all of it maps poorly to spatial interfaces. Instead, spatial design favours panels, contextual layers, and proximity-based information reveal. Content appears because you looked at something, moved towards it, or reached for it. The interaction model is fundamentally gestural and gaze-driven.

    Depth management is a new discipline you’ll need to build from scratch. Which elements sit in the foreground? Which recede? How do you communicate to a user that a control is behind them without a minimap? These problems don’t have twenty years of design pattern libraries behind them. You’re in early-explorer territory, which is either thrilling or terrifying depending on your disposition.

    Scale is genuinely strange in spatial design. Objects in XR have real-world scale. A modal dialogue that’s 600px wide on a web page becomes something you have to define in centimetres or metres in a volumetric environment. Too large and it’s overwhelming; too small and it’s fiddly. Ergonomic comfort zones, the angles and distances at which interaction feels natural, become a design constraint in the same way that viewport sizes are on the web.

    Audio as a design layer is also something screen-based designers rarely touch but spatial designers use constantly. Positional audio tells users where elements are, confirms interactions, and creates environmental feedback. If you’ve never thought about sound design, that gap needs filling.

    How to Actually Start Practising Spatial Design for UI Designers

    You don’t need to own a headset to start developing spatial intuition, though access to one obviously accelerates things. Here’s a more pragmatic path.

    Start by studying game UI design. Games have been solving volumetric interface problems for decades. Head-up displays in first-person games, diegetic interfaces that exist within the game world, contextual menus that appear near objects. Dissecting how studios like Rare or Rocksteady handle in-game UI teaches you a tremendous amount about designing for spatial contexts without writing a single line of Unity code.

    Learn the basics of Apple’s visionOS Human Interface Guidelines and Meta’s Presence Platform design principles. Both are publicly available and represent the current best thinking on spatial interface patterns. They’re genuinely well-written, even if parts of them feel like you’re reading from the future.

    Figma isn’t the right tool for spatial work, full stop. You’ll eventually need to get comfortable with either Unity, Unreal Engine, or a prototyping tool like ShapesXR or Gravity Sketch. Unity in particular has strong UK community support, with groups active in cities like London, Manchester, and Edinburgh. Getting into those communities early puts you in rooms where the practical knowledge actually lives.

    Why This Matters for Your Career Right Now

    The UK’s XR industry is not tiny. According to research from Immerse UK, the country’s immersive technology sector has been growing consistently, with significant investment going into training, healthcare, architecture, and retail applications. These sectors need designers who understand both screen conventions and spatial interaction. That intersection is currently occupied by very few people.

    Spatial design for UI designers isn’t a replacement specialism, it’s an extension. The designers who move first, who build even a basic working vocabulary in volumetric interfaces, are going to be substantially more valuable over the next five years than those who wait until the tooling is more mature. The tooling is mature enough now to learn from. It’s not mature enough yet that the patterns are locked in, which means there’s still room to help define them.

    If you’ve got strong screen design fundamentals, a willingness to unlearn a few assumptions, and even a passing interest in how spatial computing actually works, the transition is more achievable than the headset marketing makes it seem. Start small. Study the principles. Get hands-on when you can. The flat rectangle has had a good run, but design doesn’t stop at the edge of a screen.

    Frequently Asked Questions

    What is spatial design for UI designers?

    Spatial design for UI designers refers to the practice of designing interfaces and interactive elements that exist in three-dimensional space, as used in mixed reality and XR headsets, rather than on flat screens. It extends traditional screen design skills into volumetric environments where depth, scale, and physical ergonomics become core design constraints.

    Do I need a mixed reality headset to learn spatial design?

    Not initially. You can build foundational spatial design skills by studying game UI design, reading Apple’s visionOS and Meta’s Presence Platform guidelines, and learning tools like Unity or ShapesXR. That said, hands-on headset time accelerates your understanding of scale and ergonomics significantly, so getting access to a device as soon as you can is worthwhile.

    Which tools do spatial designers use instead of Figma?

    Figma is largely unsuitable for volumetric spatial design work. Common tools include Unity, Unreal Engine, ShapesXR, and Gravity Sketch. Unity is particularly well-supported in the UK, with active developer and design communities in cities like London and Manchester.

    How is spatial design different from regular UX design?

    Regular UX design operates on a fixed two-dimensional canvas with defined viewport sizes and predictable user gaze. Spatial design introduces a third axis of depth, variable real-world scale, gaze and gesture-based interaction, and the challenge of overlaying interfaces on uncontrolled physical environments. Many familiar patterns like vertical scroll and sticky navigation map poorly to spatial contexts.

    Is spatial design a good career direction for UK designers in 2026?

    Yes, and increasingly so. The UK’s immersive technology sector, tracked by organisations like Immerse UK, is growing across healthcare, retail, architecture, and training. Designers who combine strong screen-based fundamentals with spatial design knowledge are in relatively short supply, making it a genuinely valuable skill combination right now.

  • No-Code vs Low-Code vs Full Code: Choosing the Right Build Approach for Your Next Project

    No-Code vs Low-Code vs Full Code: Choosing the Right Build Approach for Your Next Project

    The question of how to actually build something has never been more loaded. In 2026, the gap between dragging a block in Webflow and writing a custom API route in Next.js is enormous, but both approaches can ship a production-ready product. Understanding the no-code vs low-code vs full code 2026 landscape properly, rather than just defaulting to what you already know, is genuinely one of the most useful decisions you can make before a single pixel gets placed or a single line gets typed.

    This isn’t about which approach is objectively best. It’s about which one fits the project sitting in front of you right now. Let’s actually break it down.

    Designer and developer comparing no-code vs low-code vs full code 2026 build approaches at studio workstations
    Designer and developer comparing no-code vs low-code vs full code 2026 build approaches at studio workstations

    What Do We Even Mean by No-Code, Low-Code, and Full Code?

    These three terms get blurred constantly, usually by marketing teams trying to make their platform sound more accessible than it is. So let’s be precise.

    No-code means building entirely through a visual interface, no programming knowledge required. Webflow is the canonical example for websites. Framer sits in an interesting middle zone (more on that shortly). The idea is that logic, layout, and interactions are all abstracted behind GUI controls.

    Low-code means a visual-first environment that still expects you to write some code when complexity demands it. Framer’s React override system is a great example. You can build 90% of a site visually, then drop into TypeScript for a custom animation or data fetch. Platforms like Bubble fall here too for web apps.

    Full code means you’re writing everything from scratch, or close to it. Next.js, Remix, SvelteKit, raw React. You control the architecture, the performance, the data layer, all of it. The ceiling is unlimited. So is the time investment.

    The Case for No-Code: Webflow and the Visual Web

    Webflow has matured considerably. Its CMS is genuinely powerful for content-heavy marketing sites, and the Interactions panel gives motion designers a level of control that would have required GSAP and a developer two years ago. For a UK agency spinning up a client brochure site, a campaign landing page, or a portfolio, Webflow is hard to argue against on speed-to-launch alone.

    The honest limitations, though, are real. Custom authentication flows, complex database relationships, dynamic user dashboards, Webflow starts to creak. You’ll find yourself reaching for Memberstack, Airtable, Zapier, and a growing stack of third-party bolt-ons that each cost money and introduce failure points. At some point, you’re maintaining a Frankenstein architecture held together by webhooks and crossed fingers.

    Best for: marketing sites, portfolios, content-driven blogs, campaign pages, client projects where the brief is well-defined and scope is unlikely to balloon.

    Developer working on low-code build tools in a comparison of no-code vs low-code vs full code 2026
    Developer working on low-code build tools in a comparison of no-code vs low-code vs full code 2026

    The Case for Low-Code: Framer’s Interesting Proposition

    Framer occupies a genuinely interesting space in the no-code vs low-code vs full code 2026 conversation. It started as a prototyping tool, pivoted aggressively to being a publishing platform, and is now used by design-led teams at some serious companies. The visual canvas is arguably better than Webflow’s for highly expressive, animation-heavy sites. The component model maps closely enough to React that moving to full code later isn’t a complete rewrite.

    Where Framer shines is for design teams who want to own the build. Designers can ship real sites without waiting for a developer, but developers can drop into code overrides when something bespoke is needed. It’s collaborative in a way that feels natural rather than forced.

    The caveats: Framer’s CMS is still less mature than Webflow’s, and for anything approaching a real web application, you’ll outgrow it quickly. It’s also worth keeping an eye on pricing, as Framer’s plans have shifted a few times and costs can accumulate for larger teams. The UK government’s guidance on open standards in technology is a useful reminder that platform lock-in is a real risk worth evaluating before committing.

    Best for: design-led teams, portfolio sites with heavy animation, marketing pages for tech companies, projects where designer autonomy is a priority.

    The Case for Full Code: Next.js and Owning Everything

    Next.js remains the dominant React framework in 2026 for good reason. Server components, edge rendering, the App Router, built-in image optimisation, and a deployment pipeline that slots directly into Vercel or a self-hosted setup. If you’re building a SaaS product, an e-commerce platform, a membership site with real logic, or anything that needs to scale with user data, full code is the only honest answer.

    The trade-off is time and expertise. A Next.js project requires architectural decisions upfront: database choice, authentication strategy, state management, API design. You’re not dragging blocks; you’re writing components, managing dependencies, handling errors, writing tests. For a small studio or solo developer, the overhead is real.

    That said, the developer experience in 2026 is genuinely good. TypeScript tooling is excellent, component libraries like shadcn/ui have removed enormous amounts of boilerplate, and deployment is faster than ever. If you have the skills or the team, full code gives you nothing you can’t build.

    Best for: SaaS products, web applications with user accounts, e-commerce with custom logic, anything requiring a real backend, projects with long-term scale requirements.

    How to Actually Choose: A Practical Framework

    Here’s the decision tree I tend to use when scoping a new project.

    Start with the question: does this project need user accounts, custom logic, or a real database relationship beyond basic CMS fields? If yes, you’re in full code territory unless you want to spend months patching low-code workarounds.

    If no, ask: does the design require significant custom animation, unusual layout patterns, or component-level interactivity? If yes, Framer’s low-code model is worth serious consideration. If the design is relatively conventional, Webflow’s no-code environment will get you to launch faster.

    Timeline and budget matter enormously. A startup with two weeks and a tight budget to validate an idea should not be commissioning a bespoke Next.js application. A growing platform with paying users and a development team should not be running on Webflow CMS bolted to four third-party services.

    The Hybrid Reality Most Projects Actually Live In

    The honest truth about the no-code vs low-code vs full code 2026 decision is that most real-world projects are hybrid. A marketing site in Webflow or Framer pulling data from a headless CMS, connected to a Next.js backend that handles authentication and payments. Or a Framer front-end with code overrides calling a lightweight API. These architectures are increasingly common, and they work well when scoped deliberately.

    The mistake is letting the approach choose itself by default. Picking Webflow because you’ve always used Webflow, or defaulting to Next.js because it feels more serious. The tool should serve the project, not the other way around. Get that decision right upfront and everything downstream is easier.

    Frequently Asked Questions

    Is Webflow good enough for a real business website in 2026?

    Absolutely, for most marketing and content-driven sites. Webflow handles CMS, SEO, hosting, and interactions well enough for the vast majority of business websites. Where it struggles is with complex user logic, real databases, and application-level features.

    Can Framer replace a developer entirely?

    For design-heavy marketing sites and portfolios, Framer can often get a designer to a shipped product without a developer. However, anything requiring custom backend logic, authentication, or complex data handling will still need developer involvement, either through Framer’s code overrides or a separate API.

    When should I use Next.js instead of a no-code platform?

    Use Next.js when your project needs user accounts, complex data relationships, a custom API, or any logic that goes beyond what a CMS can handle. It’s also the better choice when performance at scale, long-term maintainability, or bespoke functionality are priorities.

    How much does it cost to build with Webflow vs Next.js?

    Webflow’s pricing starts from around £14 per month for basic sites, scaling up to £35+ for CMS and e-commerce plans. Next.js itself is open-source and free, but you’ll factor in hosting (Vercel’s free tier is generous, paid plans start around £16 per month) plus development time, which is significantly higher than no-code.

    What is the best build approach for a SaaS startup in 2026?

    Most SaaS products genuinely need full code, specifically a framework like Next.js, because user authentication, billing, dashboards, and data logic require real engineering. You might use a no-code tool for the marketing landing page, but the actual product needs a proper codebase.

The Latest