The tech stacks I like and why they matter for your business
My criteria for picking tools are simple: proven, maintainable, and AI-friendly. Battle-tested for years, easy to hand off, and something modern AI can work with fluently. If a framework is exciting but fragile, I'm not interested. Your business needs systems that run while you sleep.
If you're a founder or operator evaluating a technical partner, you should always ask them to explain why they chose their stack. Here's my answer.
Django: the boring choice (on purpose)
Django is a Python web framework, open-sourced in 2005 and actively maintained for over 20 years. Instagram, Pinterest, and Mozilla have all run production systems on it. I call it boring as a compliment.
It's stable. Every Django LTS release gets three years of security and data-loss fixes. That means once you deploy on an LTS version, you're covered for years before you need to think about upgrading. It respects your investment.
It ships complete. Authentication, database migrations, an admin panel, form handling, security protections. All built in, all maintained by the same core team. You're not stitching together 15 packages and hoping they stay compatible.
AI is great at it. Python is the most popular language in AI training data, and Django is one of the most documented frameworks in the world. AI-assisted development tools produce accurate, production-ready Django code far more often than with newer frameworks. That's a real multiplier on delivery speed.
The result: "set it and forget it" infrastructure. Once deployed, it runs. Security patches come on a predictable schedule. Upgrades are straightforward. Your team uses the software instead of firefighting it.
For background work (sending emails, generating reports, syncing external data), I pair Django with Redis, Celery, and Celery Beat. Celery handles async tasks so nothing blocks the user. Celery Beat handles scheduled jobs: pull fresh MLS data every hour, generate weekly reports every Monday at 6am. This is an enterprise-grade stack that companies have run for over a decade. Once configured, it just runs.
For frontend interactions, I use HTMX. It adds dynamic behavior (live search, form submissions without page reloads) through HTML attributes. No JavaScript framework, no build step. Django renders HTML on the server, HTMX swaps it into the page. For dashboards and internal tools, it's the perfect complement.
Ruiz Report runs on this full stack: Django, Celery, HTMX. Data ingestion, report generation, white-label configuration, server-side analytics. Rock-solid. The kind of boring you want from the system your clients depend on.
TypeScript and the JavaScript world
Django is my default. It's the most boring, bulletproof stack for most business use cases. But it's not always the right answer. When the project needs a rich interactive frontend, when hosting budget matters (JavaScript apps can often deploy for free or close to it, a Django stack basically can't), or when there's a mobile app in the picture, I reach for TypeScript instead.
Why TypeScript
When I do reach for JavaScript, I use TypeScript across the entire project. One language means one mental model. Database schema, API contract, frontend, mobile app. Same language, no translation layer where bugs hide.
I pair it with Drizzle (database ORM) and Zod (data validation). Together they give me a structured, disciplined data layer, similar to what Django's ORM provides in Python but native to TypeScript. The database schema, the validation rules, and the application types all stay in sync automatically. When something changes, the compiler tells you everywhere it matters. No silent breakage.
React Router v7 framework mode
For web applications, I use React Router v7 in its framework mode. It's explicit about where your code runs, and the data loading model is clean. It also ships with official adapters for most deployment methods, so you're never locked into one hosting provider.
The mental model fits operations software well. Each route owns its own data and UI, cleanly separated by business domain. Same principle behind Django's "apps" concept. Adding a new module doesn't require touching the rest of the system.
React Native: why I learned JavaScript in the first place
I didn't come to JavaScript voluntarily. I was building backends in Django with HTMX handling the frontend, perfectly content. Between the two, I thought I'd solved the "do I need JavaScript?" question entirely. Then I needed a mobile app.
Django doesn't do mobile. Full stop. I chose React Native because it lets me use the same language as the rest of the stack. I can share data models, validation logic, and API clients between the web app and the mobile app. One codebase compiles to native iOS and Android. Paired with Expo for build pipelines, push notifications, and over-the-air updates, it covers every mobile use case I've encountered. The community has been shipping production apps since 2015, so when you hit a problem, someone has already solved it.
David's Men was my first React Native app: a discipleship tool for a men's ministry, built with Expo, shipping to both platforms from one codebase.
The common thread
Every tool I've described shares the same qualities: proven, well-documented, and backed by large communities. None of them are bleeding-edge. None of them will impress someone at a tech conference cocktail party. All of them will still be here in five years, supported and maintained, running your business without drama.
That's the point. Your technology stack should be an asset, not a liability. It should be something your next developer can understand in a week, not a custom labor of love that only the original author can maintain.
If you're evaluating a technical partner or a fractional CTO, ask them why they chose their stack. If the answer stops at "it's gaining a lot of traction" or "it's what I know," I would keep looking. The answer should be about your business: what's reliable, what's maintainable, and what lets you ship fast without accumulating debt you'll pay for later.