Process

How a project moves from idea to launch

Six stages take a project from discovery to a live system, each with a clear owner, a clear output and a typical duration you can plan around.

NDA on request · Free, no-obligation estimate · Reply within one business day

Two colleagues sketching a plan on a whiteboard, one holding a laptop

Overview

The stages, at a glance

  1. Discovery

    We learn your goals, constraints and existing systems before proposing an approach.

  2. Scoping and estimate

    Discovery becomes a written scope, a budget range and a delivery plan.

  3. UX/UI design

    Wireframes and interface designs are reviewed with you before any code is written.

  4. Build in two-week sprints

    Engineers build in fixed sprints, each ending with a working demo.

  5. QA and launch

    Testing, staging review and a planned release, not a surprise deploy.

  6. Support and iteration

    We stay on to fix issues, add features and monitor the system after launch.

In detail

What happens at each stage

Discovery

Discovery typically takes one to two weeks. We review existing systems, talk to the stakeholders who will use or maintain the software, and identify constraints such as compliance requirements, integrations and any deadline that shapes the plan. A senior engineer runs these conversations, not a sales representative, so technical trade-offs surface early.

  • A written summary of goals, constraints and open questions
  • A recommendation on approach, including where an existing tool might solve the problem instead of custom code

Scoping and estimate

Once discovery is complete, turning it into a scoped plan typically takes three to five days: a feature breakdown, a budget range, a delivery timeline and the assumptions the estimate depends on. Scoping is done by the engineer who will lead the build, working with a project lead who manages timeline and communication.

  • A written estimate with budget range, timeline and team composition
  • A list of assumptions and exclusions, so nothing is scoped by surprise later

UX/UI design

For projects that need new interfaces, design typically runs one to three weeks depending on the number of screens. A designer produces wireframes first, then high-fidelity screens in Figma, reviewed with your team before a single line of interface code is written. Backend-heavy projects scope this phase down or skip it.

  • Wireframes and high-fidelity screens in Figma, shared for comment
  • A component library covering the interface elements used across the product

Build in two-week sprints

The build is the longest phase, and its duration depends on scope: typically a few sprints for a focused feature, longer for a full platform. Work happens in two-week sprints, each ending with a working demo. Engineers and a project lead are involved throughout, with a QA engineer joining once there is enough built to test.

  • A working demo at the end of every sprint
  • A written update each week covering what shipped, what is in progress and any blocker

QA and launch

QA typically runs alongside the build rather than only at the end, with a dedicated pass of one to two weeks before launch covering scenarios automated tests do not reach. Launch itself is planned: a staging environment, a rollback plan and a defined release window, coordinated with whoever on your side needs to know.

  • A staging environment you can review before launch
  • A release checklist and rollback plan for launch day

Support and iteration

After launch, support typically continues on a retainer or as-needed basis: fixing issues, monitoring the system and building the next round of features. The same engineers who built the system usually stay on, since they already know the codebase and the decisions behind it.

  • A support arrangement scoped to the response time you need
  • Continued access to the engineers who built the system

Communication

Cadence and tools

You are never waiting on us to find out how a project is going. A short written update goes out every week, a working demo happens every two sprints, and the tools below are shared with you for the life of the project rather than reserved for internal use.

  • Async updates in Slack or Microsoft Teams, wherever your team already works
  • Tasks tracked in Jira or Linear, visible to you throughout the sprint
  • Code hosted on GitHub or GitLab, with every change reviewed before it merges
  • Designs shared and reviewed in Figma
  • A written update every week and a working demo every two sprints

Quality

Practices we do not skip under deadline pressure

  • Code review on every pull request before it merges
  • Automated tests run in continuous integration on every change
  • A staging environment that mirrors production for review before release
  • Accessibility checks against WCAG 2.2 for client-facing interfaces

Scope

How change requests are handled

Scope changes are normal on any real project. When a request falls outside the current sprint's plan, we estimate the additional time and cost before starting, and you decide whether it goes into the next sprint or waits. Nothing outside the agreed scope is built, or billed, without that conversation happening first.

FAQ

Process FAQs

How long does a two-week sprint actually take to show results?

You get a working demo at the end of every sprint, so results are visible every two weeks rather than only at the end of the project. Some sprints ship a complete feature; others complete groundwork a later sprint builds on.

Can our team join sprint planning and demos?

Yes. Sprint planning, demos and standups are open to anyone on your side who wants to attend, and the tools we use, such as Jira or Linear and Slack or Teams, are shared with you for the duration of the project.

What happens if we need to change scope partway through a project?

We estimate the change, tell you what it adds to timeline and cost, and wait for your decision before starting it. Change requests go through the same review as any other work; nothing extra is built or billed without that conversation.

Do you provide a staging environment before launch?

Yes. Every project gets a staging environment that mirrors production, so you can review the working system before it goes live rather than seeing it for the first time in production.

Who is involved in QA before launch?

Automated tests run in CI on every change throughout the build, and a dedicated QA pass in the one to two weeks before launch covers scenarios that automated tests do not reach, such as edge cases and cross-device checks.

Get a plan for your project

Share what you are building and we will map it to these stages with a realistic timeline and budget range.

Get a free project estimate