Background
406 Consulting (live at 406consultinggroup.com) is a boutique Montana accounting and bookkeeping firm. Like a lot of practices growing past word-of-mouth, they reached the point where spreadsheets-and-referrals had taken them as far as it could. The next phase needed a stack: a public surface that turned their accounting expertise into a search-rankable asset, a paid front door for the parts of the practice that lend themselves to packaging, and an internal platform that did more than copy-paste between Karbon HQ and a stack of Google Sheets.
What 406 didn't want was the generic accounting-firm-website experience. They wanted three different things, for three different audiences, that hung together as one practice — and they wanted those things shipped at the pace of a real working firm, not a 12-month rebuild.
The problem
Concretely, the practice needed to solve three problems at once:
- Authority and lead-gen. Prospects were finding the firm by referral or not at all. There was no public surface where 406's expertise lived in a form Google could index and prospective clients could read. A blog hidden behind a CMS that nobody could update wasn't going to fix that.
- A productized top of funnel. Montana business formation — LLC, S-Corp, C-Corp, nonprofit — is a natural way for accounting clients to find an accounting firm. But selling formation work the same way the firm sells advisory work (intake calls, estimates, custom scopes) wastes everyone's time on a transaction that should be a checkbox-and-checkout flow.
- Internal operations that compose with Karbon HQ. 406 runs its practice on Karbon HQ. That gives them the workflow primitives — work items, contacts, organizations, timesheets — but not a place to do the operational work that lives around Karbon: tracking initiatives by impact and urgency, getting an audited record of who did what when, exporting time data for invoicing in a shape Karbon doesn't natively produce. The team needed a system that treated Karbon as the source of truth without making them live inside its UI.
None of these problems was crushing on its own. The trap was that solving them as three unrelated SaaS subscriptions would scatter the firm's identity and operations across tools that don't talk to each other — exactly the position the practice was trying to grow out of.
The approach: three surfaces, one coherent stack
We shipped 406 a three-surface platform. Each surface owns its release cycle, audience, and security boundary. They share a stack, an identity system, and a set of operational primitives so the firm doesn't have to reconcile three sets of credentials and three deploy stories every time something changes.
1. The marketing site (406consultinggroup.com)
The public-facing surface for the firm. Django 5 backend, React 19 + Vite
frontend, Supabase Postgres, Mailgun for transactional email. The piece
that makes it more than a brochure is a custom article pipeline: a Prose
Kit-based rich editor with input sanitization, a unified
/articles index that consolidated the original blog and
resources sections into one taxonomy, and SEO metadata baked in at the
schema level — Article and FAQ JSON-LD generated server-side, canonical
URLs, OG images, category and tag organization. The point is that 406's
accountants can write the way they actually write — long-form, with tables
and inline links and footnotes — and the system handles the SEO surface
without anyone editing meta tags by hand.
The article import pipeline also accepts external Manus-style ZIP exports, sanitizes the markup, backfills metadata, and routes the article through a draft → in-review → published workflow. That matters because the firm sometimes drafts content in tools other than the CMS itself — and we didn't want the CMS to be the bottleneck on publishing.
2. The productized formation service: Launch 406 (launch406.com)
A niched-down product on its own brand, leveraging Montana's 406 area code
to position itself as the obvious choice for in-state entrepreneurs. The
product is Montana business formation made buyable: pick the entity type,
pick a tier, check out, and the firm picks up the work on the other side.
Stripe Checkout drives the payment flow with three tiers (starter, growth,
complete). Webhooks land back on the Django side with proper signature
verification — Webhook.construct_event(payload, sig_header, secret)
— and atomically update an Order model with Stripe's
checkout_session_id, payment_intent_id, and
customer_id. Mailgun fires a customer receipt and an internal
notification on each conversion.
The strategic role of Launch 406 is that it's a top-of-funnel for the accounting practice. People form an entity, they need bookkeeping, payroll, and tax work — and they're already a customer. A productized formation service is the kind of thing that would be a quarter-long project to add to a generic accounting-firm site. As its own brand, on its own domain, on a focused checkout flow, it's a real product.
3. The command center (cc.406consultinggroup.com)
The internal operations platform — the one the firm's team actually uses day-to-day. Django 5 + DRF for the data and admin surface; a thin FastAPI gateway in front of it for token authentication, request logging, and the bidirectional Karbon HQ sync; React 19 + Vite for the operations dashboard. The sync is the centerpiece: six Karbon entity types — users, contacts, organizations, work items, client groups, and timesheets — flow in both directions over Karbon's OData API, with transparent pagination, deduplication, and per-entity error logging. Karbon stays the practice's system of record; the command center is the operational layer that wraps around it.
Around the sync we added a few things Karbon doesn't ship natively. An
Initiative model with impact, urgency, and effort scores
yields a composite score (impact × urgency / effort)
that the team uses to prioritize internal projects. An
ActivityLog middleware records every API call with user, IP,
HTTP method, path, status, and duration — non-blocking, written via
sync_to_async, indexed on the access patterns the audit
exports actually use. Time entries link team members to projects with
billable flags, hourly rates, and date granularity, giving the practice a
clean handoff into invoicing without re-keying.
The shared stack
All three surfaces run on the same operational primitives: Django on the backend, React + TypeScript + Vite on the frontend, Supabase Postgres for data, Doppler for environment-scoped secrets, Buildkite for CI/CD, Cloudflare in front of nginx on a DigitalOcean droplet. Picking a coherent stack isn't a technical preference — it's so the firm can reason about where things are deployed, where credentials live, and how to ship a change to one surface without touching the other two.
Outcomes
The relationship is ongoing — we're still shipping work on the marketing site and continuing to extend the command center. A few qualitative outcomes that are true today:
- 406 has a public surface where their accounting expertise lives as long-form, search-indexable content rather than vanishing into client-only memos.
- Launch 406 turns Montana business formation — historically a phone-and-PDF transaction — into a checkout flow that runs without a meeting.
- Karbon HQ stays the practice's system of record, and the command center adds the operational scaffolding around it: prioritization, audit trail, and time-to-invoice handoffs that don't require a second tool.
- The three surfaces ship independently. The marketing site can publish a new article tomorrow without touching the product site or the command center; Launch 406 can add a tier or a webhook event without touching the other two.
The stack
Django 5 + Django REST Framework on every backend; FastAPI as a thin gateway on the command center; React 19 + TypeScript + Vite + TailwindCSS on every frontend; PostgreSQL on Supabase; Stripe Checkout + signed webhooks for payments; Mailgun (via django-anymail) for transactional email; Karbon HQ's OData API for the practice-management sync; Celery + Redis for background work; Doppler for secrets; Buildkite for CI/CD; Cloudflare + nginx on DigitalOcean for hosting. The 406 platform is the shape of work we like: pragmatic, multi-surface, and built so the firm can keep growing without growing the operational drag.