Skip to content
cube4devcube4dev

Theses · Development time instead of feature scope

A fixed price for a new product is a bet that you know in advance what you only learn while building.

A fixed price requires a fully defined scope of features. With new products, however, that is exactly what only becomes clear during development.

That is why I sell development time: one week, with no scope defined in advance and no automatic continuation.

In detail

What a development week can achieve

A development week is not a unit of measurement for a fixed number of features. Software products differ too greatly in complexity, starting position and technical dependencies for that.

With suitable tasks, however, a coherent application system can emerge within short development cycles: with a real user interface, domain core logic, a data model, visualisation and a solid technical structure.

With complex desktop, real-time or visualisation systems, a week can produce a vertical slice that does not contain every later feature, but holds enough real architecture and functionality to make central product decisions.

Where the technical foundations are already well understood, the scope can reach considerably further.

Where there are research, integration or performance risks, by contrast, clarifying a single critical technical problem can hold the greatest economic value.

The scope is not standardised. The standard is: as much solid product reality as possible in as short a development time as possible.

What a development week can achieve →

More theses