What is web development?

Before the tech stack is discussed there are a number of fundamental decisions. They separate one web project from another more than which stack is chosen:

1. 01Build vs buy. Build the site ourselves, hire an agency, or run on a SaaS platform. Trade-offs are about ownership, flexibility, time-to-market, and total cost over lifetime.
2. 02CMS vs custom. WordPress or Webflow give quick start and a low entry threshold. Custom builds give flexibility and ownership but require more competence in operations and maintenance.
3. 03Ownership vs convenience. Open-source CMS gives maximum ownership but requires your own operational work. Proprietary SaaS gives shorter time-to-market but locks you into the vendor.
4. 04Hosting model. Self-hosted, managed hosting, or serverless. Cost, control, and scalability are trade-offs.
5. 05Time-to-market vs future flexibility. Quick templates solve the now but limit tomorrow. Custom builds take longer but set no future limits.

Decision support, not status. What we see in the network is that most web projects that fail do not fail on the tech choice. They fail because the fundamental decisions were made implicitly, without all stakeholders understanding what they meant.

Once the fundamental decisions are made, the tech-stack choice follows as a consequence. There are no universally right choices. Here are the trade-offs for the common alternatives:

• WordPress: quick start, large ecosystem, easy to find developers. Best for content-heavy sites with moderate customization. Trade-off: security maintenance and plugin bloat over time.
• Webflow: visual builder with professional output. Best for marketing sites where design flexibility matters more than content scale. Trade-off: SaaS lock-in, less control on the server side.
• Shopify: e-commerce platform with quick start. Best for standard e-commerce flows. Trade-off: transaction fees, less flexibility outside the Shopify ecosystem.
• Next.js↗ or similar JavaScript framework: maximum flexibility and performance. Best for complex applications, headless architecture, or high-traffic sites. Trade-off: requires a development team for operations.
• Sanity, Strapi, or another headless CMS: separates content management from presentation. Best when content is used in multiple channels or when the presentation needs to be swappable without touching content. Trade-off: two-system complexity.

The tech choice should confirm the business decision, not steer it. A CMS-driven site with limited customization can be exactly right for a SaaS company that needs to focus on the product. A custom-built Next.js platform can be wrong for a smaller company that needs to iterate content quickly. Strategy leads, specialists deliver. The tech choice follows.

Performance is not a technical question. It is a business KPI. Google's guide to Core Web Vitals and business impact↗ shows that load time directly affects bounce rate and conversion. Every extra second of load time can cost bounces and lost revenue. Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift) are Google's formalized measurement points for perceived performance. They affect both ranking and conversion.

• LCP (Largest Contentful Paint): how quickly the page's main content appears. Should be under 2.5 seconds.
• INP (Interaction to Next Paint): how quickly the page responds to user input. Should be under 200 milliseconds.
• CLS (Cumulative Layout Shift): how stable the layout is when the page loads. Should be under 0.1.

Performance work is business work. It is not about passing Lighthouse tests for Google's sake. It is about visitors staying, scrolling, and converting. A site that takes 4 seconds to load loses visitors before they have seen what you are selling. Performance budgets must be there from the site's fundamental decisions, not added as optimization at the end.

Accessibility (a11y) is not a nice-to-have. The EU's European Accessibility Act made accessibility a legal requirement from June 2025 for many digital services. The WCAG guidelines↗ are the international reference framework. A11y is also a business decision: an inaccessible site excludes part of the population from shopping, reading, or converting.

• Keyboard navigation: the entire site should work without a mouse
• Screen reader support: semantically correct HTML, alt text on images, ARIA attributes where needed
• Color contrast: minimum 4.5 to 1 for normal text against background
• Focus indication: visible focus rings during keyboard navigation
• Structured headings: an H1 to H6 hierarchy that matches the document's logic

A11y work is often easier to build in from the start than to retrofit. What we see in the network (years of collective experience building and reviewing sites) is that inaccessible sites typically get built by agencies that did not have a11y as a default spec. An a11y audit on a finished site often reveals 50 to 100 issues. Building from scratch with a11y as a requirement is not more work. It is the same work, done correctly from the start.

Not all web-related problems are web development problems. A site that converts poorly may have a web development root cause, or not. Before you call a web agency, ask where the problem actually sits:

• It is web work if: the site is technically weak (load time, mobile rendering, fundamental UX errors), the structure blocks conversion, or the platform limits what you need to do going forward.
• It is CRO work if: traffic converts poorly and the problem lies in copy, hypotheses, or funnel flow rather than the site's fundamental structure.
• It is SEO work if: the right audience does not find you. Web development can be a prerequisite for SEO (technical foundation) but is not SEO.
• It is copy work if: the message does not meet the audience's situation. A beautiful site with the wrong words does not convert.

The dividing line is not exact. In practice web projects are often mixed. A relaunch can require web development, SEO migration, copy iteration, and CRO work in parallel. Understanding which discipline solves which problem separates a successful project from a scattered one. If this points to your situation, see how Memorise works with web.