Decision resource

What technology should I use for my website?

The right answer is the simplest architecture that reliably does what your business needs — and for most businesses that is several rungs below what an agency would enjoy building. This resource works out which rung you are on, and what would legitimately move you up one.

Almost every bad technology decision in this market is the same decision: a business is sold a level of machinery its requirements never asked for. A five-page plumbing site gets a database. A clothing shop gets a custom checkout. A team that publishes twice a year gets a headless CMS with a workflow engine. None of it is incompetent — it is all buildable, and it all works on the day it launches. It is simply more than the business needed, and the cost of that shows up later, as maintenance, as fragility, and as an inability to change anything without calling the person who built it.

So this page is organised around business situations rather than technologies. You will not find a ranking of frameworks. You will find the requirement that justifies each step up in complexity, stated plainly enough that you can check whether you have that requirement — and the honest answer for a lot of readers is a hosted builder and an afternoon, not a project.

Everything here is the reasoning we use on real projects, including the parts where the right recommendation is something we do not sell.

If you have not yet worked out what the site actually has to do, that decision comes first: what kind of website your business needs.

Work out your answer

Four or five questions about how your business operates — none about technology. Each one can only move you up the ladder, so you land on the simplest architecture that still satisfies something you actually said you needed.

Will people pay you through the website?

Money changing hands on the site — not an invoice you send afterwards.

The simplicity ladder

Five rungs, from least machinery to most. The rule that matters is the one between them: do not move up a level unless a requirement forces you to. Each rung below states what forces the next one.

Level 1Level 1 — Simple hosted builderOne product hosts, edits and serves the whole site. There is no separate CMS, no server you maintain and nothing to update.Framer, Squarespace, Carrd, Shopify's own pages for a shop that already exists.

Framer, Squarespace, Carrd, Shopify's own pages for a shop that already exists.

Right when

Under about fifteen pages, and the structure is not unusual.
The site's job is to be credible, explain the offer and produce enquiries.
Nobody needs to log in, and nothing needs to be stored per person.
Content changes occasionally, and one person can be trusted with the editor.

You have outgrown it when

You need a page type the builder cannot express, and you are faking it with duplicated pages.
Search is a primary acquisition channel and you are running into control limits — redirects, structured data, per-page metadata, internationalisation.
Someone needs to log in, buy something complicated, or see their own data.
The page count has grown to the point where a change means editing the same block twenty times.

What it costs to run

A subscription per month and a domain per year. No hosting bill and no maintenance retainer.

Who can change it

Anyone in the business, in a visual editor, without a deployment.

Architecture

HostingIncluded in the platform
PresentationPlatform templates and editor
ContentBuilt-in collections
FormsBuilt-in, to email
DatabaseNone — not present
AuthenticationNone — not present
BackendNone — not present

Level 2Level 2 — CMS-driven marketing siteA content management system your team publishes from, with a designed front end on top of it. Still one platform, but content is now structured rather than typed into a page.Webflow with its CMS, WordPress with a maintained theme, Shopify for a store with real content.

Webflow with its CMS, WordPress with a maintained theme, Shopify for a store with real content.

Right when

Content is a channel: service pages, locations, comparisons, case studies, a blog with a schedule.
Non-technical people publish regularly and cannot wait for a developer.
There are repeating page types — services, staff, locations, projects — that should share one structure.
Search matters commercially and you need control of metadata, redirects and structured data.

You have outgrown it when

Performance has become a commercial problem and the platform's output is the ceiling.
The design is fighting the builder — every layout needs a workaround that the next editor breaks.
You need content in two places at once: a website, an app, in-store screens.
You have started paying for four subscription apps to fake one feature.

What it costs to run

A platform subscription, plus plugins or apps. On WordPress, add real hosting and a maintenance budget — an unmaintained WordPress site is a security incident waiting for a slow week.

Who can change it

The marketing team, in the CMS, without touching layout.

Architecture

HostingPlatform (Webflow) or your host (WordPress)
PresentationTheme or visual build
ContentCMS collections and post types
FormsBuilt-in or a plugin
DatabaseThe CMS's own — you do not design it
AuthenticationEditors only — not present
BackendNone of your own — not present

Level 3Level 3 — Custom front end + CMSThe interface is built as code and the content lives in a headless CMS. The two are separate, so the site can be redesigned without re-entering the content, and the content can outlive the design.Next.js on Vercel with Sanity, Contentful or a Git-based content layer.

Next.js on Vercel with Sanity, Contentful or a Git-based content layer.

Right when

Search is a primary channel and the page count is large enough that structure and internal linking are strategy rather than housekeeping.
Performance is commercially material — a store, a lead engine, a publisher.
The design is genuinely bespoke and a builder would be reproduced at ninety per cent, badly.
Content must feed more than one surface, or must survive the next redesign.

You have outgrown it when

Users need accounts, private data, or anything that persists per person — that is Level 4, and it is a different project.
You are building business logic inside the CMS to avoid admitting you need a backend.

What it costs to run

Hosting on a serverless platform, a CMS subscription, and a developer relationship for changes to structure — not for changes to content.

Who can change it

Editors change content freely. Changing what a page type IS requires a developer, which is the trade you are making.

Architecture

HostingVercel or equivalent
PresentationNext.js / React, written for this business
ContentHeadless CMS, structured
FormsAPI route to email or CRM
DatabaseThe CMS's, plus nothing of your own
AuthenticationEditors only — not present
BackendThin — API routes, no state of its own

Level 4Level 4 — Custom front end + backend and databaseNow there is state. People sign in, records belong to them, and the system does things when nobody is watching. This is software with a website attached, rather than a website with features.Next.js with Supabase or Postgres, authentication, row-level security, Stripe for billing, Resend for transactional email.

Next.js with Supabase or Postgres, authentication, row-level security, Stripe for billing, Resend for transactional email.

Right when

Users log in and see data that is theirs — a client portal, a member area, a booking system you own.
The business has a process no existing product runs, and the process is the advantage.
Data must be queried and reported on in ways a spreadsheet or a CMS cannot express.
Something must happen on a schedule, or in response to an event, without a person.

You have outgrown it when

Multiple products, multiple teams and a genuine platform surface — Level 5, and mostly an organisational change rather than a technical one.

What it costs to run

Hosting, a managed database, an authentication provider, email, error tracking — and, unavoidably, an ongoing engineering relationship. Software is not a thing you buy once.

Who can change it

Marketing content, if a CMS was included. Everything else is a deployment, which is why the marketing site is often deliberately kept out of this level.

Architecture

HostingVercel or equivalent
PresentationNext.js / React application
ContentCMS for marketing pages, if there are any
BackendAPI routes, server actions, scheduled jobs
DatabasePostgres, with access rules per row
AuthenticationSupabase Auth, Clerk or equivalent
PaymentsStripe, if money changes hands

Level 5Level 5 — Full custom software or platformA product in its own right: anyone can sign up, billing runs itself, and the system is expected to keep working while the team sleeps. The website becomes marketing for the software, not the thing itself.A SaaS application — Next.js, Postgres, authentication with roles and organisations, Stripe subscriptions, transactional email, observability, a staging environment and a release process.

A SaaS application — Next.js, Postgres, authentication with roles and organisations, Stripe subscriptions, transactional email, observability, a staging environment and a release process.

Right when

Customers self-serve: they sign up, use it and are billed without you touching anything.
Multiple organisations use the same system and must never see each other's data.
The software is what you sell, or it is the operational core the business runs on.

You have outgrown it when

This is the top of the ladder. What changes past here is team structure, not architecture.

What it costs to run

Everything at Level 4, plus observability, on-call expectations, a security posture, and a roadmap. Budget for the second year before you commit to the first.

Who can change it

Product and engineering, on a release cycle.

Architecture

HostingManaged platform, plus a staging environment
PresentationApplication UI, plus a separate marketing site
BackendApplication services, jobs, webhooks
DatabasePostgres, with tenant isolation
AuthenticationAccounts, roles, organisations, SSO
PaymentsStripe subscriptions and entitlements
ObservabilityLogging, error tracking, alerting

Nine business situations

Find the one that matches how your business actually operates. Each states the normal answer, the defensible alternatives, the over-engineering that situation specifically invites, and the single requirement that legitimately moves it up a level.

Simple business websiteLevel 1A hosted builder — Framer or Squarespace — set up properly, with the domain and analytics in the business's own accounts.

Who this is

Contractors, consultants, local service companies, restaurants, clinics, trades, professional practices — businesses whose website has to establish that they are real and make it easy to get in touch.

What it has to do

Explain the offer, the service area and the prices or the range.
Look credible enough that a stranger is willing to call.
Produce enquiries: a form, a phone number, a map, opening hours.
Be found for the business's own name and a handful of local terms.

Normal answer

A hosted builder — Framer or Squarespace — set up properly, with the domain and analytics in the business's own accounts.

Nothing on the requirement list needs a database, a login or a deployment. What it needs is clear structure, credible design, fast pages, correct local search signals and a form that reaches a person. A hosted builder does all of that, and does it without creating anything for the business to maintain. The failure mode for this kind of site is almost never the platform — it is vague copy, no clear next step, and a Google Business Profile nobody filled in.

Also defensible

Webflow: There are repeating page types — several services, several locations — that should share one structure rather than being copies.
WordPress: The business already has a WordPress site, a person who maintains it, and no reason to migrate. Moving platforms is a cost; “WordPress is old” is not a requirement.
A static custom build: The brand is the product and the design must be genuinely bespoke — hospitality, luxury, architecture — or the site is a lead engine where performance and search structure are worth paying for.

The over-engineering to refuse

A database, a login, a headless CMS, or a custom-coded build for a five-page site nobody edits. A plumber does not need Supabase. If the proposal contains one, ask which requirement it serves and expect a specific answer.

What legitimately moves it up

Search becoming a real acquisition channel — the moment you want twenty service-by-neighbourhood pages that share a structure, you have moved to Level 2.

Level 1 — Simple hosted builder →

Marketing / SEO-heavy websiteLevel 2Webflow when the marketing team must own the pages end to end. Next.js with a headless CMS when the page count is large, performance is commercially material, or the site is bilingual and the URL architecture matters.

Who this is

Businesses where organic search and paid landing pages are a primary source of customers: agencies, SaaS marketing sites, multi-service or multi-location companies, anyone running content as a channel.

What it has to do

Many landing pages that share a structure and can be produced quickly.
A blog or resource library, published to a schedule by non-developers.
Excellent Core Web Vitals, because performance is both a ranking input and a conversion input.
Full control of metadata, canonicals, redirects, structured data, sitemaps and hreflang.
Conversion tracking that survives consent, and analytics you can actually act on.

Normal answer

Webflow when the marketing team must own the pages end to end. Next.js with a headless CMS when the page count is large, performance is commercially material, or the site is bilingual and the URL architecture matters.

This is the situation where the platform genuinely changes results. Landing pages are only cheap if the page type exists once and the team can produce instances of it; performance is only reliable if you control what ships to the browser; and search structure — canonicals, redirects, hreflang — is only controllable if the platform exposes it. Those three are exactly where hosted builders start to run out of room, and exactly where a custom front end starts to earn its cost.

Also defensible

WordPress: There is an existing content team who know it, someone accountable for updates, and a plugin that genuinely solves a requirement rather than adding one.
Staying on a hosted builder: Search matters but the site is small. Do not migrate a fifteen-page site for search reasons alone — fix the content and the structure first, and see whether the platform was ever the constraint.

The over-engineering to refuse

A backend and a database for a site that publishes articles. Content is not application state. If nothing is stored per user, the CMS is the only database in this project.

What legitimately moves it up

Content needing to feed a second surface — an app, in-store screens, a partner feed — or performance hitting the platform's ceiling. Both point at Level 3.

Level 2 — CMS-driven marketing site →

Content-heavy publisherLevel 3A headless CMS with proper roles and scheduling — Sanity, Contentful, or WordPress used strictly as a headless back end — with a Next.js front end.

Who this is

Magazines, newsrooms, research and education sites, large resource libraries — anywhere the content is the product and more than one person is responsible for it.

What it has to do

Frequent editing, by several people, without collisions.
Real editorial workflow: drafts, review, scheduled publishing, embargoes.
Taxonomy that holds up at volume — categories, tags, series, authors.
Media handling: images at multiple sizes, video, captions, credits.
Archives that stay fast and stay indexed as they grow into the thousands.

Normal answer

A headless CMS with proper roles and scheduling — Sanity, Contentful, or WordPress used strictly as a headless back end — with a Next.js front end.

Publishing is the case where the editorial experience is a business requirement, not a convenience. Editors need drafts and scheduling; the archive needs to stay quick at scale; and the content needs to outlive several redesigns. Separating content from presentation is what makes all three possible at once. It is also the one situation where WordPress's editorial model, thirty years of refinement deep, is a genuine argument in its favour.

Also defensible

WordPress, traditionally themed: The editorial team is large, already trained, and the performance requirements are ordinary. Do not headless a newsroom for fashion — it doubles the surface area you maintain.
Webflow CMS: The library is in the low hundreds of items and the workflow is simple. Its item limits and editorial workflow are the constraints to check before committing.

The over-engineering to refuse

Building a custom CMS. Editorial software is a solved problem with decades of usability work behind it, and a bespoke admin panel will be worse on the day it ships and worse still in three years. Build a custom CMS only when the content model is genuinely unrepresentable — and it almost never is.

What legitimately moves it up

Subscriptions, paywalls or reader accounts. That is Level 4, because it introduces users and things that belong to them.

Level 3 — Custom front end + CMS →

EcommerceLevel 2Shopify, unless something about how you sell genuinely breaks a normal store. Put the effort into the theme, the product data and the merchandising rather than into the plumbing.

Who this is

Anyone selling products online — a first store, an established brand, direct-to-consumer, or a wholesale operation moving online.

What it has to do

A catalogue with variants, inventory and collections.
A checkout that converts, and that handles tax, shipping and fraud correctly.
Payments, refunds and chargebacks handled compliantly.
Operations: orders, fulfilment, returns, customer records, reporting.
Marketing: discounts, email, abandoned carts, product feeds.

Normal answer

Shopify, unless something about how you sell genuinely breaks a normal store. Put the effort into the theme, the product data and the merchandising rather than into the plumbing.

Checkout is the most expensive component in commerce and the least visible. Tax across jurisdictions, address validation, fraud screening, PCI scope, payment method coverage, retries on failed cards, refunds, chargebacks — Shopify has spent well over a decade on that surface, it improves without you, and it is regulated territory where being wrong is expensive. Rebuilding it is a large project whose best possible outcome is parity with what you could have rented. Almost every store that thinks it needs custom commerce actually needs a better theme, cleaner product data and a merchandising decision.

Also defensible

Shopify with a custom front end (headless): The brand or content experience is genuinely a differentiator and the storefront is a real design problem — but keep Shopify's checkout. Headless means custom storefront, not custom checkout.
WooCommerce: The business is already deep in WordPress, the catalogue is modest, and someone is accountable for maintenance and PCI posture.
Custom commerce: Per-customer contract pricing, rentals with availability and returns, complex configurators, marketplaces with third-party sellers, or an ERP that must remain the source of truth. These are real, and they are rarer than they are claimed.

The over-engineering to refuse

A custom checkout. A clothing store does not need one. If a proposal includes rebuilding checkout, ask what it will do that Shopify's will not, and price the compliance and maintenance of the answer alongside the build.

What legitimately moves it up

Selling models a store cannot express — subscriptions with entitlements, usage billing, per-account catalogues. At that point commerce has become an application, which is Level 4.

Level 2 — CMS-driven marketing site →

Booking / service businessLevel 1Embed the booking product your industry already runs on — Calendly, Square, Acuity, OpenTable, Jane, your practice management system — into whatever level the rest of the site is at. Booking rarely changes the architecture of the website.

Who this is

Clinics, salons, studios, restaurants, trades with scheduled visits, consultants selling time, tours and rentals.

What it has to do

Availability that reflects reality — staff, rooms, equipment, travel time.
Confirmations, reminders and rescheduling without phone calls.
Deposits or payment at the time of booking, where that suits the business.
Whatever the industry already expects: OpenTable, a practice management system, a POS.

Normal answer

Embed the booking product your industry already runs on — Calendly, Square, Acuity, OpenTable, Jane, your practice management system — into whatever level the rest of the site is at. Booking rarely changes the architecture of the website.

This is the clearest example of the integrate-versus-build split, and the one where the cost difference is largest. Embedding a scheduling tool is configuration and styling; building an availability engine is software, with rules about staff, resources, buffers, cancellations, time zones, no-shows and reminders — every one of which is a decision someone has to make and maintain. The industry tool also usually carries something you cannot rebuild cheaply: reminders that reduce no-shows, a payments relationship, and compliance if health records are involved.

Also defensible

A booking system you own: Availability depends on rules no product expresses — multi-resource jobs, technician routing, equipment that must return before it can go out again — or the booking flow itself is the differentiator.
Booking through the ecommerce platform: You already run Shopify and are selling appointments as products with a straightforward calendar.

The over-engineering to refuse

Building a scheduling engine because the embedded widget does not match the brand fonts. Style the embed, or choose a product that allows styling. The visual mismatch costs a fraction of what maintaining a calendar system costs.

What legitimately moves it up

Availability rules no product can express, or bookings that must drive an operational system you own. Then it is Level 4 — and it is a software project with a website beside it, not a bigger website.

Level 1 — Simple hosted builder →

Membership / authenticated portalLevel 4First, check whether a product already does it: Circle, Memberstack, a course platform, your CRM's client portal. If none fits, this is where a backend earns its place — Next.js with Supabase or Postgres, real authentication, access rules enforced per row, Stripe for billing.

Who this is

Associations, course providers, agencies giving clients a place to see their own work, B2B suppliers exposing pricing or documents, communities behind a login.

What it has to do

Accounts, and content or data that only the right person can see.
Roles: member, admin, staff, sometimes organisation-level access.
Recurring billing, if membership is paid.
A record of things that belong to a person — files, progress, invoices, tickets.

Normal answer

First, check whether a product already does it: Circle, Memberstack, a course platform, your CRM's client portal. If none fits, this is where a backend earns its place — Next.js with Supabase or Postgres, real authentication, access rules enforced per row, Stripe for billing.

This is the boundary the whole ladder is built around. The moment data belongs to a specific person, you have taken on responsibility for access control, for privacy law, for password and session handling, and for what happens when someone leaves. That responsibility is exactly what Supabase, Clerk and their peers exist to reduce — and it is exactly why a login should never be added casually to a marketing site. A portal is not a page behind a password; it is an application with a marketing site attached.

Also defensible

An off-the-shelf membership product: The requirement is content behind a login and recurring billing. This covers more cases than most agencies admit, and it removes the security surface entirely.
A shared workspace instead of a portal: The real requirement is “clients can see their files and the project status”. Notion, a shared drive or your project tool often satisfies that for the cost of an afternoon.

The over-engineering to refuse

Building a portal to deliver something an email attachment or a shared folder already delivers. Portals are frequently bought to look organised and then abandoned because logging in is more friction than the value inside.

What legitimately moves it up

Anyone being able to sign up unattended, with self-serve billing and tenants who must never see each other — that is Level 5.

Level 4 — Custom front end + backend and database →

SaaSLevel 5Next.js and React on Vercel; Postgres, usually via Supabase, with row-level security; Supabase Auth or Clerk for accounts; Stripe for subscriptions; Resend for transactional email; GitHub with previews and a staging environment; error tracking and uptime alerting from day one.

Who this is

Software sold as a subscription, where customers sign up themselves, use the product, and are billed automatically.

What it has to do

An application interface that is the product, not a description of it.
Multi-tenancy: strict isolation between customer organisations.
Authentication with roles, invitations and — eventually — SSO.
Subscription billing, plan changes, proration, dunning, entitlements.
Transactional email that reliably arrives.
Observability: you find out something is broken before your customers tell you.

Normal answer

Next.js and React on Vercel; Postgres, usually via Supabase, with row-level security; Supabase Auth or Clerk for accounts; Stripe for subscriptions; Resend for transactional email; GitHub with previews and a staging environment; error tracking and uptime alerting from day one.

This is the one situation on this page where custom architecture is the obvious answer rather than a risk, because the software IS the product — you cannot rent the thing you are selling. The discipline that matters here is different: not “should this be custom” but “how little can we build for the first version”. Buy authentication, buy billing, buy email, buy error tracking. Build only the part your customers are paying for. Teams that build their own auth and their own billing to save subscription fees routinely spend a quarter doing it and inherit the security burden permanently.

Also defensible

Validate on no-code first: The product hypothesis is unproven. A concierge version behind a form and a spreadsheet answers the question that matters far more cheaply than a platform does.

The over-engineering to refuse

Microservices, Kubernetes and event buses for a product with no users yet. A single well-structured application on managed infrastructure will carry you further than most founders expect, and it is far easier to split something that works than to assemble something that never quite did. Equally: a SaaS dashboard should not be assembled from page-builder pages — the product surface is application state, which is not what those tools are for.

What legitimately moves it up

Scale problems you can actually measure. Split a service when a specific bottleneck demands it, not in anticipation of one.

Level 5 — Full custom software or platform →

Internal business applicationLevel 4Apply the buy-first test hardest here. If an existing product does most of it, run it and build the missing part. Where custom is right, an internal tool is usually the cheapest custom software there is: a Next.js interface over Postgres, authentication, and honest scope.

Who this is

Operations software used by staff rather than customers: a CRM, quoting or dispatch tooling, an approval workflow, inventory, reporting dashboards.

What it has to do

Encode a process that currently lives in spreadsheets, email and people's heads.
Records with a history, and reporting across them.
Permissions by role, and an audit trail where decisions have consequences.
Connections to the systems that already hold the data.

Normal answer

Apply the buy-first test hardest here. If an existing product does most of it, run it and build the missing part. Where custom is right, an internal tool is usually the cheapest custom software there is: a Next.js interface over Postgres, authentication, and honest scope.

Internal tools have a hidden advantage — the users are your own staff, so the interface can be plain, the edge cases can be handled by a person, and the requirements can be gathered by walking over to someone's desk. That makes them unusually good value when the process really is unusual. But the same conditions make them easy to over-scope: the request is often for a system that replaces four tools when what is needed is one screen that removes one repeated hour a week.

Also defensible

Configure an existing platform: The process is common — sales pipeline, tickets, projects, inventory. Airtable, a proper CRM or your ERP will beat a custom build for years.
An automation instead of an application: The requirement is really “this data should move from A to B without a person”. That is a workflow, not a system, and it is a fraction of the cost.

The over-engineering to refuse

Rebuilding a CRM. Also: dashboards nobody opens. Before building a reporting system, find out which decision the report changes — if the answer is none, the report is a project with no return.

What legitimately moves it up

The tool becoming something you would sell to others. That is a different business, and it needs the Level 5 requirements — multi-tenancy, self-serve billing, support.

Level 4 — Custom front end + backend and database →

Highly custom platformLevel 5Custom, and scoped in writing before anything is built. Paid discovery that produces a requirements document, an architecture and a fixed build price is not a formality here — the requirements are the expensive part, and they do not exist yet.

Who this is

Marketplaces, logistics and routing systems, regulated workflows, data products, anything where the way the business operates is not represented by any product on the market.

What it has to do

A domain model that no off-the-shelf system expresses.
Rules, states and integrations specific to this business.
Frequently: compliance, auditability, or data residency requirements.
A long life, and therefore a maintainable architecture rather than a clever one.

Normal answer

Custom, and scoped in writing before anything is built. Paid discovery that produces a requirements document, an architecture and a fixed build price is not a formality here — the requirements are the expensive part, and they do not exist yet.

This is where custom software is straightforwardly correct: when the process is the competitive advantage, encoding it is the investment. The risk is no longer over-engineering the architecture — it is building the wrong thing accurately. So the money goes into deciding what to build, into shipping the smallest version that a real user can use for real work, and into boring, well-understood infrastructure underneath. Nobody can honestly price a platform from a questionnaire, and any studio that does is guessing at your expense.

Also defensible

A composed stack of existing products: The unusual part is one step in an otherwise ordinary process. Ninety per cent bought and ten per cent built beats a hundred per cent built, permanently.

The over-engineering to refuse

Architecting for a scale you have not reached. The most common failure at this level is not too little engineering — it is a system designed for the company you hope to be in five years, shipped so late that the company you are now could not wait for it.

What legitimately moves it up

Nothing above this. The next constraint is organisational: who maintains it, who is on call, and what happens when the person who understood it leaves.

Level 5 — Full custom software or platform →

Comparison by criterion

Six approaches against the fifteen criteria that decide real projects. Rows are approaches rather than individual products, because the choice a business makes is architectural — “a hosted builder” is a decision; “Framer rather than Squarespace” is a preference.

There are no scores out of ten here, deliberately. Nobody can defend why one platform's SEO is a 7 and another's an 8, and a number invents a precision that does not exist. What can be defended is the decision a rating implies, so each cell says what it would mean for your choice — and carries the fact behind it. These are judgements from building and maintaining these stacks, not benchmarks.

A reason to choose it
Fine, with a caveat
Possible, but it fights you
Wrong tool for this

Comparison by criterion
Criterion	Hosted builderFramer, Squarespace	Visual CMSWebflow	WordPressSelf-hosted, themed	ShopifyHosted commerce	Custom front end + CMSNext.js + Sanity	Custom app + backendNext.js + Supabase
Setup complexity	A reason to choose it Live in days. No environment, no build step, no hosting decision.	Fine, with a caveat Days to weeks. Structuring collections properly is real design work.	Fine, with a caveat Fast to stand up, slow to make good. Theme and plugin choices decide the next five years.	A reason to choose it A working store, with payments and tax, in days.	Possible, but it fights you Weeks. Content modelling, front end and deployment are all real decisions.	Wrong tool for this For a marketing site, this is the wrong starting point. For an application, it is the beginning of a project, not a launch.
Ongoing maintenance	A reason to choose it Nothing to patch. The platform updates itself.	A reason to choose it Hosted and patched by the platform.	Possible, but it fights you Core, theme and plugin updates are ongoing and non-optional. Unmaintained WordPress is the most commonly compromised software on the web.	A reason to choose it Platform, checkout and compliance are Shopify's problem. Apps are yours.	Fine, with a caveat Dependencies need periodic updates, but there is no server to patch and a smaller attack surface than a plugin ecosystem.	Possible, but it fights you Dependencies, migrations, security patches and someone accountable when it breaks at 2am.
Client editing	A reason to choose it Visual editing by anyone, published instantly.	A reason to choose it The Editor role lets marketing publish without touching layout.	A reason to choose it Thirty years of editorial refinement, and a workforce that already knows it.	A reason to choose it Products, collections and content in one admin the whole team can use.	A reason to choose it Editors get a purpose-built model. Changing what a page type IS still needs a developer.	Possible, but it fights you Content editing exists only if a CMS was deliberately included. Everything else is a deployment.
SEO flexibility	Fine, with a caveat Metadata, sitemaps and redirects are handled; advanced control — hreflang, granular structured data, edge rules — varies and should be checked before committing.	A reason to choose it Per-page control, redirects, canonicals, sitemaps and structured data are all exposed.	A reason to choose it Complete control, with mature plugins. The constraint is discipline, not capability.	Fine, with a caveat Solid, with known constraints — enforced URL prefixes and limited control over some generated pages.	A reason to choose it Total control: metadata, canonicals, hreflang, structured data, redirects, sitemaps, rendering strategy.	A reason to choose it Complete control — though most of an application is behind a login and correctly not indexed at all.
Performance	Fine, with a caveat Usually good out of the box; the ceiling is the platform's, and heavy animation or embedded scripts erode it quickly.	Fine, with a caveat Good when built carefully; degrades with heavy interactions and third-party embeds.	Possible, but it fights you Achievable, but it is work: caching, image handling and plugin restraint. Plugin sprawl is the usual cause of a slow site.	Fine, with a caveat Fast by default; app scripts are the usual reason a store stops being fast.	A reason to choose it You decide what ships to the browser, which is the only durable way to hold Core Web Vitals.	A reason to choose it Yours to control, and yours to get wrong. Database queries become the thing that decides it.
Ecommerce	Possible, but it fights you Fine for a handful of products. Not an operations platform.	Possible, but it fights you Exists, but is not competitive with a dedicated commerce platform for real operations.	Fine, with a caveat WooCommerce is capable and puts you in charge of PCI posture, updates and uptime.	A reason to choose it Checkout, tax, fraud, payments, inventory and reporting — the whole surface, maintained for you.	Fine, with a caveat Correct as a storefront in front of Shopify. Building the commerce engine itself is a different project.	Fine, with a caveat Necessary only for selling models a commerce platform cannot express. Otherwise a large, avoidable cost.
Authentication	Wrong tool for this Password-gating a page is not authentication.	Possible, but it fights you Member features exist; anything beyond gated content wants a real backend.	Fine, with a caveat Users and roles exist; membership plugins extend them. Security posture is yours to own.	Fine, with a caveat Customer accounts are built in. Not a general-purpose identity system.	Fine, with a caveat Straightforward to add — but adding it means you are at Level 4, not Level 3.	A reason to choose it The reason to be here. Accounts, roles, sessions and per-row access rules.
Database / persistence	Wrong tool for this Collections hold content, not per-user records.	Possible, but it fights you CMS collections, with item limits worth checking against your archive.	Fine, with a caveat A real database underneath, though the schema is WordPress's rather than yours.	Fine, with a caveat Products, orders and customers, with metafields for the rest. Not a place for unrelated application data.	Fine, with a caveat The CMS is the database. Add your own only when something must persist per user.	A reason to choose it A schema designed for your domain, which is the whole point of this level.
Custom workflows	Wrong tool for this No place to run business logic.	Possible, but it fights you Logic means third-party automation services, not code you control.	Fine, with a caveat Hooks and custom plugins can do genuine work — at the cost of maintaining that code inside someone else's release cycle.	Fine, with a caveat Flow, apps and functions cover a lot; genuinely unusual logic needs code beside the platform.	Fine, with a caveat API routes and scheduled jobs handle real logic without a full backend.	A reason to choose it Any rule, any schedule, any integration. Nothing is “not supported”.
Scalability	Fine, with a caveat Traffic scales fine. Page count and structural complexity are what break first.	Fine, with a caveat Comfortable into the hundreds of items; plan the architecture past that.	Fine, with a caveat Scales with caching and infrastructure attention. Very large sites do run on it, with teams.	A reason to choose it Handles traffic spikes and large catalogues without you thinking about it.	A reason to choose it Static generation and edge delivery scale essentially without limit.	A reason to choose it Scales as far as the architecture and the database design allow.
Development cost	A reason to choose it The lowest credible entry point for a professional site.	Fine, with a caveat Mid-range. Cheaper than custom, more than a builder.	A reason to choose it Enormous supply of developers and themes keeps entry cost low.	A reason to choose it Money goes into theme, product data and merchandising rather than plumbing.	Possible, but it fights you The most expensive option that is not an application. Justified by traffic, page count or brand.	Wrong tool for this By far the highest, and unrecoverable if the requirement was imaginary.
Ongoing cost	A reason to choose it A subscription and a domain.	Fine, with a caveat Site plan plus seats; costs rise with editors and add-ons.	Fine, with a caveat Hosting, premium plugins, and a maintenance budget that is not optional.	Fine, with a caveat Subscription plus transaction fees plus apps. App creep is the cost to watch.	Fine, with a caveat Hosting plus a CMS subscription — often less per month than the equivalent stack of plugins.	Possible, but it fights you Hosting, database, auth, email, monitoring — plus an ongoing engineering relationship.
Vendor lock-in	Possible, but it fights you The design does not leave with you. A move means a rebuild.	Possible, but it fights you Content exports; the build does not. Leaving means rebuilding the front end.	A reason to choose it Open source. You can host it anywhere and nobody can raise the rent.	Possible, but it fights you Real, and usually worth it. Theme code and checkout do not come with you.	A reason to choose it Your code, your repository, portable hosting. The CMS is the replaceable part.	A reason to choose it Your code and your data. Managed services are swappable with effort.
Portability	Possible, but it fights you Content can usually be exported; layout and interactions cannot.	Possible, but it fights you CMS content is portable via CSV or API; layout is not.	A reason to choose it Database and files are yours; export paths are well-trodden.	Fine, with a caveat Products, customers and orders export cleanly; the storefront does not.	A reason to choose it Content exports via API; the front end runs anywhere that runs Node.	Fine, with a caveat Postgres and standard tooling travel well; managed-service specifics need planning.
Expertise required	A reason to choose it A capable non-developer can run it indefinitely.	Fine, with a caveat Editors need no skills. Building well requires someone who knows the tool properly.	Fine, with a caveat Easy to start, and needs a genuinely competent maintainer to stay safe.	A reason to choose it Merchants run stores unaided every day. Specialists are for theme and integration work.	Possible, but it fights you Requires a developer relationship for anything structural. That is the trade.	Wrong tool for this Needs continuous engineering. A business without that relationship should not be at this level.

Hosted builderFramer, Squarespace

Setup complexityA reason to choose it: Live in days. No environment, no build step, no hosting decision.
Ongoing maintenanceA reason to choose it: Nothing to patch. The platform updates itself.
Client editingA reason to choose it: Visual editing by anyone, published instantly.
SEO flexibilityFine, with a caveat: Metadata, sitemaps and redirects are handled; advanced control — hreflang, granular structured data, edge rules — varies and should be checked before committing.
PerformanceFine, with a caveat: Usually good out of the box; the ceiling is the platform's, and heavy animation or embedded scripts erode it quickly.
EcommercePossible, but it fights you: Fine for a handful of products. Not an operations platform.
AuthenticationWrong tool for this: Password-gating a page is not authentication.
Database / persistenceWrong tool for this: Collections hold content, not per-user records.
Custom workflowsWrong tool for this: No place to run business logic.
ScalabilityFine, with a caveat: Traffic scales fine. Page count and structural complexity are what break first.
Development costA reason to choose it: The lowest credible entry point for a professional site.
Ongoing costA reason to choose it: A subscription and a domain.
Vendor lock-inPossible, but it fights you: The design does not leave with you. A move means a rebuild.
PortabilityPossible, but it fights you: Content can usually be exported; layout and interactions cannot.
Expertise requiredA reason to choose it: A capable non-developer can run it indefinitely.

Visual CMSWebflow

Setup complexityFine, with a caveat: Days to weeks. Structuring collections properly is real design work.
Ongoing maintenanceA reason to choose it: Hosted and patched by the platform.
Client editingA reason to choose it: The Editor role lets marketing publish without touching layout.
SEO flexibilityA reason to choose it: Per-page control, redirects, canonicals, sitemaps and structured data are all exposed.
PerformanceFine, with a caveat: Good when built carefully; degrades with heavy interactions and third-party embeds.
EcommercePossible, but it fights you: Exists, but is not competitive with a dedicated commerce platform for real operations.
AuthenticationPossible, but it fights you: Member features exist; anything beyond gated content wants a real backend.
Database / persistencePossible, but it fights you: CMS collections, with item limits worth checking against your archive.
Custom workflowsPossible, but it fights you: Logic means third-party automation services, not code you control.
ScalabilityFine, with a caveat: Comfortable into the hundreds of items; plan the architecture past that.
Development costFine, with a caveat: Mid-range. Cheaper than custom, more than a builder.
Ongoing costFine, with a caveat: Site plan plus seats; costs rise with editors and add-ons.
Vendor lock-inPossible, but it fights you: Content exports; the build does not. Leaving means rebuilding the front end.
PortabilityPossible, but it fights you: CMS content is portable via CSV or API; layout is not.
Expertise requiredFine, with a caveat: Editors need no skills. Building well requires someone who knows the tool properly.

WordPressSelf-hosted, themed

Setup complexityFine, with a caveat: Fast to stand up, slow to make good. Theme and plugin choices decide the next five years.
Ongoing maintenancePossible, but it fights you: Core, theme and plugin updates are ongoing and non-optional. Unmaintained WordPress is the most commonly compromised software on the web.
Client editingA reason to choose it: Thirty years of editorial refinement, and a workforce that already knows it.
SEO flexibilityA reason to choose it: Complete control, with mature plugins. The constraint is discipline, not capability.
PerformancePossible, but it fights you: Achievable, but it is work: caching, image handling and plugin restraint. Plugin sprawl is the usual cause of a slow site.
EcommerceFine, with a caveat: WooCommerce is capable and puts you in charge of PCI posture, updates and uptime.
AuthenticationFine, with a caveat: Users and roles exist; membership plugins extend them. Security posture is yours to own.
Database / persistenceFine, with a caveat: A real database underneath, though the schema is WordPress's rather than yours.
Custom workflowsFine, with a caveat: Hooks and custom plugins can do genuine work — at the cost of maintaining that code inside someone else's release cycle.
ScalabilityFine, with a caveat: Scales with caching and infrastructure attention. Very large sites do run on it, with teams.
Development costA reason to choose it: Enormous supply of developers and themes keeps entry cost low.
Ongoing costFine, with a caveat: Hosting, premium plugins, and a maintenance budget that is not optional.
Vendor lock-inA reason to choose it: Open source. You can host it anywhere and nobody can raise the rent.
PortabilityA reason to choose it: Database and files are yours; export paths are well-trodden.
Expertise requiredFine, with a caveat: Easy to start, and needs a genuinely competent maintainer to stay safe.

ShopifyHosted commerce

Setup complexityA reason to choose it: A working store, with payments and tax, in days.
Ongoing maintenanceA reason to choose it: Platform, checkout and compliance are Shopify's problem. Apps are yours.
Client editingA reason to choose it: Products, collections and content in one admin the whole team can use.
SEO flexibilityFine, with a caveat: Solid, with known constraints — enforced URL prefixes and limited control over some generated pages.
PerformanceFine, with a caveat: Fast by default; app scripts are the usual reason a store stops being fast.
EcommerceA reason to choose it: Checkout, tax, fraud, payments, inventory and reporting — the whole surface, maintained for you.
AuthenticationFine, with a caveat: Customer accounts are built in. Not a general-purpose identity system.
Database / persistenceFine, with a caveat: Products, orders and customers, with metafields for the rest. Not a place for unrelated application data.
Custom workflowsFine, with a caveat: Flow, apps and functions cover a lot; genuinely unusual logic needs code beside the platform.
ScalabilityA reason to choose it: Handles traffic spikes and large catalogues without you thinking about it.
Development costA reason to choose it: Money goes into theme, product data and merchandising rather than plumbing.
Ongoing costFine, with a caveat: Subscription plus transaction fees plus apps. App creep is the cost to watch.
Vendor lock-inPossible, but it fights you: Real, and usually worth it. Theme code and checkout do not come with you.
PortabilityFine, with a caveat: Products, customers and orders export cleanly; the storefront does not.
Expertise requiredA reason to choose it: Merchants run stores unaided every day. Specialists are for theme and integration work.

Custom front end + CMSNext.js + Sanity

Setup complexityPossible, but it fights you: Weeks. Content modelling, front end and deployment are all real decisions.
Ongoing maintenanceFine, with a caveat: Dependencies need periodic updates, but there is no server to patch and a smaller attack surface than a plugin ecosystem.
Client editingA reason to choose it: Editors get a purpose-built model. Changing what a page type IS still needs a developer.
SEO flexibilityA reason to choose it: Total control: metadata, canonicals, hreflang, structured data, redirects, sitemaps, rendering strategy.
PerformanceA reason to choose it: You decide what ships to the browser, which is the only durable way to hold Core Web Vitals.
EcommerceFine, with a caveat: Correct as a storefront in front of Shopify. Building the commerce engine itself is a different project.
AuthenticationFine, with a caveat: Straightforward to add — but adding it means you are at Level 4, not Level 3.
Database / persistenceFine, with a caveat: The CMS is the database. Add your own only when something must persist per user.
Custom workflowsFine, with a caveat: API routes and scheduled jobs handle real logic without a full backend.
ScalabilityA reason to choose it: Static generation and edge delivery scale essentially without limit.
Development costPossible, but it fights you: The most expensive option that is not an application. Justified by traffic, page count or brand.
Ongoing costFine, with a caveat: Hosting plus a CMS subscription — often less per month than the equivalent stack of plugins.
Vendor lock-inA reason to choose it: Your code, your repository, portable hosting. The CMS is the replaceable part.
PortabilityA reason to choose it: Content exports via API; the front end runs anywhere that runs Node.
Expertise requiredPossible, but it fights you: Requires a developer relationship for anything structural. That is the trade.

Custom app + backendNext.js + Supabase

Setup complexityWrong tool for this: For a marketing site, this is the wrong starting point. For an application, it is the beginning of a project, not a launch.
Ongoing maintenancePossible, but it fights you: Dependencies, migrations, security patches and someone accountable when it breaks at 2am.
Client editingPossible, but it fights you: Content editing exists only if a CMS was deliberately included. Everything else is a deployment.
SEO flexibilityA reason to choose it: Complete control — though most of an application is behind a login and correctly not indexed at all.
PerformanceA reason to choose it: Yours to control, and yours to get wrong. Database queries become the thing that decides it.
EcommerceFine, with a caveat: Necessary only for selling models a commerce platform cannot express. Otherwise a large, avoidable cost.
AuthenticationA reason to choose it: The reason to be here. Accounts, roles, sessions and per-row access rules.
Database / persistenceA reason to choose it: A schema designed for your domain, which is the whole point of this level.
Custom workflowsA reason to choose it: Any rule, any schedule, any integration. Nothing is “not supported”.
ScalabilityA reason to choose it: Scales as far as the architecture and the database design allow.
Development costWrong tool for this: By far the highest, and unrecoverable if the requirement was imaginary.
Ongoing costPossible, but it fights you: Hosting, database, auth, email, monitoring — plus an ongoing engineering relationship.
Vendor lock-inA reason to choose it: Your code and your data. Managed services are swappable with effort.
PortabilityFine, with a caveat: Postgres and standard tooling travel well; managed-service specifics need planning.
Expertise requiredWrong tool for this: Needs continuous engineering. A business without that relationship should not be at this level.

The technologies, by layer

Grouping by architectural layer prevents the most common confusion in these conversations: treating tools that do unrelated jobs as if they compete. Stripe and Framer are not alternatives to one another. Supabase does not replace Shopify. Most real stacks pick one thing per layer and leave several layers empty — and an empty layer is a good result, not a gap.

Presentation — what the visitor sees

The interface itself. Every project has this layer; the only question is whether it is expressed in a visual editor or in code.

Framer: A hosted design tool that publishes a real site.; Small, design-forward sites where the team wants to edit visually and nothing needs a backend.
Webflow: A visual builder with a CMS behind it.; Marketing sites with repeating page types where the marketing team must own the pages.
React: The component library the custom work is written in.; Any interface built as code — which in practice means anything at Level 3 or above.
Next.js: The React framework: routing, rendering strategy, metadata, images, API routes.; Custom sites and applications where search, performance or application state matter.

Where this goes wrong: Choosing a framework before knowing whether the site needs one. Next.js is an excellent answer to questions a five-page brochure site never asks.

Content — where words and images live

Where editable content is stored and modelled. Needed the moment content changes on a schedule or by someone who is not a developer.

Built-in CMS (Framer, Webflow, Shopify): Collections inside the platform.; The site and the content live on the same platform, which covers most businesses.
WordPress: A mature CMS with a large editorial ecosystem.; Large editorial teams, an existing WordPress capability, or a genuinely useful plugin.
Sanity / headless CMS: Content as structured data, delivered by API.; A custom front end, or content that must feed more than one surface.
Markdown in the repository: Content as files, versioned with the code.; Developer-authored content — documentation, changelogs — where review through pull requests is a feature.

Where this goes wrong: Building a custom CMS. Editorial software is a solved problem, and a bespoke admin panel is worse on the day it ships than the thing you did not buy.

Commerce — catalogue, checkout, orders

Everything between a product existing and money arriving: variants, inventory, cart, checkout, tax, shipping, fulfilment, returns.

Shopify: Hosted commerce, including a checkout that is maintained for you.; Almost every store. The default until a specific requirement breaks it.
Shopify headless (Storefront API): Shopify's commerce engine behind a custom storefront.; The brand experience is a differentiator — while keeping Shopify's checkout.
WooCommerce: Commerce as a WordPress plugin.; Already committed to WordPress, modest catalogue, someone accountable for maintenance.
Custom commerce: Your own catalogue, cart and order model.; Contract pricing, rentals, configurators, marketplaces, or an ERP that must be the source of truth.

Where this goes wrong: Confusing “headless” with “custom checkout”. Headless commerce means you built the storefront. Rebuilding checkout is a separate, much larger and much riskier decision.

Data — what persists

Where records live when they must survive, be queried, and belong to someone. This layer is empty on most business websites, and that is the correct outcome.

PostgreSQL: The relational database almost every serious application ends up on.; Anything with users, records, history or reporting.
Supabase: Managed Postgres with authentication, storage, realtime and row-level security.; Applications that want a real database without running one — the usual choice at Level 4.
The CMS's own storage: Content, already stored and already queryable.; The content is the only thing that persists — which is most sites.

Where this goes wrong: Adding a database because the project feels like it should have one. If nothing is stored per user, this layer stays empty and the project stays cheaper to own.

Authentication — who is signed in

Identity, sessions and permissions. Introducing this layer is the single largest step up the ladder, because it brings responsibility for other people's data with it.

Supabase Auth: Accounts, sessions and access rules alongside the database.; You are already using Supabase and want access control enforced at the data layer.
Clerk / Auth.js: Dedicated identity providers.; Social sign-in, organisations, invitations or SSO are requirements.
Platform accounts (Shopify, Circle, a membership product): Someone else's login, someone else's liability.; The requirement is content or orders behind a login — which it usually is.

Where this goes wrong: Writing your own authentication. Sessions, resets, rate limiting, breach handling and privacy law are all in scope the moment you do, and none of it is where your product is different.

Payments — taking money

Processing money. Deliberately separate from commerce: taking a deposit is not the same problem as running a store, and conflating them is how businesses end up with a store they did not need.

Stripe: Payments, subscriptions, invoices, hosted checkout.; Deposits, service payments, subscriptions, or an application that bills — anywhere without a full catalogue.
Shopify Payments: Payments inside the commerce platform.; You are running a store; it is already there.
A payment link: A hosted page you send someone.; Occasional or one-off payments. The correct answer far more often than a checkout is.

Where this goes wrong: Building a store to take four payments a month. Stripe on a Level 1 site handles that for the cost of an afternoon and no ongoing platform fee.

Email — messages the system sends

Transactional mail: confirmations, receipts, password resets, notifications. Distinct from marketing email, and it must arrive.

Resend: Developer-focused transactional email with a real deliverability posture.; Any custom build that sends mail on its own.
Platform email: Whatever the builder or store sends already.; Form notifications and order confirmations on a hosted platform.

Where this goes wrong: Sending transactional mail from an inbox provider or an unauthenticated domain. Without SPF, DKIM and DMARC, password resets land in spam and nobody finds out until a customer complains.

Hosting and delivery

Where the site actually runs, and how quickly it reaches people.

The platform itself: Framer, Webflow and Shopify host what they build.; Levels 1 and 2. There is no hosting decision to make, which is a feature.
Vercel: Managed hosting for Next.js, with previews and edge delivery.; Custom front ends and applications, where deploy previews change how review works.
Traditional managed hosting: A server someone maintains.; WordPress. Choose a host that handles updates and backups, or budget for someone who does.

Where this goes wrong: Hosting in the agency's account. Whatever the stack, the hosting, domain and DNS should be in the business's own name — it is what makes every other decision reversible.

Measurement — knowing whether it worked

The layer that decides whether any of the others were worth it. Independent of the stack, and routinely the last thing anyone sets up.

Google Analytics 4: Traffic, sources and conversions.; Always, with consent handled properly.
Google Search Console: What the site is actually found for, and what Google cannot index.; Always. It is free, and it is the only first-party view of search.
Microsoft Clarity: Session recordings and heatmaps.; Diagnosing why a page that gets traffic does not convert.

Where this goes wrong: Analytics that measure sessions but not the enquiry. If the form submission is not a tracked event, the site cannot be improved on evidence and every argument about it becomes a matter of taste.

Source control and process

Where the code lives and how changes reach production. Only present from Level 3 up — and from there it is not optional.

GitHub: Version history, review, and the record of why things changed.; Any custom build. Also your insurance policy against a single point of human failure.
Preview deployments: Every change gets a URL before it is live.; Custom front ends — it changes review from a description into something you can click.

You need something only a device provides — offline use, push notifications, camera or location in the background.
Usage is habitual and frequent enough that the home-screen icon is worth the install friction.
Distribution through the app stores is itself the channel.

What to do instead

Build a fast, properly responsive site first. If installability is the only requirement, a progressive web app covers a surprising amount of it without two more codebases.

How we actually decide

Requirements pick the architecture — never the reverse

Every rung on the ladder is justified by a requirement or it is not justified at all. If nobody can name the requirement that needs a database, there is no database. This sounds obvious and is violated constantly, usually because the technology was chosen before anyone wrote the requirements down.

Integrating what exists and building it are different products

“Take bookings” can mean embedding the scheduling tool you already pay for, or building an availability engine with staff, resources and rules. Those are not two sizes of one job — they differ by an order of magnitude in cost, in time and in what you are responsible for afterwards. The same split applies to ordering, payments, logins and search. Asking which one you mean is usually the single highest-value question in a project.

Buy before you build, and be honest about which one you are doing

If an existing product does eighty per cent of it, the correct move is nearly always to run that product and build the missing twenty — or to change the process so the eighty is enough. Custom software earns its place when the process is the competitive advantage, not when it is merely unusual.

Count the second year, not the launch

Any of these approaches can be made to look good on launch day. The differences show up in year two: who can change a price without a developer, what breaks when a plugin updates, whether a redesign means a rebuild, and whether you can leave. Cheap to build and expensive to own is the most common bad trade in this market.

Own the accounts, whatever the stack

The domain, the DNS, the hosting, the analytics and the repository should be in your name, with your agency invited in. This is independent of every other decision on this page and it is the one that determines whether a technology choice is reversible. A stack you like on someone else's account is worse than a stack you tolerate on your own.

Prefer the boring layer

Postgres, a hosted CMS, a payment processor everyone already trusts. Novelty at the infrastructure layer buys almost nothing for a business website and costs a great deal when the interesting choice stops being maintained. Save the originality for the parts of the product your customers can see.

We build custom software, and this page still tells most readers not to buy it. That is not modesty — a business on the wrong rung becomes an unhappy client about eighteen months in, and we would rather lose the project than inherit that.

Common questions

What technology should I use for my website?

Choose the simplest architecture that reliably satisfies your actual requirements. For most businesses — contractors, consultants, clinics, restaurants, professional services — that is a hosted builder such as Framer or Squarespace, or a CMS-driven site on Webflow or WordPress. A custom front end with a headless CMS becomes justified when search is a primary channel and the page count is large. A backend and database become justified when users log in and see data that belongs to them. Full custom software is justified when the process itself is the product.

Is WordPress still a reasonable choice in 2026?

Yes, for a specific case: a content-heavy site with multiple editors, an existing WordPress team or agency, and a plugin that genuinely solves a requirement. It is a poor choice when nobody is accountable for updates, because the maintenance is real and the cost of neglect is a compromised site rather than an out-of-date one.

Do I need a custom website, or is a template fine?

A template is fine when the site's job is to be credible and explain what you do, and when nobody on the team is fighting the template to publish. It stops being fine when the structure you need does not exist in the template, when performance or search results are commercially material, or when the design has become indistinguishable from your competitors using the same theme.

Should I use Shopify or build a custom store?

Use Shopify unless something about how you sell genuinely breaks a normal store — per-customer pricing, rentals and returns, complex configurators, a marketplace with third-party sellers, or an ERP that must be the source of truth. Shopify's checkout, tax handling, fraud screening, payment compliance and hosting represent an enormous amount of work you would otherwise pay to rebuild and then maintain, and rebuilding checkout almost never returns the investment.

When does a business actually need a database like Supabase or Postgres?

When something must persist and belong to someone: user accounts, saved records, order history you control, uploaded documents, an application's state. A contact form does not need one — it needs an email. A blog does not need one — the CMS already has one. If nothing dynamic needs to be stored and retrieved per user, a database is machinery with no job.

Is Next.js overkill for a small business website?

Often, yes. Next.js earns its place when a site is large, when search is a primary acquisition channel, when content comes from a CMS or an API, or when the site will grow into an application. For a five-page site edited twice a year, a hosted builder gets you the same commercial result faster, and someone in your office can change the phone number.

How do I avoid being over-sold?

Ask which requirement makes each component necessary, and expect a specific answer. “You will need it later” is not a requirement. Ask what happens on the day you want to leave, who owns the accounts, and who can change a price without a developer. A studio that cannot answer those in plain language is quoting a stack rather than solving a problem.

Want this decided for your actual business?

The cost calculator asks the same kind of questions this page does — about your business rather than about technology — and returns a scope and a range from the model we use to price real work. If the answer turns out to be a hosted builder and no project, it will say so.

Use the cost calculator See published prices