From value hypothesis to a product you can evaluate.
CoRISE engagement
Working with the client and product manager, CoRISE explored the value hypothesis, UX and requirements, contributing proposals and questions as specifications evolved. We built the SaaS product from scratch, covering the application, infrastructure as code, CI/CD and a PoC environment on AWS Fargate.
- React
- FastAPI
- OpenTofu
- Nix
- Docker
- GitHub Actions
- AWS ECS / Fargate
01 / PRODUCT
Participation in product definition
Joined the client and product manager in deciding what to build, from the value hypothesis through UX and specifications.
02 / ENGINEERING
Application design and development from scratch
Designed the application and architecture around the product hypothesis to be evaluated.
03 / DELIVERY
Delivery through an evaluable PoC
Combined IaC, CI/CD and ECS / Fargate to connect specifications to a system people could use and assess.
Challenge
Work together to establish what to build.
An early value hypothesis does not translate directly into software requirements. Who experiences the value, in which situation, and through which actions? The interaction, data and constraints needed to support that experience must be made concrete.
We worked with the client and product manager to clarify UX and requirements, feeding technical feasibility and operational conditions back into the specifications.
CoRISE contributed to shaping specifications from the value hypothesis as well as implementing them.
↔ Scroll horizontally to see the full diagram.
View diagram as text
The left is a comparison model: a one-way handoff from client and product manager to CoRISE, then to product and engineering decisions. The right illustrates this engagement: adjacent elements are connected in both directions, showing continuing conversation and feedback.
Product development loop
Develop product decisions through implementation and evaluation.
Value hypothesis, UX, requirements, specifications, architecture, implementation and PoC evaluation influence one another. CoRISE participated throughout this work in continued dialogue with the client and product manager.
↔ Scroll horizontally to see the full diagram.
View diagram as text
Eight elements form a cycle: value hypothesis, user and UX, requirements, specification, architecture, implementation, PoC and feedback. Feedback returns to the hypothesis. The central client, product manager and CoRISE labels indicate shared participation across the work. This is a conceptual view of the development relationships.
Approach
Connect product decisions with engineering decisions.
PRODUCT
Product decisions
- Value hypothesis
- Usage scenarios and UX
- Requirements and specifications
- Discussion with the client and product manager
- Questions and proposals
ENGINEERING
Engineering realization
- React / FastAPI implementation
- Application architecture
- Nix / Docker development environment
- GitHub Actions CI/CD
- OpenTofu infrastructure configuration
- AWS ECS / Fargate deployment and PoC operation
↔ Scroll horizontally to see the full diagram.
View diagram as text
UX decisions shape application behavior. Architecture decisions and product constraints influence one another. Operational constraints inform specification revisions. The diagram separates these three relationships.
Architecture and delivery
Build the PoC as a real system people can evaluate.
Application code, the development environment and infrastructure configuration formed one reproducible delivery path. Nix and Docker supported development, GitHub Actions delivered the application, and OpenTofu configured the AWS ECS / Fargate runtime.
We treated the application and its infrastructure as one connected system, from development through PoC operation.
↔ Scroll horizontally to see the full diagram.
View diagram as text
Product and UX decisions inform the React and FastAPI application, delivered through GitHub Actions to AWS ECS / Fargate. Nix and Docker support development and builds; OpenTofu configures the AWS runtime. The result is an evaluable, operated PoC environment. This is a conceptual view of the components and delivery path.
Development from scratch
Design the product structure around its value hypothesis.
The engagement began with an evolving product hypothesis rather than an existing packaged product or fixed implementation specification. We translated that hypothesis into domain behavior, UX, application structure, infrastructure and an operating environment.
Building from scratch meant designing for the hypothesis under evaluation, using established technologies such as React and FastAPI to assemble the structure the product needed.
Outcome
Make the idea usable, evaluable and ready to inform the next decision.
Value hypotheses and UX decisions developed with the client and product manager informed the application, architecture and infrastructure.
Our scope extended through building and operating the PoC environment, making the concept available as a system people could use and evaluate. That created a basis for feeding findings into subsequent specification and implementation decisions.
↔ Scroll horizontally to see the full diagram.
View diagram as text
Hypothesis leads to a working product, use, evaluation and the next decision. A return arrow connects the next decision to the hypothesis, showing how evaluation can inform subsequent development.
Scope of continuity
Maintain continuity across the boundaries of each stage.
We connected value-hypothesis exploration, design, implementation, delivery infrastructure and PoC operation, carrying findings back into earlier decisions. The diagram illustrates that continued participation.
↔ Scroll horizontally to see the full diagram.
View diagram as text
Discover covers the hypothesis and problem; Design covers UX, requirements and specifications; Build covers application design and implementation; Integrate covers infrastructure, IaC and CI/CD; Operate covers deployment and PoC operation. Forward arrows and separate return arrows between neighboring stages represent progress and revision.
Related insight
Connecting business knowledge to design decisions.
Architecture Notes