The method
What if is never a limiting factor.
Every product, patent, and system that comes out of this group started as a question someone decided was worth asking. It is the one method that runs through all of it — named here because it shapes how the engineering actually gets done, not because it makes a good slogan.
Constraints are the terrain, not the destination.
The question is not asked to find a reason something cannot be done. It is asked to find one reason — any reason — why it might be possible. The moment that reason exists, there is somewhere to build from.
This is not the same as ignoring reality. Constraints are real, resources are finite, and physics does not negotiate. But a constraint is the terrain you cross, not the place you stop. Possibility is the only legitimate starting point.
Three modes
Which question, and when
The same question does different work depending on where you are. Asking the generative version of it during an incident wastes everyone's time; asking the diagnostic version at the concept stage kills the concept.
Generative
Facing a blank sheet.
A new concept, an unmet need, a frustration with how something currently works. The goal is expansion — as many directions as possible before evaluation starts. Judgment is deliberately suspended.
Strategic
Facing a commitment.
A go/no-go, an architecture choice, a platform bet. The goal is scenario coverage: the decision gets tested across several futures, not only the intended one. The question is asked with deliberate adversarial intent.
Diagnostic
Something is already straining.
A project off-track, a system behaving unexpectedly, a migration not going to plan. The goal is root-cause mapping — asked to find the failure honestly, because you cannot fix what you have not named.
In practice
What this actually commits us to
A principle that changes nothing about how the work is done is decoration. Each of these is checkable against the deliverables.
No system is designed without a failure scenario
Resilience is designed in, not retrofitted. Row-level security exists in Praxis because the question was asked at schema time, not after a leak.
No strategy ships untested against its own failure
Before any architecture is committed, it is asked what happens if it does not work — and the answer is written into the decision record alongside the choice.
Constraints get interrogated, not accepted
A constraint is real until someone checks whether it is still real. Most technical limits in a brief turn out to be inherited assumptions nobody has re-examined.
The question stays open after the decision
A decision record is a snapshot of reasoning, not a locked door. When the reasoning stops holding, the record gets superseded rather than defended.
A strategy that has only been tested against the best-case scenario is a plan, not a strategy.
Where it started
Every product here was a question first
What if a dealer in the Rio Grande Valley could run their whole lot from a phone, in Spanish, for less than a paper ledger costs?
What if tenant isolation were enforced by the database itself, so an application bug could not leak one customer’s data to another?
What if a flyer designer were one file that needed no account, no subscription, and no internet at all?
None of those had an obvious answer when it was asked. Each one is now a product, a schema, or a patent filing. “We cannot” must always be followed by “unless.”
The question is never the problem. The problem is stopping before you ask it.