Situation
The same problem wearing five costumes
An interior design firm came to us with a problem that did not fit in one box, because it was not one problem.
Design work runs on coordination. A project moves forward when the right email gets answered, the right vendor confirms the right spec, and the right person remembers what was decided three months ago. None of that is design. All of it consumes designers. The inbox decided each morning's priorities by arrival order. Vendor threads stalled on incomplete information, then needed chasing. Institutional knowledge lived in the heads of senior people and in attachments nobody could find. The picture of how the business was doing lived in whoever last assembled it. Business development happened in the gaps the other four problems left behind.
Most firms in this position buy five tools and get five new logins. We argued for one operating layer instead, because the five problems feed each other. An answered email often depends on knowing what was decided before, which is a knowledge problem. A vendor follow-up depends on noticing the gap, which is an inbox problem. A leadership decision depends on seeing the numbers, which is a reporting problem. Automate any one in isolation and it keeps tripping over the other four.
That argument has a cost, and we said so. Five systems in one build means a longer deployment, more change management, and more education before anyone can declare victory. The firm took that trade with eyes open.
Three constraints were fixed before the build. The systems had to follow the firm's own workflows, because a design studio's email is not a sales team's email and vendor coordination has its own grammar of specs, lead times, samples and revisions. The system could propose but never act on its own: an AI-drafted reply is a draft until a person sends it, and a vendor follow-up goes out only under rules the team set. And the firm's knowledge had to stay the firm's, on its own database instance, with the firm holding the keys.
What we built
Five systems on one data layer
- AI inbox. Incoming email is triaged by priority instead of arrival order, and the system prepares draft replies for a person to edit and send.
- Vendor coordination. Vendor threads are checked for missing specs, confirmations and dates. Gaps trigger follow-ups under team-set rules, so chasing stops being a job someone has to remember.
- Internal knowledge brain. Retrieval over the firm's own documents and decisions, on vector search in Supabase. Ask it what was decided, and it answers from the firm's record instead of someone's memory.
- Visual business dashboard. A live view of the numbers leadership checks, replacing the status picture assembled by hand.
- Inbound content engine. The system reads industry content and surfaces suggestions, so business development starts from a stocked shelf instead of a blank page.
Underneath the five sits an execution layer of 24 automation scripts, including scrapers that watch municipal building permits and realtor listings and enrich what they find. Permit activity is an early signal of design work to come. The system reads it so a person does not have to.
How it runs
Custom front end, one database, serverless scripts
The front end is React and Vite rather than a template, because the dashboard and inbox had to match the firm's working patterns. Supabase holds the data layer, including the vector store behind the knowledge brain, on one instance owned by the engagement and isolated from everything else. Modal runs the 24 Python scripts on schedules, with no servers for anyone to maintain. Claude does the language work: triage judgments, draft replies, completeness checks, retrieval answers.
The whole thing runs on the same DOE architecture as every build we ship. Plain-text directives the team can read and edit, an orchestration layer that makes decisions, and deterministic scripts that do the work. The reasoning behind each tool is at /stack.
Under our Build + Educate model, the firm's team is learning the system while we ship it. They own the directives: triage rules, follow-up logic, dashboard definitions, all in plain text they can change without an engineering ticket. They are learning to check AI-drafted replies instead of trusting them, and to feed the knowledge brain the documents that make it better. When the build phase ends, the operating knowledge stays in the building.
The vendor-coordination and intake patterns here are productized as client onboarding and document automation. The knowledge brain is the same pattern as our own agency knowledge vault, which we run on ourselves. If you want your own baseline mapped before any build, start with the free audit.