Everything we do to build marketing sites and products that are fast, measurable, SEO-ready, and accessible, written out in full. How we scope, how we choose the stack, how we enforce performance budgets, how analytics gets wired in from day one, and how the engagement runs from audit to launch. No fluff, no secrets held back.
This guide is long because the decisions that determine whether a site performs, ranks, and converts are made early, before any code is written. Most of them are also invisible to the people paying for the build, which is how you end up with a beautiful site that scores 38 on Lighthouse and has no analytics tracking what happens after someone clicks the hero CTA. What follows is how we think about each of those decisions, in the order we make them.
Scoping is a diagnostic exercise, not a sales one. The output of a good scoping process is a document precise enough that the people doing the work cannot misread what is in and what is out, and clear enough that the people paying for it know exactly what they will have at the end of each sprint. Anything vague in a scope is a future dispute waiting to happen.
We scope in three passes. The first pass is the free technical audit: what exists now, what is wrong with it, and what the constraints are. The second pass is a written brief that covers the deliverables, the acceptance criteria for each, the target performance budgets, the analytics events we will track, and the launch criteria. The third pass is the sprint plan: the work broken into two-week windows, with each window ending in something you can test and approve.
Estimating follows naturally from the brief. If the brief is precise, the estimate is precise. If it is not, we do not guess; we ask the questions that make it precise before any money changes hands. That is how you avoid the classic pattern where a fixed-price project turns into a series of change orders because the original scope was a paragraph of marketing copy.
What goes in a scope document. Deliverables by page type and component, acceptance criteria per deliverable, performance budgets (LCP, CLS, INP targets), analytics events and destinations, third-party integrations, browser and device support, accessibility standard (WCAG 2.1 AA by default), deployment environment, and handover documentation. If it is not in the scope, it is not in the price.
Estimates are in time ranges, not single numbers. We give a best-case and a realistic case, explain what drives the difference, and build the sprint plan from the realistic case. Padding a project with artificial buffer is not honest; telling you a five-week project will take three is not helpful either.
Every engagement opens with a technical audit of what you already have, because the most expensive thing in web development is building in the wrong direction. The audit answers two questions before any scope is written: what is actually wrong with the current site or build, and what would fixing it be worth?
The audit covers five layers:
The output is a written report with every finding categorised by impact (critical, high, medium, low), the specific URL or component where it occurs, and the fix. We walk through it on a short call and you keep the report whether or not you engage us.
Stack choice is a constraint-matching exercise. The right stack is the one that fits the content model, the team's skills, the performance requirements, and the growth trajectory. It is not the newest framework, not the one the lead developer likes most, and not the one that produces the most impressive demo.
The main decision is whether the site is static, server-rendered, or a full client-side application, and whether a CMS is involved. Here is the practical breakdown:
| Approach | Best for | Trade-offs |
|---|---|---|
| Static site (HTML, CSS, minimal JS) | Landing pages, low-change marketing sites, documentation | Fastest possible load, simplest hosting; not suitable for dynamic content or authenticated features |
| Static site generator (Eleventy, Hugo, Astro) | Content-heavy sites with infrequent updates, blogs, knowledge hubs | Excellent performance floor, pairs well with headless CMS; build time grows with content volume |
| Server-rendered framework (Next.js, Nuxt, SvelteKit) | Marketing sites with personalisation, product pages, e-commerce | Strong SEO by default, flexible rendering strategies; more infrastructure to manage |
| Headless CMS plus frontend | Sites where non-technical teams publish content frequently | Best separation of concerns; adds a dependency and a monthly cost for the CMS platform |
| Full product (SPA or server-rendered app) | Authenticated product features, dashboards, tools with state | Most flexibility; highest complexity, longest build, needs careful SEO treatment for public-facing pages |
The choice between a static site generator and a server-rendered framework is the one teams get wrong most often. If the site is mostly marketing content with infrequent updates and no personalisation, a static generator will outperform a server-rendered framework every time and cost far less to host and maintain. We recommend a framework when the content is dynamic, the team needs per-user rendering, or the site needs to grow into product features over time.
We make this recommendation in writing as part of the scope, with the reasoning and the trade-offs, so the decision is explicit and documented. We do not push a particular stack because it is what we know best; we push the one that fits the problem.
A performance budget is a set of constraints agreed in writing before the first line of code is committed. Without one, performance is always sacrificed for features because the cost of adding a third-party script or an unoptimised image is invisible until someone runs Lighthouse and finds a score of 42.
We work to three Core Web Vitals thresholds from Google:
fetchpriority="high". Fixing the hero image alone moves most sites from failing to passing LCP.Performance budget enforcement. We set Lighthouse CI thresholds in the deployment pipeline so any commit that regresses a Core Web Vitals score blocks the deploy until it is fixed. This prevents the slow degradation that turns a fast site into a slow one over twelve months of feature additions.
Beyond the three Core Web Vitals, we budget total page weight, JavaScript bundle size, number of render-blocking resources, and the number of third-party scripts allowed on performance-critical pages. Each one is written into the scope so everyone working on the project knows the constraint before they propose adding something that would break it.
Third-party scripts deserve special attention. Analytics, chat widgets, A/B testing tools, and marketing pixels are each individually small; collectively they routinely add two to four seconds to load time and introduce layout shifts. We use a facade pattern for non-critical tools: load a lightweight placeholder that only loads the full script when the user interacts with it. The chat widget loads when the user clicks the chat button, not on page load.
An SEO-ready build is not a checklist you apply at the end. It is a set of structural decisions made before any content is written. The biggest mistake teams make is building a site, launching it, and then asking an SEO consultant to fix the problems, at which point fixing them means reworking the underlying architecture rather than adding a meta tag.
Every page needs a single H1, a logical heading hierarchy (H2 for sections, H3 for subsections), landmark elements for navigation, main content, and footer, and descriptive alt text on every image. These are the things Googlebot and screen readers both depend on to understand the page, and they cost nothing to get right the first time.
Googlebot can render JavaScript, but it does so in a second wave that can take days for pages that are not already authoritative. For public-facing pages that need to rank, server-side rendering or static generation is safer than a client-side-only application. If your product is a single-page application, the marketing and landing pages should be statically rendered even if the authenticated product is not.
We ship structured data on every page type from day one, using the types that match the content. The rollout follows a standard map:
| Schema type | Where it goes | What it unlocks |
|---|---|---|
| Organization | Sitewide (usually in the footer or head) | Brand knowledge panel, logo in search results |
| BreadcrumbList | Every page with a navigation hierarchy | Breadcrumb trail in the search result |
| WebSite plus SearchAction | Homepage | Sitelinks search box on branded queries |
| FAQPage | Pages with a genuine FAQ section | Expandable FAQ accordion in the result |
| Article | Blog posts and guides | Publication date, author, and enhanced indexing |
| Product | Product or pricing pages where applicable | Price and availability in the result |
| SoftwareApplication | SaaS product pages | Rating and platform data in the result |
Every structured data block is validated with Google's Rich Results Test before launch and monitored in Search Console after. Invalid schema is worse than no schema: it produces a manual action warning if Google finds it misleading.
Every page needs a self-referencing canonical tag pointing to its preferred URL. If the site has multiple language or locale versions, every page needs a full set of hreflang annotations, including a self-referencing hreflang and an x-default. Missing or incorrect hreflang is one of the most common and most expensive mistakes on international sites: Google often indexes the wrong language version for each market, which splits the ranking signals and dilutes authority across versions.
Titles stay under 60 characters. Meta descriptions stay under 155. Both are written before launch, not auto-generated from the first sentence of body copy. They are the first thing a searcher sees in the result and they determine whether anyone clicks, regardless of ranking position.
Accessibility is not a compliance exercise. It is a build quality standard. A site that is inaccessible to keyboard users has broken navigation for power users. A site with low colour contrast fails in sunlight, not just for users with visual impairments. A site without proper ARIA labels is harder for Google to parse, not just harder for screen reader users.
We work to WCAG 2.1 AA on every build. The practices that matter most in a typical marketing site or product build:
Automated testing catches roughly 30 to 40 percent of WCAG violations. The rest require manual testing. We run automated scans on every commit using axe-core, and we do a manual keyboard and screen reader check on each page type before launch.
Analytics is almost always an afterthought in web builds. The site launches, someone adds Google Analytics via a CMS plugin, and three months later the business has no idea what is actually driving conversions because the events were never set up to answer the questions that matter.
We set up analytics before the first sprint ends, with events mapped to the business questions, not to what is easy to track. The setup follows a brief written during scoping:
On measurement and privacy. We implement analytics in compliance with GDPR and ePrivacy requirements: consent management before any tracking fires, anonymised IP by default, data retention settings reviewed at launch, and no personally identifiable information in event parameters. Getting this right from the start is far cheaper than retrofitting a compliant consent layer onto a site that has been tracking everything for twelve months.
After launch, we run a tracking QA pass: every event fires on the correct trigger, no duplicate events, no missing events, and the data in the analytics platform matches the expected user behaviour. This takes half a day and prevents months of working from bad data.
A component system is the difference between a site that stays consistent as it grows and one that develops twelve slightly different button styles across seventeen pages because each was built independently. It is also the difference between a site where a non-technical team can publish new content safely and one where every new page requires an engineer to copy-paste markup and hope they do not break anything.
We build every site with a documented component library. The scope covers which components are needed and what variants each requires. The implementation covers three things:
For marketing sites, we build the component system in whatever framework is specified in the scope, or in plain HTML and CSS for static sites. For product builds, we default to a headless component pattern where the visual layer is separated from the business logic, so the design system can be updated without touching application code.
The CMS choice is a workflow decision, not a technology decision. The right CMS is the one that lets the people who will actually update the site do so without filing a ticket, breaking the layout, or needing to understand the codebase.
The main options we work with and when we recommend each:
CMS migrations deserve their own attention. Moving content from one platform to another is almost always messier than it looks: redirects for URLs that change, content that does not map cleanly to the new schema, images that need re-uploading, and SEO metadata that needs to be preserved. We plan migrations in the scope, build the import scripts before touching the live site, and verify every redirect before launch day.
A modern marketing site or product typically connects to five to fifteen external services by launch: analytics, CRM, email marketing, customer support, payment processing, form handling, and whatever the product itself needs. Each integration is a potential failure point, a performance risk, and a privacy surface. We treat them with the same rigour as the application code.
The integration checklist we run before any third-party service is added:
Form handling is a common area where things go wrong. We use a server-side handler or a form service (Formsubmit, Netlify Forms, or a serverless function) rather than exposing an email address or a transactional email API key in the client. Honeypot fields, rate limiting, and reCAPTCHA are standard; the choice between them depends on the volume of submissions and the sensitivity of the data.
For product builds with their own API, we write an API contract before any frontend or backend code is written. The contract covers endpoints, request and response shapes, authentication, error codes, and pagination. Frontend and backend development can then proceed in parallel against the agreed contract, rather than sequentially, which is how you keep sprint velocity up in a product build.
Security in a marketing site or product build is not glamorous, but the basics are non-negotiable. The mistakes that cause breaches are almost always the obvious ones: secrets exposed in client-side code, no Content Security Policy, dependencies with known vulnerabilities, and no HTTPS enforcement.
The security checklist we run before launch on every engagement:
Hosting is where performance, reliability, and security all come together. The hosting choice should follow from the stack choice: a static site does not need a server; a server-rendered application does. Choosing the wrong hosting for the stack leads to unnecessary complexity and cost.
For static sites and sites built with static site generators, we default to a CDN-first host (Netlify, Vercel, or Cloudflare Pages). Every page is served as a pre-built file from an edge location close to the visitor, with no server round-trip for the initial HTML. Load times that would take two to three seconds from a single-region server drop to under half a second from a CDN edge. The cost difference between a CDN host and a server is often zero for the traffic volumes that startups and scaleups run at.
For server-rendered applications and product builds, we evaluate the infrastructure requirements against the expected traffic and budget. A small product with a few thousand users per month does not need a Kubernetes cluster; it needs a well-configured VPS or a managed platform like Railway or Render with sensible autoscaling settings.
Every deployment pipeline we set up includes preview environments: isolated, publicly accessible deployments of every pull request or branch, with a unique URL that is generated automatically. Preview environments let the whole team (designers, writers, QA, founders) review and approve changes before they merge to main. They also let us catch regressions before they reach the live site, because the preview runs the same build as production.
The deployment pipeline runs on every commit to the main branch: build, lint, unit tests, Lighthouse CI check against the performance budgets, and deploy. If any step fails, the deploy is blocked. This is not optional; it is how you prevent the slow accumulation of technical debt that turns a performant site into a slow one.
The build that ships at launch is not the build that runs in two years. Scaling a site or product is mostly about the decisions made early: a component system that makes it easy to add pages consistently, a CMS that lets non-technical teams publish without engineering support, a dependency list that does not grow without governance, and a codebase that new engineers can navigate without a three-day orientation.
The practices that most affect maintainability in the long run:
The real cost of technical debt in a web build is not the code that needs to be replaced. It is the time spent working around code that nobody understands but everyone is afraid to touch. The best time to prevent it is during the initial build. The second best time is a focused technical debt sprint, which we can scope separately if the codebase has already accumulated it.
Every engagement follows the same structure: audit, scope, build in sprints, launch, and handover. The structure is the same whether we are building a landing page or a full product; the size of each phase scales with the scope.
The phases in order:
Because we run growth and SEO work for the same companies we build for, the handover can transition into an ongoing engagement or stay as a one-time project. Either is fine. The site we build is yours, the code is yours, and the documentation is written so you can run it independently.
How long does a typical project take? A landing page is typically four to six weeks from scope sign-off to launch, including content, QA, and deployment. A full marketing site is eight to twelve weeks. A product build depends on scope but we structure it in fixed two-week sprints so you see working software at the end of each one.
Do you work with our existing stack? Yes, if the audit tells us the current stack is sound. We recommend a change only when the current one is a genuine constraint on what you need to do, and we explain the reasoning before any work starts.
What does it cost? The audit is free. The build is scoped after the audit because the right scope depends on what we find and what you want to ship. We write the scope and the price into the agreement before any work begins.
Can you handle SEO and growth after the build? Yes. We run SEO, content, and link building for the same companies we build sites for. The build we ship is already SEO-ready; the growth work runs on top of it. There is no handoff to a different agency.
What if we need changes after the project is scoped? Changes that are outside the agreed scope are scoped as a separate item with a separate price, before any work on them starts. We do not absorb unscoped changes silently and then invoice for them at the end.
That is the full method. When you want it applied to your site or your next build, the next step is a free audit: real findings on your real Lighthouse and field data, in about a week, with no obligation.
A free technical audit of your site or build. Real findings on your real Lighthouse and field data. A fixed scope to fix what matters. Findings in a week.
Get a free site audit