How we work

The Schtelbe model

Six steps, two benches of people on every one of them, and a price agreed after the analysis rather than before it.

Start a project

Why it exists

Most software fails before anyone writes code

A custom system rarely fails because the engineering was poor. It fails because the thing being built was specified by people who understood software but not the business, or by people who understood the business but had no idea what software could reasonably do.

The Schtelbe model is our answer to that. It puts both kinds of people in the room from the first conversation and keeps them there until the system is in use - and it holds back the commercial commitment until there is enough understanding on the table to make it mean something.

The principle

Two benches, on every project

Every Schtelbe project is staffed from both at once. Neither one hands work to the other and walks away.

Bench one

IT specialists

The people who build the thing: mobile developers, RPA engineers, integration and dashboard work. They decide what is technically possible, what it will cost to maintain, and what should not be built at all.

Bench two

Industry experts

Recognised specialists from the industry the software is for - people who have run the warehouse, the call centre, the production line or the finance function themselves. They decide whether the thing being specified is the thing the business actually needs.

More than 23 experts, with backgrounds at Apple, Microsoft, Google, Amazon, UiPath, Citadele, Luminor and Riseba.

The model

Six steps

You are involved in four of them. Each one ends with something you can hold, read or test - not a status update.

  1. Step01

    Goal definition

    We discuss what you need and define the target. Not a feature list - the business outcome the software is supposed to produce, stated plainly enough that we can later tell whether it happened.

    You end up with: a written target.

    Schtelbe You

  2. Step02

    Prototype visualisation

    Analysis and evaluation, then a visualised concept. This is where the industry expert earns their place: the concept is reviewed by someone who has done the job the software is meant to support, before a line of it is committed to.

    You end up with: a concept you can look at and argue with.

    Schtelbe Experts

  3. Step03

    Contract signing

    Budget, technical scope and deadlines are confirmed together, and then the contract is signed. This is deliberately the third step and not the first. You are not asked to commit to a number before anyone understood the problem - the figure you agree to is attached to a defined piece of work.

    You end up with: a price, a scope and a date, all agreed at once.

    Schtelbe You

  4. Step04

    Development

    The build, with follow-ups. The expert who reviewed the concept stays reachable through it, so questions that come up mid-build are answered by someone who knows the business rather than guessed at by someone who does not.

    You end up with: working software, and regular sight of it.

    Schtelbe

  5. Step05

    Project testing

    Testing and correction - including by the people who will actually use it daily, not only by us. What they find is fixed before rollout rather than logged for later.

    You end up with: a tested system and a list of what changed.

    Schtelbe You

  6. Step06

    Implementation

    Rollout, with a guarantee. Going live is treated as part of the project rather than the end of it - the measure of success is the system being used, not the system being delivered.

    You end up with: a system in use, under guarantee.

    Schtelbe You

What it is for

Three ways a project goes wrong

The wrong thing gets built

Everyone agrees, everyone signs off, and the result solves a problem nobody had.

Answered at steps 1 and 2, by having someone from the industry review the concept before it is committed to.

The price moves

A number agreed before the analysis is an estimate of an unknown, and it moves once the work is understood.

Answered at step 3, by agreeing budget, scope and deadline together - after the analysis, not before it.

It ships and nobody uses it

The system is delivered, the project is closed, and the old spreadsheet quietly stays in use.

Answered at steps 5 and 6, by testing with the people who will use it and treating rollout as part of the project.

Thinking about a project?

Step one is a conversation about what you are trying to achieve. Projects start from €15,000.

Contact us