Skip to content
How we work

Our software development process,
from first message to shipped.

Every Asauvia engagement follows six stages — discover, design, build, validate, launch and improve — with an overlap window agreed at kickoff and progress visible in a shared backlog. You review the plan before we build and choose an engagement model: fixed scope, dedicated team, or time and materials (or a retainer).

Process

Six stages.
Always in this order.

See each stage in detail
stage-01.md
01 / 06

Discover

Scope the real problem and constraints on a short call.

Stage 01 of 06
Each stage in detail

What happens at each process stage,
and what you get.

Each stage ends with something concrete you can review, not just a status update.

  1. 01

    Discover

    We start with a short call to understand the real problem, not just the requested feature. We ask about your users, existing systems, constraints and what success looks like. An NDA is signed before any confidential detail is shared.

    What you get

    • A written scope summary of the problem and constraints
    • Open questions and assumptions, listed so you can correct them
    • A recommended engagement model
  2. 02

    Design

    We work out the architecture and the delivery plan, and document the key decisions up front. You review the plan before anything is built, so disagreements surface on paper rather than in code.

    What you get

    • An architecture document with the decisions and their reasons
    • A delivery plan broken into backlog items
    • Your review of the plan before build begins
  3. 03

    Build

    We deliver in increments against a backlog you can see. Every change goes through code review, and dependencies are reviewed as they are added. You follow progress through the backlog and updates on the cadence agreed at kickoff.

    What you get

    • Working increments you can try as the build progresses
    • A shared backlog showing what is done, in progress and next
    • Code that has passed review, with dependencies checked
  4. 04

    Validate

    Nothing ships without passing testing and review gates. For web work, Core Web Vitals budgets are enforced in CI, so a performance regression fails the build instead of reaching your users.

    What you get

    • Test and review results for the release
    • A release that has passed those gates before it goes live
  5. 05

    Launch

    We deploy with monitoring and a rollback path in place from the first release. If something behaves unexpectedly in production, there is a known way back.

    What you get

    • A deployed release with monitoring in place
    • A documented rollback path
  6. 06

    Improve

    After launch we measure the result against the goal agreed in discovery, then decide with you what to change next. Some engagements end here; others continue as ongoing product work.

    What you get

    • A review of the release against the original goal
    • A ranked list of next improvements
    • A recommendation on whether and how to continue
Engagement models

Three engagement models.
Chosen to fit the work.

We recommend a model after the scoping call, based on how defined the work is and how long it is likely to run.

Fixed scope

When it fits
Well-defined projects where requirements are clear before work starts.
Scope and change
Scope is agreed in writing before build. Changes are discussed openly and handled as an agreed change to scope, not absorbed silently.
Not suited for
Work where the requirements are still being discovered.

Dedicated team

When it fits
Ongoing product work where you need consistent capacity and people who know your system.
Scope and change
Priorities are set through the shared backlog. You reorder work as your needs change, and the team picks up what matters most next.
Not suited for
A one-off project with a clear end point.

Time and materials or retainer

When it fits
Work that evolves as you learn, such as early-stage products, integrations with unclear edges, or continued improvement after launch.
Scope and change
Scope stays flexible by design. Work is planned in the backlog and reviewed with you, so you can change direction as you learn.
Not suited for
Buyers who need a single fixed figure agreed before work begins.

What affects cost

We do not publish a rate card because cost is driven by the work itself. The main factors are scope and uncertainty: how clearly the requirements are defined, how much integration with your existing systems is involved, and how much of the build is genuinely new rather than an established pattern. We scope this with you before any work starts, so the proposal reflects your project rather than a generic package. See the product engineering, custom software development and AI software development service pages for what each one covers.

Time zones and communication

Working across time zones,
with status you see without asking.

Distance only becomes a problem when information is hard to get. We set up the working rhythm with you at kickoff and keep progress visible from there.

A head start for Western teams

Our team works India Standard Time, which runs ahead of business hours in the US, UK and Europe and overlaps with much of Asia-Pacific. For Western teams, work started during our day is often ready before yours begins.

Overlap and cadence agreed with you

At kickoff we agree an overlap window for live conversation and a communication cadence that suits your team.

A shared backlog

The backlog is visible to your team, so you can see what is done, in progress and next at any time.

A standing update cadence

Updates arrive on the cadence agreed with you, so decisions and context do not depend on catching someone live.

How to start

Three steps to start a project,
from first message to proposal.

The proposal recommends an engagement model. You decide whether and how to go ahead.

  1. 01

    Send us a message

    Tell us what you are building, improving or automating through the contact form.

  2. 02

    Short scoping call

    We talk through the problem, constraints and goals. An NDA is signed first if you need to share anything confidential.

  3. 03

    Proposal

    You receive a written proposal covering the approach and a recommended engagement model.

Process questions

Questions about our process,
answered before you get in touch.

Do you have a rate card or fixed price list?

No. Every engagement is scoped with you before work starts. Cost depends mainly on scope and uncertainty: how defined the requirements are, how much integration with existing systems is needed, and how much of the work is genuinely new.

Which engagement model should we choose?

Fixed scope suits well-defined projects, a dedicated team suits ongoing product work, and time and materials or a retainer suits work that evolves. We recommend a model in the proposal after the scoping call, and you decide.

How will we know what is happening during the build?

You get access to a shared backlog and updates on a cadence agreed at kickoff. Status is visible to you at any time rather than reported only when you ask.

How do you handle working across time zones?

Our team works India Standard Time, which runs ahead of business hours in the US, UK and Europe and overlaps with much of Asia-Pacific. We agree an overlap window and a communication cadence with each client at kickoff.

Who owns the code and other work product?

Intellectual property in the work product is assigned to you on delivery or payment. Access to your systems and data is limited to the people on the project for the duration of the engagement.

Let's solve
something together.

Tell us what you're building, improving, or automating. We'll come back with a plan, not a pitch.

NDA before any scoping conversation