How We Scope and Ship a Project: Our Technical Process End to End

Most dev shops describe their process in vague terms: “agile methodology”, “collaborative approach”, “iterative delivery”. This tells you nothing about what actually happens between your first conversation and your site going live.

This post is the unvarnished version. Here’s exactly how we run a project, with the reasoning behind each step.

Phase 1: Discovery and Scoping (Days 1–3)

Before we write a line of code, we need to understand three things:

What does the system need to do? (functional requirements)
What constraints exist? (timeline, budget, existing tech, team capabilities)
What does success actually look like? (KPIs, user outcomes — not just “a website”)

We run a single 90-minute discovery call to cover all three. We come prepared: we’ve already reviewed your existing site or product, your competitors, and any materials you’ve sent. The call is structured around specific questions, not an open-ended chat.

After the call, we produce a scoping document — not a proposal. There’s a difference. A proposal is a sales document. A scoping document is a technical document:

Project: Audeze Shopify Overhaul
──────────────────────────────────
Scope:
  ✓ Theme architecture refactor (Liquid + custom JS)
  ✓ Product filtering system (AJAX, no page reload)
  ✓ Fulfilment API integration (ShipBob → Shopify webhook)
  ✓ Performance optimisation (target: LCP < 2s on mobile)

Out of scope:
  ✗ New product photography / content
  ✗ Email marketing integration (Klaviyo — separate engagement)
  ✗ App development

Timeline: 4 weeks
Fixed price: £X,XXX

The out-of-scope list is as important as the in-scope list. It’s how we prevent scope creep — and how we protect you from paying for work you didn’t ask for.

Phase 2: Architecture Decisions (Days 3–5)

With scope defined, we make framework and infrastructure choices. These decisions are documented before coding starts, and we explain the reasoning.

A typical architecture decision record (ADR) looks like this:

## ADR-001: Frontend Framework

**Decision:** Astro with static output, deployed to Vercel CDN

**Context:** Marketing site with weekly content updates. No authenticated
routes. SEO is a primary concern.

**Alternatives considered:**
- Next.js: adds ~180kb JS runtime and SSR overhead for no benefit here
- Plain HTML: lacks templating and component reuse for a site of this size

**Consequences:**
- Build time: ~2s locally, ~12s on Vercel CI
- Deployment: static files, no serverless functions required
- Maintenance: any developer familiar with HTML/CSS can maintain templates

We write one ADR per significant decision: framework, database, authentication approach, third-party service choices. By the time we start coding, every major decision is written down and you’ve approved it. There are no surprises mid-project.

Phase 3: Development (Week 1–3)

We work in one-week sprints with a fixed structure:

Monday: Sprint planning. We define exactly what ships by Friday and assign ownership.

Wednesday: Mid-week check-in (30 minutes). You see what’s been built, flag anything that looks wrong before it compounds.

Friday: Sprint review. We demo what shipped. You give feedback. We update the backlog for next sprint.

The Wednesday check-in is the most important meeting. It’s where we catch misalignments early — before they become expensive rework.

Code quality standards we apply to every project

No direct commits to main. Every feature goes through a pull request with a description of what changed and why.

PR: Add product filtering system

Changes:
- FilterBar component (Liquid): renders facets from metafields
- filter.js: AJAX request to Shopify Search & Discovery API
- Debounced input: 300ms delay to prevent API spam
- URL state: filters update query params for shareable links

Testing:
  ✓ Tested on Chrome, Firefox, Safari (desktop + mobile)
  ✓ No JS fallback: filter form submits to /search as standard GET

TypeScript everywhere. Even in Shopify Liquid projects, our custom JavaScript is TypeScript compiled to ES2020. Type errors surface at build time, not in production.

Performance budgets. Before a page ships, we run Lighthouse CI against it. If it scores below our agreed threshold (typically 90+ on performance), it doesn’t merge.

# .lighthouserc.yml
ci:
  assert:
    assertions:
      "categories:performance": ["error", {"minScore": 0.9}]
      "categories:accessibility": ["error", {"minScore": 0.9}]
      "first-contentful-paint": ["error", {"maxNumericValue": 2000}]
      "largest-contentful-paint": ["error", {"maxNumericValue": 2500}]

Phase 4: Staging Review (End of Week 3)

Before anything goes to production, the complete build lives on a staging URL for 3–5 business days.

During staging review:

You (and your team) test against real content
We run a cross-browser matrix: Chrome, Firefox, Safari, Edge — desktop and mobile
We test against real network conditions (throttled 4G) using Chrome DevTools
We run a full accessibility audit (keyboard navigation, screen reader, colour contrast)

Feedback from staging is categorised:

Category	Handling
Bug (something broken)	Fixed before go-live, no discussion
Revision (looks/feels wrong)	Fixed before go-live under unlimited revisions policy
New feature (out of scope)	Logged for Phase 2 — not blocked, not rushed in

The “new feature” category is key. Scope creep kills timelines. We’re strict about what constitutes a revision vs. a new feature — but we’re equally strict about not charging for revisions on agreed scope.

Phase 5: Production Deployment

Go-live is planned, not improvised. For most projects:

DNS changes scheduled for a low-traffic window (typically Sunday 22:00–02:00)
Old site preserved at a subdomain (old.domain.com) for 30 days
Vercel deployment promoted from staging to production
Post-deploy smoke test: every page, every form, every critical user journey
Monitoring confirmed (Vercel Analytics + any agreed error tracking)

We stay available for 48 hours post-launch for any hotfixes. Not “available by email” — available on Slack, responding within the hour.

Phase 6: Handoff and Ongoing Relationship

At project close, we deliver:

Codebase on GitHub with a documented README covering local setup, deployment, and content management
Architecture overview doc explaining key decisions and how to extend the system
Content management guide (if applicable) for non-technical team members
30-minute handoff call walking through the codebase with whoever will maintain it

Most of our best client relationships don’t end here. They move to a monthly retainer — a fixed block of hours for maintenance, feature work, and the occasional late-night “something broke” message.

We don’t disappear after go-live. The developers who built your product know it better than anyone else, and that knowledge has value. We’d rather keep working with you than hand you over to someone who has to start from scratch.

If this sounds like the kind of process you want behind your next project, let’s talk.