Have Software Built by the Week

PRODUCT DEVELOPMENT BY THE WEEK

FOCUSED DEVELOPMENT TIME. MOVING PRIORITIES. DECIDED WEEK BY 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.

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

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.

If you do not own the source code after a software project, you have rented software.

SOURCE CODE. CONTINUITY. CONFIDENTIALITY.

The collaboration is designed for technical independence.

After payment in full, the client receives the project-related source code of the state of development produced, together with the project files relevant to further work, insofar as these are part of the development and can be transferred in law.

The state of development is intended to be continued by the client themselves or by third parties.

Confidential business and technical information is treated as confidential.

There is no strategic tie to a proprietary development platform belonging to CUBE4DEV.

You buy development time and receive the project state that comes out of it.

If all you need is more developer hours, I am the wrong choice.

The approach is particularly suited to companies in which substantial product ideas exist whose potential has not yet been sufficiently clarified.

That may be a new standalone application, a digital product, a specialised domain system, a simulation, a visualisation environment, a complex interactive tool, or a significant software extension to an existing product.

The model makes particular sense where a real technical state of development promises more insight than further abstract planning, and where the product idea is still flexible enough to respond to new findings.

It is less suitable where a fully specified scope of features is to be bought at a fixed contractual price, where a large development team is needed, or where the aim is merely to add development resources to an existing organisation.

The approach is not aimed at implementing existing IT tasks as cheaply as possible. It is aimed at product ideas where technical development can make new entrepreneurial options visible.

WHICH IDEA SHOULD WE TRY FIRST?

The longest feature list is the worst start for a new product.

Not every relevant product idea needs a large project straight away.

Often a precise question is enough to begin with: which product idea should be brought to a real technical level before a larger investment is decided? Which application so far exists only as a concept? Which technical possibility is interesting enough not to be discussed in theory any longer?

A development week can be the beginning of a larger product. It can equally provide the basis for deliberately not pursuing an idea, or for developing it in another direction.

The first step does not have to determine the whole product. It has to make the next decision better.

ONE WEEK · 4,900 € NET

Example projects

Ask about this