Functional spikes
Small working implementations created to test one technical assumption.
LABS / EXPERIMENT TYPE 02
Rapid Experiments.
Build enough to learn. Not enough to pretend it is finished.
We create small, time-bounded experiments around risky assumptions so teams can learn before turning uncertainty into a full production roadmap.
When the biggest risk is still an assumption.
Rapid experiments reduce uncertainty by isolating the thing that could change the direction, then testing it without building the rest of the product around it.
Start with
the uncertainty.
- A product idea needs evidence before a larger build.
- A new interaction or workflow could fail for users.
- An external service or technical approach needs a fast feasibility check.
- Two competing directions need something more concrete than opinion.
- A risky feature should be isolated before entering production.
- A stakeholder needs to experience an idea rather than review a deck.
Only enough
to find out.
Interaction experiments
Focused interface tests around a risky user behavior or workflow.
Integration experiments
Time-bounded tests of external services, protocols or provider constraints.
Model experiments
Controlled AI tests around a task, input and measurable output.
Workflow simulations
Simplified systems that expose how a process might behave before full automation.
Decision prototypes
Experiments built specifically to make the next investment decision more informed.
The learning loop.
The experiment
The learning loop
Make the next version smarter, not merely newer.
Make
Build one small, explicit test.
Three imperfect impressions become progressively more deliberate. Each pass feeds a small observation into the next—not an endless loop and not a finished product.
A method,
not a guess.
- 01
QUESTION
Write down the one thing the experiment needs to reveal.
- 02
CUT
Remove everything that does not contribute to answering that question.
- 03
BUILD
Create the smallest credible test environment.
- 04
RUN
Put the experiment against the user, system or constraint it was built for.
- 05
EVIDENCE
Capture what happened instead of relying on memory or excitement.
- 06
DECIDE
Stop, revise or graduate based on what the evidence actually supports.
What we learn.
What we use.
Tools serve the question. They are not a fixed stack or a promise of an outcome.
Evidence to collect
- Working experiment
- Observed behavior
- Failure notes
- Measured constraint
- Decision signal
- Next test
Experiment materials
- TypeScript
- Python
- Next.js
- FastAPI
- SQLite
- Supabase
Stop↗
The evidence says the idea should stop here.
Iterate↗
The question became clearer, but another experiment is justified.
Graduate↗
The idea earned a path into a permanent Yard or product.
An experiment that cannot change a decision is just activity.
Good questions
come first.
How fast is a rapid experiment?
The timebox depends on the question. The point is to keep scope proportional to the uncertainty being tested.
Is the result production-ready?
Usually not. Experimental code and interfaces should not be presented as production-ready without a separate hardening step.
Can users test the experiment?
Yes, when user behavior is part of the uncertainty.
Can you test third-party integrations?
Yes, where suitable access and documentation are available.
What if the experiment fails?
That can still be useful if it removes a bad assumption before a larger investment.
Can a successful experiment become a real product?
Yes, but successful evidence should lead to a deliberate production plan rather than silently rebranding the experiment as finished software.