Skip to content

Process

Six phases. No surprises in week nine.

Every engagement runs the same way. You always know what is happening now, what comes next, and what you get at the end of it.

  1. 01

    Discover

    Week 1–2

    We interview the people who will use the system every day, not only the people commissioning it, and audit whatever is running today. The goal is to find the real constraint before anyone opens a design tool.

    • Stakeholder interviews
    • Current-system audit
    • Scope document
  2. 02

    Design

    Week 2–6

    Research, information architecture and interface design, with the system architecture planned in the same weeks rather than after it. A screen the data model cannot serve gets caught here, while changing it is still free.

    • Flows and wireframes
    • High-fidelity UI
    • System architecture
  3. 03

    Develop

    Week 5–14

    Sprints with a review at the end of each one, so the first time you see the system is not the week it is due. Accessibility and performance are checked automatically on every commit rather than audited at the end.

    • Working software each sprint
    • API and schema
    • Test coverage
  4. 04

    Deploy

    Week 12–16

    Production launch with a zero-downtime strategy, and with backups and monitoring provisioned as part of go-live. Where an old system is being replaced, the two run side by side until the new one has earned the switch.

    • Production environment
    • CI/CD pipeline
    • Backup and rollback plan
  5. 05

    Manage

    Ongoing

    The subscription phase. Monitoring, security patching and bug fixes against a tiered SLA, through a support channel that reaches someone who knows your system rather than a queue.

    • SLA response times
    • Monthly security patching
    • Quarterly health report
  6. 06

    Scale

    Ongoing

    Feature and infrastructure expansion as the business grows: a second branch, a new department, a traffic profile nobody forecast. All of it planned against the same architecture, so growth stays a configuration change.

    • Capacity planning
    • Feature request pipeline
    • Infrastructure expansion

Principles

Four things we do on every project.

Most projects do not fail in week nine. They fail in week two, when nobody writes down what done means.

Numbers before pixels

Two or three metrics with current values, agreed by whoever owns the budget, before anyone opens a design tool. It is how scope gets decided and how we know when we are done.

A written “not doing” list

Scope gets cut on every project. We do it deliberately in week two and in writing, rather than silently in week nine.

Weekly reviews of rough work

Unfinished work, shown weekly, clearly labelled. Disagreements surface while they cost a day instead of a sprint.

Phases with real exits

Each phase ends with something usable on its own and a genuine option to stop. You keep everything produced up to that point.

Working together

We work inside your tools, not alongside them.

No client portal, no weekly status deck. We join the channels your team already uses and work where the work happens.

  • Slack

    Shared channel, we are in it daily

  • Figma

    Live files, no “final v3” exports

  • GitHub

    PRs your engineers review

  • Linear

    Or whatever you already use

Ready when you are

Two weeks from now you could have a validated scope.

Discovery starts with interviews and an audit. By the end of it you have a written plan, whether or not you continue with us.

Or email us directly at hello@uxatom.com