arlo/eng

~/process

// process

Five phases.
Written down.

Discover, Architect, Build, Validate, Operate. Each phase has named activities, named artifacts, and a cadence both teams sign off on. No mystery meetings, no surprise invoices.

start a project→view services

// phases

Each phase, in detail.

// phase 00

00wk 1–2

Discover

Stakeholder interviews, technical audit, analytics teardown. We surface the real constraints — political, technical, financial — before we make promises.

// activities

  • 018–12 stakeholder interviews across product, engineering, design, and ops
  • 02Technical audit: stack, perf, accessibility, SEO, security posture
  • 03Analytics teardown with named instrumentation gaps
  • 04Competitor + heuristic review on the routes that matter

// artifacts

  • +Opportunity register, scored by effort and impact
  • +Risk register with mitigations
  • +90-minute readout + working session

// cadence

your team
2 hrs / week of stakeholder time
our team
1 strategist · 1 senior engineer, full-time

// sample

Surfaced a checkout regression hidden behind A/B-test pollution — fix shipped in week 3, recovered $640k ARR.

anonymized · representative

// phase 01

01wk 2–4

Architect

Information architecture, content models, technical blueprint, performance budgets. Written so a new engineer can ship inside a week. We commit to constraints in writing before code begins.

// activities

  • 01Information architecture and content modeling
  • 02Technical RFC: stack, data flow, hosting, edge strategy
  • 03Performance budget per route (LCP, CLS, INP, JS bytes)
  • 04Design system foundations (tokens, primitives, motion language)

// artifacts

  • +Signed RFC with explicit non-goals
  • +Migration plan with rollback gates
  • +Design system seed in Figma + Storybook

// cadence

your team
2 review sessions, written feedback in 48 hours
our team
1 architect · 1 designer · 1 engineer

// sample

RFC accepted by a 40-person product org in one review — zero rework once we entered build.

anonymized · representative

// phase 02

02wk 4–12

Build

Two-week increments, deployed continuously. You see real software in week one, not a deck. Every PR ships behind a flag with a preview URL — your team can poke it before it's real.

// activities

  • 01Sprint planning every other Monday with written goals
  • 02Trunk-based development, preview deploys per PR
  • 03Pairing sessions with your engineers (knowledge transfer is non-optional)
  • 04Demo every Friday with a written changelog

// artifacts

  • +Working software in production behind feature flags
  • +Storybook coverage for every shipped component
  • +ADRs (architecture decision records) for every non-obvious choice

// cadence

your team
1 PM, 1 designer reviewer, 30 min standup 2× week
our team
2–4 engineers · 1 designer · 1 PM

// sample

Shipped a logistics dashboard in 11 weeks. Median TTI dropped 2.7s. Zero P1 incidents in first 90 days.

anonymized · representative

// phase 03

03wk 10–14

Validate

Accessibility audit, Lighthouse pass, conversion experiments, load testing. We don't ship vibes — every change ships with an instrumentation plan and a reviewable result.

// activities

  • 01WCAG 2.2 AA audit with prioritized remediation
  • 02Core Web Vitals diagnosis and fixes (field + lab)
  • 03Load testing against realistic traffic curves
  • 04Pre-launch experimentation plan with hypotheses and MDEs

// artifacts

  • +Audit reports (a11y, perf, SEO, security)
  • +Test suite with coverage thresholds enforced in CI
  • +Launch checklist signed off by both teams

// cadence

your team
1 final stakeholder review, 1 go/no-go meeting
our team
1 engineer · 1 QA · 1 analyst

// sample

DTC migration: LCP 3.4s → 1.1s on mobile, +18% checkout completion in eight weeks.

anonymized · representative

// phase 04

04ongoing

Operate

Observability, on-call rotation, dependency hygiene, quarterly roadmaps. The relationship begins at launch — most agencies treat launch like the finish line. We treat it like Monday morning.

// activities

  • 0124/5 on-call with defined SLOs and incident review
  • 02Monthly dependency, security, and performance hygiene
  • 03Quarterly roadmap workshops aligned to your OKRs
  • 04Continuous deployment with automated rollback

// artifacts

  • +Public runbook + incident post-mortems
  • +Monthly transparency report: what shipped, what's next
  • +Quarterly roadmap deck with prioritization rationale

// cadence

your team
1 hr / month roadmap, async otherwise
our team
1–3 engineers retained · fractional design

// sample

Fintech client: 99.99% uptime across 18 months, 240+ deploys, zero rollback incidents in Q4.

anonymized · representative

// principles

Six rules we don't bend.

01

Write the constraint down.

Performance budgets, accessibility targets, and non-goals live in the RFC. If it isn't written, it isn't real — and we won't be the ones to relitigate it in week 8.

02

Ship in week one.

The first deploy goes out before the first invoice. Working software collapses arguments faster than any deck.

03

Senior people, on the keys.

Every engagement is staffed with engineers who've shipped the thing before. No bait-and-switch from sales pitch to delivery team.

04

Instrument before you optimize.

Every meaningful change ships with measurement. We'd rather have a slow page with honest data than a fast page we can't defend.

05

Boring tech, on purpose.

TypeScript, Postgres, the platforms you can hire for. We pick stacks for fit, not for the conference talk.

06

Hand the keys back.

Your team owns the codebase from day one. Pairing, ADRs, runbooks — by handoff, your engineers have shipped to it themselves.

// tooling

How we run the engagement.

// communication

  • Slack Connect
  • Linear
  • Loom
  • Notion

// engineering

  • GitHub
  • Vercel / Cloudflare
  • Storybook
  • Playwright

// observability

  • Sentry
  • Datadog
  • PostHog
  • Statuspage

// delivery

  • 2-week sprints
  • Trunk-based dev
  • Preview deploys
  • Friday demos

// faq

Things teams ask before kickoff.

  • 01

    Q. How rigid is the timeline?

    The phases are sequenced, but they overlap on purpose. Validate often starts before Build is finished — that's the point of shipping in week one. We'll commit to milestone dates, not a Gantt chart.

  • 02

    Q. What if our internal team can't keep up with reviews?

    We'll flag it in week one and propose a lighter-weight review cadence. Slipping reviews kill projects more often than missed deadlines.

  • 03

    Q. Do you use Agile / Scrum / Shape Up?

    We use whichever vocabulary makes sense to your team. Mechanically: 2-week sprints, written goals, demo every other Friday, retro every fourth.

  • 04

    Q. Can we onboard our own engineers mid-engagement?

    Yes — and we encourage it. Pairing, ADRs, and weekly knowledge-transfer sessions are part of the engagement, not an extra.

  • 05

    Q. What happens if you find something worse than we described?

    We tell you in week one, in writing, with options. Discovery exists to surface this before scope is locked.

// 09 — engage

Don't rent a team.
Own an engineering partner

Tell us what your business needs its digital platform to do. We'll respond within one business day — with a senior engineer, not a sales script.

start a conversation→hello@arlo.eng

// engagement

platform engineering · min 6 mo

// response_time

< 1 business day

// accountability

one team · one platform · one outcome