We elevate software engineers to the right abstraction level: the domain- what your software actually manipulates.
Software design starts at the domain, not the code.
We give product designers and software engineers the tools to model domains, verify it, and build from it.
Our Guiding Principles
Every concept earns its definition.
An invariant is not a policy. A command is not an event. An entity is not a value. We draw these distinctions because imprecise semantics produce imprecise systems. When every concept has a sharp name, typed relations, and explicit constraints, the model becomes something you can reason about - and build from - with confidence.
The domain is the product.
Technology serves the problem space, never the reverse. If you can't name it, you can't build it right. And when the domain is clear, it becomes almost invisible - users don't notice the model, they just experience software that does exactly what they expect. That's the value: not the elegance of the abstraction, but the clarity it creates for the people who use the system every day.
Prove it, don't promise it.
Every entity carries invariants that must hold. Every state machine defines which transitions are legal and which aren't. Every policy declares what happens when an event fires. These aren't documentation - they're verifiable properties baked into the model itself. Simulate a scenario, and you see exactly where a rule breaks, a guard fails, or a boundary leaks. Confidence doesn't come from promises in a spec document. It comes from a model you can run.
Who we are?
We dig until the problem is sharp - the right solution follows.
The hardest part of software isn't writing code - it's knowing what you're building and why. We dig into the domain until we find the right concepts, the right boundaries, the right rationale. Because a system built on well-defined problems stays coherent. A system built on assumptions falls apart the moment someone asks "why?"
We obsess over details.
A vague boundary in a model becomes an ambiguous rule in code, then an edge case nobody handles, then an incident report. We'd rather spend an hour getting one detail exactly right than watch it quietly rot through the entire system.
We design for real systems.
Performance, reliability, security, operability - we architect for the forces that don't show up in user stories but make or break production. Thirty years in the software industry, and we're still geeks at heart: nothing excites us more than a well-designed system where every piece earns its place.
The people behind Specy
David Panza
Co-founder
I build and ship. Fast. Give me a well-defined problem and I'll have a working system before you've finished your coffee. I'm a pragmatic builder - I design reliable software end-to-end, from the first expression of a need to deployment, always weighing the economic, organizational, and cultural context around the software.
Jérémie Grodziski
Co-founder
I think about the problem and the right concepts to solve it until is crystal clear. I've spent my career at the intersection of software, architecture and product design, designing complex software systems using Domain-Driven Design - not because it was fashionable, but because it was the only way that worked. I'm a curious mind: I dig into domains until I understand the people and the problems, and I won't stop refining until the model is right. Specy grew out of that obsession - years of formalizing domain concepts, typing relations, drawing precise boundaries.
See what your system knows.
We'll run Specy on one of your modules.
One hour. No commitment. You keep the model.