Introducing Gesttalt
I've been frustrated with static site generators for years.
Not because they're bad tools. They're excellent at what they do: compiling content into deployable sites. But every time I've wanted to build something on top of them, I hit the same wall. The structure shifts. Configuration options change. What worked in version 2.x breaks in version 3.x. The ecosystem can't grow because the foundation keeps moving.
If you want to have a tool to publish content to your static site, which can live on GitHub, or just a directory synced via iCloud, you can't because the structure follows no convention. The alternative is running your instance of WordPress, Ghost or similar, with an API contract you can adhere to, but it shouldn't need to be like that.
Gesttalt is my attempt to fix this.
The Web Got This Right
Think about web browsers. HTML, CSS, and JavaScript have evolved over decades, but the fundamental contract has never broken. A page written in 1995 still renders today. This stability didn't limit innovation. It enabled an explosion of tools: editors, frameworks, analytics, accessibility checkers, all building on the same unchanging foundation.
Static site generators haven't learned this lesson. Most prioritize flexibility over stability. They let you configure everything, which sounds great until you realize that configurability means nothing is guaranteed. Want to build an iPhone app to edit your blog? You'll be rewriting it every few months as the generator evolves. Thinking about an LLM interface for content creation? Hope you enjoy maintaining integration code.
This fragility makes it impossible to build an ecosystem.
What Gesttalt Promises
Gesttalt is designed like a web browser: a stable compiler with unchanging conventions. The structure won't break. The compilation model won't shift. This isn't about limiting what you can do. It's about creating a foundation others can build on.
This principle echoes the Lindy effect: the longer something has survived unchanged, the longer it's likely to continue. The web's stability comes from its backwards compatibility guarantee. Gesttalt adopts this same philosophy.
Here's what becomes possible:
- Multiple interfaces for content editing: iPhone apps, web editors, LLM-powered writing assistants, all working with the same content structure. Build one, and it keeps working.
- Deployment as a side effect: Compilation is the source of truth. When you compile your site with Gesttalt, deployment happens automatically. No separate deploy step, no configuration drift.
- Programmable through bindings: Binary and C bindings let you build custom tools without waiting for features. Gesttalt becomes infrastructure, not a product.
Why Zig?
This vision only works if Gesttalt runs everywhere. We chose Zig to make that real. Gesttalt compiles for Linux, macOS, Windows, and WebAssembly. A single binary, no runtime dependencies. The foundation is accessible from servers to browsers to mobile devices.
The Starting Conventions
These are the first conventions Gesttalt guarantees. They will never break:
content/blog/YYYY/MM/DD/slug.mdfor blog posts (date-based organization)theme/layouts/for Mustache templatesstatic/for assets (CSS, images, etc.)build/for compiled output
We're starting with blogs because that's what most people need. But the plan is to expand: documentation sites, project pages, photo galleries. Each type of content will get its own conventional structure. The key is that once we add a convention, it never changes.
This approach follows the principle of convention over configuration, pioneered by frameworks like Ruby on Rails. But where Rails allows configuration overrides, Gesttalt's conventions are immutable.
If we add content/docs/ for documentation, your tools built for that structure will work forever. If we add content/photos/, same deal. The ecosystem grows, but the foundation never shifts.
Who Gesttalt Is Not For
Let me be direct: Gesttalt is not for everyone.
If you need maximum flexibility, use something else. If you want to customize every aspect of your build pipeline, this isn't it. If you're building a one-off site that you'll never touch again, the stability promise doesn't matter to you.
If you need built-in integrations with web services like payment processors, user authentication, or real-time databases, Gesttalt won't help. These are dynamic features that static site generators simply don't support. You'll need a traditional CMS or web framework for that.
Gesttalt is for people who want to build tools and workflows around their content. It's for developers who value long-term stability over short-term flexibility. It's for teams who want to invest in custom tooling without the fear that an update will break everything.
If you're happy rebuilding your integrations every few months, you don't need Gesttalt. If that thought makes you frustrated, welcome.
What's Next
This is just the beginning. Gesttalt is about creating infrastructure. The ecosystem will grow from here: editors, deployment tools, analytics integrations, content management interfaces. All building on the same reliable structure.
I'm building this in public. The conventions are public. The roadmap is public. If you value stability, simplicity, and the freedom to build your own tools, I'd love for you to join me.