The VIA method.

A clear route, in three steps, to a finished tool.

Three steps, three decisions.

At the end of each step you know what you have in hand, and you choose to go on or to stop there.

  1. View

    We look at how your team really works and what slows it down. This is the diagnostic: we map how your work flows and spot what is worth changing.

    What you get
    A prioritized roadmap: 3 concrete workstreams, ranked by impact. For each one: the problem, the solution, the estimated effort, the expected gain and the risks. All of it readable by a non-technical person.
    Your decision
    You keep the roadmap, and you choose which workstream to start, or none.
    See the diagnostic in detail
  2. Imagine

    We draw the tool, its scope and its price before writing any code.

    What you get
    A described tool, a defined scope and a fixed price.
    Your decision
    You approve the tool, its scope and its price, or you stop there. No code is written before that.
  3. Assemble

    We build and deliver what was drawn.

    What you get
    The tool drawn in the previous step, built and put into service.
    Your decision
    After delivery you choose: carry on by yourselves, or hand us the follow-up (maintenance and evolution), as an option.
    See the follow-up plans

Why the route comes first.

The route is there so you decide before you spend.

  • Drawn before it is built.

    The tool, its scope and its price are fixed before the first line of code. You know what will be built, and at what cost, before we start.

  • We tell you what is not worth doing.

    The roadmap sets aside the attractive ideas that don’t hold up. If nothing is worth doing, we tell you.

  • The roadmap stays with you.

    You keep it either way, whether or not you start a workstream with us.

  • You decide at every step.

    Nothing moves on without your approval: at the end of each step you carry on or stop, with what you have in hand.

Where the name comes from.

The name comes from the via ferrata, the equipped mountain routes whose line and anchor points are set before the climb. The method applies that idea to a software project: the route is fixed before we build, and each step ends at a point where you can stop.

First the route, then the tool.

Start where the route starts.

The diagnostic tells you what is worth building, and in what order.

Book my diagnostic