Skip to content
Mobile Byte Sensei

How an engagement runs.

Three stages: Discovery sprint, Build engagement, and Hold and improve. Each has a stated duration, billing basis and output, and each produces work the client owns.

Request a proposal View services

Written response within one week. No preliminary sales call.

Three engagement models.

Duration, billing basis and terms are stated before work begins. Most engagements proceed through them in order, and each can be the last.

Best for
For a defined problem where the shape of the build is not yet known.
Duration
2–3 weeks
Billing
Fixed fee
Included
  • Stakeholder and user interviews
  • Technical feasibility review
  • Scoped plan with a costed estimate
  • Clickable prototype of the core flow
Terms
Fee is credited against a build engagement that starts within 90 days.

Indicative, not a quotation.

Each stage in detail.

What each stage delivers, what it requires from the client, and where it most often goes wrong.

  1. Discovery sprint

    2–3 weeks · Fixed fee

    For a defined problem where the shape of the build is not yet known.

    Questions precede the estimate. The sprint establishes what the product must change, what already exists, and which constraints are real rather than assumed. Engineers take part, so nothing is designed that has not been checked for how it will be built.

    You receive

    • A written scope stating what is in and what is explicitly out
    • An estimate expressed as a range, with the assumptions behind it
    • A written risk register
    • A build plan in two-week increments

    Required from you

    • Access to the people who understand the domain
    • Existing research, analytics or support records
    • A decision-maker with authority to approve scope
    • One named reviewer with final say on design

    Where this stage goes wrong

    Without access to the people who understand the domain, an estimate is guesswork; in that case we state so rather than produce one. Design by committee is the other common cause of overrun.

  2. Build engagement

    3–9 months · Monthly retainer

    A dedicated team delivering working software in two-week increments.

    Work proceeds in two-week increments, each ending in a build that can be installed and used rather than a percentage or a status deck. If an increment ends without a runnable build, the client is told first.

    You receive

    • The repository, in the client’s organisation, from the first commit
    • Test coverage on the paths that carry money or data
    • Screen designs for every state, including empty, loading and error

    Required from you

    • Attendance at the demo by a product decision-maker
    • Timely answers on product decisions
    • Third-party credentials the build depends on

    Where this stage goes wrong

    Scope added mid-build is the one change that reliably moves the date. It is priced rather than absorbed, so the trade-off remains the client’s decision.

  3. Hold and improve

    Rolling · Monthly retainer

    After launch, for products that must remain operational and continue to improve.

    Launch, monitoring and the first weeks of real traffic, which is when a product establishes what it actually is. Release is treated as the midpoint of the work, not its conclusion.

    You receive

    • Crash reporting, analytics and alerting, configured and watched
    • A runbook the client’s team can operate independently
    • A recorded handover session

    Required from you

    • Store and infrastructure accounts held in the client’s name
    • A decision on continued operation after launch

    Where this stage goes wrong

    App review rejections are routine and usually cost days rather than weeks. Submission plans allow for them from the outset.

Reporting cadence.

An engagement fails quietly, through silence, long before it fails visibly. This schedule prevents it.

Reporting during a build engagement.
FrequencyReport
WeeklyDemo and written statusProgress, blockers and the decisions taken.
Every two weeksWorking buildInstalled on the client’s devices, not shown as a screen recording.
MonthlyBudget and burnSpend to date, remaining budget and what it purchases.
On adverse newsImmediate noticeNot held for the next scheduled update.

Between these, the team is reachable on a shared channel during the client’s working day. There is no ticket queue and no account manager relaying messages to the engineers building the product.

Commitments that hold at every stage.

Every stage hands over work the client owns, so an engagement can end after any of them without loss.

  • Each stage can be the last.

    Every stage produces work the client owns and can take elsewhere. A discovery sprint yields a plan any competent team could build from.

  • The estimate follows the questions.

    An estimate given before scoping is a guess presented as a commitment. Estimates are issued after discovery, as a range with stated assumptions.

  • Continuity, start to finish.

    A named lead is accountable for the engagement from scoping to release. The people who scope the work stay involved in building it, and there is no rotation to balance utilisation.

  • Adverse news is reported first.

    Problems are reported in the next written status, not held for the next milestone.

Begin with a discovery sprint.

2–3 weeks, fixed fee. Fee is credited against a build engagement that starts within 90 days.

Request a proposal

Or write to hello@mobilebytesensei.com