Why we use Flask
We Develop in Django and WordPress — So Why Is Our Own Website Built with Flask?
If you looked under the hood of zojax.com, you might be surprised: the site of a company that builds and supports Django and WordPress applications is, itself, a Flask application. That's not an accident, and it's not an identity crisis. It's a deliberate engineering decision — and walking through it says a lot about how we choose technology for our clients.
The short answer: our website is not the same kind of problem as our clients' applications.
Most of what zojax.com needs to do is serve well-crafted pages fast: service descriptions, case-making content, a blog, a few API endpoints behind the scenes. There is no complex data model, no staff workflow, no nightly import job. When the problem is "deliver excellent pages with a thin layer of logic," a full-stack framework is carrying weight you never asked it to lift — and weight always eventually costs you something.
What Flask gives us in development:
Speed to change. Our Flask layer is small and explicit: every route is visible, every dependency justified. When we want to add a page or an endpoint, the distance between "idea" and "deployed" is measured in minutes, not in settings, migrations, and app boilerplate.
Honest architecture. Because Flask doesn't hand you opinions, the ones you have are yours. The data layer is cloud storage, the compute scales to zero, and the site costs pennies a month to run while staying fast under traffic. Every one of those choices exists because we made it — which means every one of them can be explained, audited, and changed.
What Flask gives us in maintenance (the bigger deal)
Fewer moving parts age slower. No ORM to migrate, no admin to secure, no plugin ecosystem to babysit. The maintenance burden of a small Flask application is close to flat: it does what it does, and it keeps doing it. For a site whose main job is to stay up and stay fast, that stability is exactly the feature you want.
A smaller attack surface. WordPress's greatest strength — its enormous plugin ecosystem — is also its most common point of compromise. Django's power — admin, ORM, batteries included — means more surface to patch and secure. Our Flask site has a handful of dependencies and no plugins at all. That's not a knock on the other tools; it's a recognition that risk should match the job.
Dogfooding where it counts
We're not Flask partisans. If tomorrow our own site needed authenticated users, complex workflows, and a data model with forty tables, we'd rebuild it in Django — and we'd sleep well doing it. If its content needed to be edited daily by a non-technical team, we'd reach for WordPress without hesitation.
The technology is not the deliverable. The deliverable is a system that fits the problem, runs cheaply, stays maintainable, and hands the client the right amount of rope — no more, no less. Sometimes that's Django. Sometimes it's WordPress. And sometimes it's a hundred lines of Flask doing a job it was born to do.
Dean Powers, Founder and CEO zojax.com