BuildBusters

The problem

BuildBusters sells stamped, permit-ready drawings to homeowners and contractors across the US. Every lead started with a quiz on the marketing site, and ended in an inbox. The quiz emailed the team and stored nothing. Everything after it, the call, the quote, the payment, the drawings, ran on phone calls and emailed PDFs.

The approach

One system from the first answer to the approved permit.

• The quiz. 22 project-type flows, written as data rather than code, each ending in a ballpark: projects like yours cost X to Y. The ballpark is stored against the enquiry, so when the quote lands higher both sides can see what changed.
• The client app. Passwordless sign-in by code or link. Architect call booking, quote acceptance, Stripe milestone payments, drawing rounds with signed downloads, project files, team invites, messaging.
• The admin. A form builder, a leads inbox and project operations, updating live over websockets.
• The plugin. The backend is also an MCP server, packaged as an assistant plugin. The owner runs the pipeline from chat: today's leads, a quote set and sent, a drawing round delivered.

A few rules hold it together. An enquiry is not a project until money moves. The project tracker is derived from what actually happened, never set by hand. No tool can accept a quote; that stays the client's decision. And anything that emails, texts or bills a client stops at a draft first.

What I owned

The API, the web app and the plugin. Django 5.2, DRF and Channels on the server, Celery for email and SMS, and Stripe, Twilio and Resend behind offline stubs, so the whole stack runs with no keys at all. Next.js 16 on the front, behind a BFF that keeps tokens in httpOnly cookies. The marketing site on Astro and Cloudflare. The API on Oracle Cloud behind Caddy.

Outcome

Live at buildbusters.com, with the client portal at app.buildbusters.com. 728 backend tests. 31 MCP tools.