Skip to content
MOITOITECH
EET--:--:--
SUN--:--

Build · Scale Sprint

Scale in. Scale out.

Two weeks. One difficult problem. Senior hands-on attention.

Find the real constraint, make something move, and leave the system easier to own.

Start a Scale Sprint

Fit

For a problem that is stuck, fragile, or unclear.

You do not need to arrive with the diagnosis. Bring the operation, the people around it, and what is not moving.

  • Something keeps failing

    An incident or recurring reliability problem keeps pulling the team away from product work.

  • The next move is unclear

    A migration, integration, performance issue, or technical decision is blocked on evidence.

  • The work spans disciplines

    The constraint may be in a database, infrastructure, product workflow, or the hand-off between them.

  • You need work, not a report alone

    The sprint is hands-on: investigate, decide, build or fix, test, and transfer what was learned.

This is not staff augmentation or a bucket of hours. Another sprint needs its own reason and outcome.

Method

Sail in. Stay long enough to understand. Sail out.

The two-week minimum gives enough time to see what actually happens, not just what a diagram or ticket says.

  1. 1. Sail in

    Learn the product, people, architecture, constraints, and history. No assumed answer on arrival.

  2. 2. Stay and explore

    Follow evidence into code, data, infrastructure, product, or workflow. The original problem may not be the real one.

  3. 3. Build

    Fix, prototype, automate, deploy, test, simplify, migrate, or validate the highest-value next step.

  4. 4. Sail out

    Leave the result, decisions, residual risks, and handover clear. Do not manufacture dependency.

Outcome

A concrete change and a clear next decision.

The finish line is agreed around the problem, not a generic deliverables list.
  • The relevant system or workflow has been investigated with evidence.
  • The highest-value agreed change has been built, fixed, tested, or validated.
  • Deployment, rollback, or recovery considerations are recorded where relevant.
  • Known residual risks and the next owner are clear at handover.

Proof

Mervare shows how the work goes.

It is Andres’s own product: inspect the product decisions, delivery gates, live directory, and what is still only a pilot or in development.
Mervare's public harbour map

The case study shows problem discovery, technical and product decisions, AI-assisted execution, and explicit limits on claims.

Andres has worked in production engineering since 1995 and studied Business Administration and Management part-time at EBS from 2021 to 2026. This is professional background, not an endorsement or a promise to copy large-company architecture into a small product.

His technical background includes Kubernetes, MySQL/TiDB, AWS, Terraform, and observability. These are supporting capabilities, not separate offers or employer endorsements.

Read the Mervare case study