· 6 min read · process · engineering · web development
A detailed walkthrough of how Ten Peaks Tech takes a project from initial brief to production deployment — including how we handle scope, architecture decisions, code review, and handoff.
Ten Peaks Tech
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.
Before we write a line of code, we need to understand three things:
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.
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.
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.
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}]
Before anything goes to production, the complete build lives on a staging URL for 3–5 business days.
During staging review:
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.
Go-live is planned, not improvised. For most projects:
old.domain.com) for 30 daysWe stay available for 48 hours post-launch for any hotfixes. Not “available by email” — available on Slack, responding within the hour.
At project close, we deliver:
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.
Keep reading
· 9 min read
A practical comparison of React and Next.js — covering SSR vs SPA tradeoffs, performance, deployment complexity, and real project examples to help you choose the right tool.
· 5 min read
A technical breakdown of how Astro's island architecture, content collections, and build pipeline make it the right default for most production web projects.
A senior engineer replies within one business day.
