Value-driven
system development.
Software has long carried the risk of getting built. Even with enormous effort, there is no guarantee value follows. This study reimagines system development from the side of value.
actually possible?
The current situation —
an era where building itself is the risk.
System development was meant as a means of producing value. But in the structure that has prevailed for so long, building itself has become a business risk.
Building itself is the largest risk.
Features, effort, headcount — development demands enormous resources, and the feasibility itself amplifies the uncertainty of a business. Whether a thing can be built has come to decide a business's fate.
Even when built, the economics don't hold.
Systems that succeed technically often fail to be rewarded in business or economic terms. Between value and cost lies a structural disconnect.
Redesigning development from the side of value.
Rather than first deciding what to build, first define the value to be produced. Working backward from there, we redesign the relationship itself between developer and customer.
Recomposing the relationship.
From the old structure of order → delivery → sell-and-done, toward a structure of value definition → co-creation → usage fees. The developer's economics become tied to value itself.
Order → deliver
→ sell-and-done
Fix the spec, quote, deliver, end.
Developer and value separate at the moment of delivery.
Toward the side of value.
Origin is not what is built,
but the value that is produced.
Value definition → co-creation
→ usage fees
Customer and developer share responsibility for producing value.
The relationship continues as long as the value does.
Our hypothesis, at the present time.
Automation of development by AI, and a value-first relationship. When these two are combined, how does the economy of software change?
Development automation lowers the developer's burden,
and repeating customer feedback raises usage and LTV.
When development is nearly automated, a developer can participate in much more value with much less effort. With repeating customer feedback, the product gets used and LTV grows. — We believe this structure can simultaneously hold the sustainability and economics of the developer.
Two things to verify.
Beautiful hypotheses are not research until tested. We confirm the two below through real-world partnerships.
Sustainability,
on the developer's side.
Within the cycle of automation and co-creation, can a developer keep engaging long-term — without burning out and without losing creativity? We verify this on three axes: time, body and mind, and relationships.
The economics.
Does the usage-fee model actually work? Do the assumed unit price and timing align with reality? Can the economy be rational for both developer and customer?
From the field where systems are built
and businesses are sharpened.
We are now seeking early business partners for this study — companies wanting to build a new internal system, and companies wanting to fundamentally streamline existing operations. We welcome operators and executives ready to launch — together, in the field — the first cases of design that begins from value, from the question rather than from requirements.