SpecState
System design for critical software
I help teams design backend systems, workflows, and protocols before the wrong assumptions get baked into code. When useful, I use formal verification and TLA+ to make behavior precise.
What I do
I work on the parts of a system that are easy to get wrong on paper
Most system design problems are not about syntax. They are about behavior: what can happen, what must not happen, and what the system should do when reality gets messy.
- Backend systems with tricky state and failure handling
- Workflows with retries, ordering, permissions, and approvals
- Protocols and state machines that need exact behavior
- AI agent flows with tools, handoffs, and side effects
Who this is for
For teams building systems where behavior matters
- Engineering leads working through hard system design problems
- Founders with technical teams building core backend logic
- Teams shipping workflows, protocols, or stateful product behavior
- Teams that want clearer system behavior before writing a lot of code
Services
How I work
Design Review
1I review one system, workflow, or protocol and point out the assumptions and failure cases that need to be fixed before implementation.
System Modeling
2I model the behavior of a system when the rules are hard to reason about informally, using formal verification and TLA+ when useful.
Advisory or Implementation
3I stay involved after the design work when you need help turning the design into code without losing the original intent.
Common engagements
Work that often needs exact system behavior
Formal Verification and TLA+ Consulting
When a system has too much state, concurrency, ordering, or retry logic to reason about confidently, I use formal verification and TLA+ to make the rules precise and expose failure cases early.
Distributed Systems and Backend Design Review
I help teams pressure-test retries, idempotency, consistency, timeouts, handoffs, and failure recovery before those assumptions get locked into production code.
Workflow, Permissions, and State Machine Design
I work on approval flows, operational workflows, and product behavior where permissions, transitions, and side effects need to stay coherent under real-world usage.
Why formal verification
I use it when plain reasoning is not enough
- Most teams do not need formal verification everywhere.
- It helps when a system has enough state, ordering, retries, or coordination that informal reasoning stops being reliable.
- I use formal verification and TLA+ when that is the clearest way to make the behavior precise.
FAQ
Questions teams usually ask before reaching out
When does formal verification or TLA+ make sense?
It becomes useful when a system has enough concurrency, retries, coordination, or failure handling that informal design reviews stop being reliable.
Do you only work on greenfield projects?
No. I review both new designs and existing systems that already have production constraints, operational incidents, or unclear behavior.
Is this only advisory work?
No. I can stay involved after the design phase when a team needs help translating the design into implementation without losing the original guarantees.
Contact
Bring me in before the design turns into code
Reach out if you are working through backend system design, workflows, protocols, state machines, or formal verification work.
contact@specstate.com