How We Think

We started Flow Canon because we saw talented people trapped in dysfunctional systems, shipping nothing. We've built for the web for over two decades, with Django since version 1.1. We settled on a set of principles. They aren't complicated. Doing them is the part people skip.

Half measures are as bad as nothing at all

We inherited a project from a zombie startup once. Leadership had flown to a dude ranch in Arizona for a team-building retreat, bought a dozen hatchets from the general store, wrote their names in Sharpie, and planned to bury them in the desert as a symbolic gesture. They never dug the holes. The CEO's hatchet said "The Best" across the face. It still works great as an actual hatchet.

That company had fired its CIO and COO. They were reading Creativity Inc on a three-day mandate. They had a business coach. They did not have working software. Dysfunctional organizations produce dysfunctional code. Symbolic hatchet-burying won't change that. People who ship code will.

We've taken over codebases with no tests, no docs, and no active team members. The first project Wade worked on took two weeks to get running on a laptop. That experience is why every project we touch gets a script/bootstrap that takes you from zero to running in minutes. Partial documentation, almost-working Docker configs, READMEs that were accurate two years ago: as bad as nothing. We don't leave things in that state.

Mind your words, they are important

The best communicator wins the job, the promotion, the influence. They don't need the best ideas. A developer with genius-level intelligence who goes dark and can't explain their work will lose to the one who keeps stakeholders informed.

We never go dark. You see what we built, merged, and deployed every week in GitHub, not a slide deck. A developer who disappears for two weeks and resurfaces with "sorry, I was heads down" has a communication problem. Jeff Atwood put it well: don't go dark. We over-communicate rather than leave you wondering.

Simple is better than complex

Should you use Django's Generic Foreign Keys? No. Don't cut down a tree with a butter knife, and don't bring a chainsaw to breakfast. We use Django, Docker, Tailwind, Poetry, and GitHub Actions. After trying everything else, we chose these because they stay out of the way.

Complex is fine when the problem demands it. Complicated is never acceptable. A well-structured Django app with clear app boundaries, test coverage, and a one-command bootstrap is complex. A tangle of Generic Foreign Keys, undocumented Celery tasks, and a README that says "ask James" is complicated. We turn complicated into complex, complex into simple, wherever we can.

Practicality beats purity

You can learn everything a business coach will tell you from books and the internet. We've read the books. We've sat through the retreats, the frameworks, the paraphrased commencement speeches repackaged as "strategy." None of that ships software. Asking the right questions, understanding the problem, and writing the code does.

Before we write a line of code, we ask questions. Lots of them. Debugging, and consulting by extension, is the art of asking good questions. Most failed projects have a diagnostic problem, not a technology problem. Someone skipped straight to building without understanding what was broken. We spend time on diagnosis because the fix is obvious once you see the problem clearly.

Deliver exceptional value, and all else will follow

We reassess priorities monthly. Twelve chances a year to evaluate whether you're doing the highest-value work available. Last month's top priority might be irrelevant today. Teams that cling to a stale roadmap burn cycles on features nobody needs.

Deadlines force decisions. We focus on the most impactful work, split large efforts into progressive deliveries, and ship something of value every week. Antonio Gracias put it well: great companies are built by engineers, ruined by CMOs, destroyed by CFOs.

Show up and do the work

Pressfield calls it the Resistance. You know it as the gap between what you planned to do today and what you did instead. The hardest part of any project has nothing to do with architecture or technology. You show up, day after day, and put in the reps.

We ship. We improve the project with every PR: refactoring, adding tests, fixing documentation as we go. The teams that showed up every day are the ones still standing when the money dries up.