Case study Own product · Engineering platform Built and used by Maksym Shpak
Rune — engineering decisions backed by experiments.
I built Rune to make rigorous engineering practical throughout product development. It supports research, implementation, automated checks, and cross-model review — while I remain responsible for the technical decisions and the final result.
1
Comparing implementations through experiments
During a technical spike, I can build several implementations of the same component, measure them under identical load, and choose the one that best fits the requirements.
The criteria come from the task: correctness, latency, throughput, resource use, operational complexity. The winner is rarely “the fastest” — it’s the option whose trade-offs the product can live with.
| Criterion · same load | A | B | C chosen | D |
|---|---|---|---|---|
| Correctness | Meets | Meets | Meets | Fails edge case |
| Latency | Misses target | Best | Within target | Within target |
| Throughput | Within target | Best | Within target | Within target |
| Resource use | Low | High | Moderate | Low |
| Operational complexity | Low | New infrastructure to run | Low | Low |
In this example, B is the fastest but adds infrastructure the team would have to operate; C meets every requirement at a cost the team can sustain. The decision and its evidence go into the pull request.
A real decision
Comparing documentation architectures
In Rune’s own documentation spike, two approaches were compared across file budgets, preservation of measurements, and content organization. The final decision selected A-v5. This is a qualitative architecture comparison, separate from the illustrative performance scenario above.
2
Testing behavior under failure
With Rune, I can develop simulation and fault-injection tests for the failures a specific system is likely to meet — and check what it does next.
These are examples of tests we design for a particular system. They show how it behaves under the failures we model; they are not a built-in guarantee or proof that a system has no bugs.
- Retries and duplicate events
- Deliver the same event more than once. Check that state changes exactly once.
- Idempotency
- Repeat a request with the same key. Check for one effect and a consistent response.
- Interrupted operations
- Stop a process mid-operation. Check that it resumes or rolls back cleanly.
- Redis unavailable
- Take the cache away under load. Check that the system degrades without corrupting data.
- Database outage
- Drop the database mid-transaction. Check for no partial writes and a clean reconnect.
- Recovery and data integrity
- Restart after a failure. Check that state reconciles with the source of truth.
3
A controlled path from task to pull request
AI does a large share of the research and implementation. It doesn’t decide what gets built or what ships. I define the constraints, review the evidence, and accept the result — nothing reaches a pull request without that.
01
Task
I define
02
Research and requirements
Rune researches
03
Approved plan
I approve
04
Implementation
Rune builds
05
Automated checks and cross-model review
Rune verifies
06
Human acceptance
I accept
07
Pull request
With the evidence attached
What it means for your project
Built to support my work with clients.
Decisions you can inspect
Key technical choices come with the alternatives considered and the evidence behind them.
Failure behavior checked early
We model relevant failure scenarios and test recovery behavior before release.
One accountable engineer
AI extends what I can check. The judgment, and responsibility for the result, stay with me.
Discuss your product.
Tell me what you’re building, where it stands, and the technical problem in front of you. I’ll reply with the main risks I see and what I’d test first.