Rules we learned the hard way.

We've built for the web for over two decades, with Django since version 1.1. These are the rules we've settled on. None of them are complicated. Doing them is the part people skip.

Half measures are as bad as nothing at all

Wade's first project took two weeks to get running on a laptop. Every project we touch now gets a script/bootstrap that goes from a fresh clone to a running app in minutes. Almost-working Docker configs and READMEs that were accurate two years ago count as nothing.

Never go dark

You see what we built, merged and shipped every week, in GitHub, not in a slide deck. Nobody disappears for two weeks and comes back "heads down".

Taste doesn't come from a prompt

Agents write a lot of our first drafts now. Deciding what's worth building, what to delete, and which shortcut will bite you in two years is still on us.

Simple beats complex. Complex beats complicated.

Django, Postgres, Docker, Tailwind, GitHub Actions. After trying everything else, these work without a fight. Complex is fine when the problem demands it. A README that says "ask James" never is.

Diagnose before you build

Most failed projects have a diagnostic problem, not a technology problem. We ask a lot of questions first. Once you understand what's actually broken, the fix is usually obvious.

Ship something every week

Deadlines force decisions. We split big work into pieces that ship weekly, and recheck priorities every month so nobody burns cycles on last quarter's roadmap.

Leave it better than we found it

Every pull request refactors a little, adds a test, fixes a doc. Showing up and putting in the reps, day after day, is the whole trick.