Reference Implementation
Maintained by Scott Michael Wilson. Grounded in eight production solutions running on .NET in 2026. The bar every other stack matches.
Status: Complete
Stacks
Where the Methodology Meets the Metal
The core methodology is intentionally stack-agnostic. Stack-specific patterns, standing orders, and anti-patterns live in the extensions repository — one folder per stack, each owned by a maintainer who has shipped real production work in it. Stacks are scaffolded as the methodology spreads. The .NET reference is complete; the rest are open for contribution.
The Stacks
Status reflects what's currently in the repository. Open stacks are looking for their first maintainer. Click any card to open its folder on GitHub.
Open for Contribution
Component composition, state management, build tooling, and the patterns that survive a real product over multiple years.
Status: Maintainer wanted
Open for Contribution
Web frameworks, packaging, type discipline, and the long-running services that quietly hold up half the internet.
Status: Maintainer wanted
Open for Contribution
Async patterns, dependency hygiene, and the tooling decisions that determine whether a project ages well or collapses under its own package count.
Status: Maintainer wanted
Open for Contribution
Convention-driven development with the discipline FSE adds on top — where the framework's defaults align with the methodology and where they don't.
Status: Maintainer wanted
Open for Contribution
Standard library first, dependencies sparingly, the deployment discipline that comes naturally to compiled binaries — applied through the FSE protocol.
Status: Maintainer wanted
Open for Contribution
Enterprise-grade patterns under FSE's session discipline. Where Spring's conventions fit and where they actively fight the modular monolith approach.
Status: Maintainer wanted
Open for Contribution
The pragmatic stack that quietly runs an enormous share of production websites — under the FSE rules for state, sessions, and standing orders.
Status: Maintainer wanted
Open for Contribution
Cross-platform mobile under FSE — widget patterns, state management, and the build/deploy ceremony that mobile demands.
Status: Maintainer wanted
Open for Contribution
Native iOS development with FSE's session structure and bedrock file approach. App Store-shaped pressure meets methodology-shaped discipline.
Status: Maintainer wanted
Becoming a Maintainer
The first contributor whose extension passes review becomes the maintainer for that stack. The bar is the .NET folder — match its structure, its depth, and its grounding in real production work.
An extension is not a tutorial. It's not a curated awesome-list. It's a working developer's notes on how FSE actually behaves when applied to a specific stack. If you've never shipped a real project in the stack you want to maintain, this isn't the right starting place.
If that still sounds like you, the contribution process is documented in the extensions repository's CONTRIBUTING.md. Open an issue first to confirm the stack is still open and to discuss scope before you start writing.
Frequently Asked Questions
Why these stacks?
They're the stacks that come up most often in the kind of work FSE was built for. Other stacks can be added — open an issue in the extensions repository proposing a new stack and explaining why it needs its own folder rather than fitting under an existing one.
What if my stack isn't listed?
Open an extension request. New stacks get added when there's a maintainer ready to commit and a clear case that the stack is meaningfully different from the existing scaffolding.
Can I use FSE without an extension for my stack?
Yes. The core methodology is stack-agnostic and works without any extension. Extensions are accelerators — they tell you what's already been figured out for your stack so you don't have to rediscover it. If your stack has no extension yet, you're rediscovering it as you go, which is also fine.
What happens if a stack maintainer goes inactive?
If activity drops off and issues stop getting responses, the maintainer status reverts to open. We'll find a successor. Maintenance is a commitment, not a tenure — stepping down honestly is better than holding the role inactively.
Why is .NET first in the list?
Because the creator has worked in it for 25 years and it's the stack everything was originally pressure-tested in. That's the entire reason. The other stacks are listed in roughly the order they tend to come up in real projects.
Are extensions versioned with the core?
No. The core methodology evolves slowly and deliberately. Extensions evolve at the pace of their stacks. Each extension folder is responsible for staying current with its stack's reality.
Can an extension contradict the core?
No. If a stack-specific reality genuinely conflicts with the core methodology, that's a signal to open an issue against the core, not to write a contradicting extension. Extensions translate the core to a stack — they don't override it.
Do extensions cover frontend, backend, and mobile separately?
Mostly yes, by virtue of how stacks split. React covers frontend web, Flutter covers cross-platform mobile, Swift/iOS covers native iOS. A full-stack project may pull from multiple extensions — that's expected.
What about infrastructure stacks like Kubernetes, Terraform, or Docker?
Those aren't application stacks in the same way the listed ones are, so they don't fit the current folder structure. If demand grows, an infrastructure subdirectory may be added. Open an issue if this matters to your work.
Where do I get the extensions?
The extensions repository on GitHub has every stack folder. Clone the repo or browse it directly. Each folder's README.md describes what's in it and who maintains it.
The methodology is stack-agnostic on purpose. Extensions exist so it stays that way without losing the specifics that make it useful.