Skip to content
cube4devcube4dev

Theses · Development time instead of feature scope

Anyone who changes priorities in the middle of development is not planning badly. They have learned something.

In the weekly model, new insights may shift priorities. If a better direction becomes visible, we respond immediately.

That is not a lack of planning: much product information only emerges during real development.

In detail

PRODUCT DEVELOPMENT BY THE WEEK

The week model follows from this logic. The collaboration does not begin with an attempt to fix a long-term scope of features completely. It begins with a concrete product idea or technical question and a clearly bounded development period.

Before the development week

We clarify which question promises the greatest value, in insight or in product terms, given the current state. What matters is not the longest feature list, but the question whose technical clarification improves the next entrepreneurial decision.

That may be a coherent vertical slice of an application, the core of a new software architecture, a demanding operating concept, a simulation, a visual working environment, or a first complete product core.

During the development week

Development is focused. New insights can change the priorities. If an approach turns out to be weak, or a better direction becomes visible, we can respond immediately.

This flexibility is not a lack of planning. It is a deliberate consequence of the fact that relevant product information can only arise during real development.

At the end of the development week

The state of development reached is there to be seen. On that basis it is decided whether to develop further, go deeper, change course or stop.

What is booked is development time. Not a scope of features defined in advance, and not a particular contractual result.

ONE WEEK · 4,900 € NET

Every further week is agreed separately. There is no automatic continuation.

PRODUCT DEVELOPMENT BY THE WEEK →

More theses