Django and the Case for a Boring Stack on a Small Team

Django is the least exciting backend choice a solo developer in Sri Lanka can make in 2026, and that is exactly why I keep recommending it. The case landed again this week in "What I love about Django" by Justin Duke, founder of the newsletter platform Buttondown, published on his company blog on 4 August 2026.

Duke has run a real, paying business on Django for eight years. What struck me was not his list of favourite features. It was how much of the essay is about things his team refuses to use.

---

🔍 The argument: good abstractions disappear

Duke's framing is that Django's best parts are the ones you stop noticing. His own line:

"The best parts of Django are the ones you stop noticing — a tour of the abstractions that have given Buttondown the most leverage."

He walks through five: middleware, models with one light base class, actions (behaviour in its own file, one verb per module), views, and testing. The base model gives every table a UUID, a creation date, implicit change tracking, and a provenance trail through transition tables. On views he is blunt:

"Writing maintainable view code is more about avoiding failure than finding success."

He picked Django in 2018 to spend fewer innovation tokens, and says he has never regretted it, even while second-guessing his frontend choice.

---

🚫 The subtraction list is the real content

Here is the part most people will skim past. Buttondown deliberately does not use large chunks of the framework it depends on.

Django feature	Buttondown's stance
Signals	Avoided, with exactly one exception
Class-based views	Not used; function-based only
Conventional app structure	Not followed
Django Checks	Not used
Django Forms	Not used
Factory Boy test factories	Replaced with custom pytest fixtures hitting real DB rows

Six removals against five endorsements. That ratio is the essay's actual thesis, whether or not it was meant that way.

Key takeaway: The leverage does not come from the framework. It comes from picking a small subset of it and never deviating, so that any file in the codebase is predictable from its name alone.

---

💡 Why this matters more here than in San Francisco

A team of twenty can absorb an inconsistent codebase. Someone has been there long enough to know that utils/helpers2.py is where the billing logic hides. A team of one or three cannot. In Sri Lanka most product work happens at that size: a freelancer with three retainer clients, a two-person startup, an in-house dev maintaining something a departed contractor wrote.

Costs land differently at that scale:

Decision	Cost on a 20-person team	Cost on a team of one
Novel framework	A week of shared learning	Every bug is also a research project
Inconsistent file layout	Tribal knowledge covers it	You re-read your own code as a stranger
Clever metaprogramming	One person owns it	Nobody owns it after three months
Heavy test factories	Absorbed by CI budget	Slow tests mean you stop running them

Add the local constraint: a lot of us deploy to a 1–2 GB VPS or a free tier, not an autoscaling cluster. A stack with a large, well-trodden default path is cheaper to run and far cheaper to debug at 11pm when nobody else is awake to help.

---

🛠️ Four conventions worth stealing, whatever you write

You do not need to write Python to use this. Translate the rules:

1. One verb per file. Duke's "actions" pattern puts each behaviour in its own module instead of growing a 900-line model class. The Next.js equivalent is one server action per file, not a barrel of forty exports.
2. Function-based, individually filed views. Standardised names mean you can find any handler without grep. Fewer inheritance chains, fewer surprises.
3. One thin base model. IDs, timestamps and change tracking defined once. Every ORM supports this and almost nobody bothers.
4. Fixtures over factories. Tests that touch real rows, tuned for speed. Slow test suites do not get run, and an unrun suite is worse than none.

Notice that none of the four are Django-specific. Three of them are really a single rule: make the file's location and name tell you what is inside it.

---

🎓 What this means for students and freelancers

If you are at a Sri Lankan university learning Python and wondering whether Django is a dead-end while everyone posts about newer stacks: it is not. A framework that carries a running business through eight years of change is a safer bet for your first production app than whatever is trending on Hacker News this month. And the local job market for Python backends is real, mostly in fintech, logistics and outsourced product work.

Practical starting points:

• Get comfortable with plain Python first. Our free online Python compiler runs in the browser, so a slow laptop or no local setup is not a blocker.
• When you hit the ORM, you will spend real time reading generated SQL. The SQL formatter makes a 40-line query readable.
• Django's URL routing is regex-shaped underneath. The regex tester is worth having open while you learn it.

One caveat I will state plainly: Duke's post is one experienced founder describing what worked for one product. It is a well-argued opinion, not a benchmark. Your constraints may point at Laravel, Rails or a TypeScript backend, and any of those support the same discipline.

---

What this means for you

Pick the boring thing, then be strict about how you use it. That is the whole lesson, and the strictness half is the part people skip.

Concretely, for your next project:

• Choose one framework you can get unstuck in at midnight. Popularity is a debugging feature, not a fashion statement.
• Write down the subset you will use. Which patterns are in, which are banned. Put it in a CONVENTIONS.md at the repo root.
• Spend your innovation tokens on the product, not the plumbing. Your users cannot see your stack.
• Re-read your own rules in three months. If you broke them, either fix the code or change the rule. Do not leave both standing.

Bottom line: Duke did not write a love letter to Django. He wrote a love letter to constraints, and Django just happened to be the thing he constrained. The constraints are portable. Take those.