Software Design

Thinking in Solana

Accounts, Programs, ownership, Sealevel; the Solana building blocks that unlock your thinking about real-world use cases and applicability.

Mission control room with operators at consoles facing a curved wall of monitors and telemetry — the human go/no-go moment in a high-stakes system

The Half of CI We Forgot to Automate

We automated the cheap half of trust: contracts and types. The expensive half, evidence on how the system actually behaves, we still answer with a vibe.

A path forks in the foreground — one branch leads into a dark forest of broken, glowing technology and stormy decay; the other winds toward a bright, sustainable city under a golden sunset. The choice between an unstable path and one that leads forward.

Stable Problems

The moment everyone nods at the problem is the moment to slow down.

A drafting table merging into a terminal screen — compass, ruler, and wireframe blueprints dissolving into lines of code — the boundary between design and programming erased

Design Is the New Programming

The bottleneck moved. Execution got cheap and most builders aren’t optimizing for it. Yet.

Silhouetted figure in a doorway holding keys towards a brightly lit factory floor — control of the whole production at stake

Process Before Solution

AI is getting better at solving it. You still don’t know how. This will keep happening.

A clean geometric structure made of transparent glass blocks with simple arrows showing clear rules, contrasted against a tangled dark mass of wires and patches behind it — a visual metaphor for explainable design versus accumulated complexity

Explain Your Rules

Every abstraction introduces rules. If you can explain them in a sentence, your design is mature. If you can’t, something went wrong — and it’s one of three things.

Aristotle as a software architect, contemplating a digital interface while fragmented design patterns labeled "Singleton" and "Bad Code" scatter around, with a flowing river of data representing well-modeled reality

Model the Reality, Not the Patterns

Why focusing first on properly modeling the domain is better than forcing design patterns into your code.