I Built One Backend For My Entire Business With Claude

A business data backend is the thing most solo builders never build, because they rent it in pieces from five tools that never talk to each other. Two weeks ago I planned mine on camera. This episode is the build: one Postgres database on a single droplet, every platform wired into it, a privacy firewall baked in, and Claude Code reading the whole thing in plain language. The integrations were the easy part. Getting the shape right, so one person can ask the entire business a question and get a straight answer, was the real work. This article extracts the principles. The build is the case study.

Why this matters

I was paying forty to fifty dollars a month for Make.com, Airtable, and n8n to shuffle my data around, and I still could not answer the simplest questions about my own business. The data was there. It was just scattered, unsorted, and useless. So I shut it all down and built my own backend for about twenty five dollars a month. The savings were beside the point. What changed everything is that once every signal lives in one place, an AI on top of it stops being a novelty and becomes the most useful employee you have. Here is how the build actually went, mistakes included.

#1: Research every API before you write a line of integration code

The best decision I made was refusing to build first. Before any integration, I sent one research agent per external API to answer the same brief: what data is available, what is actually worth pulling for my business questions, the rate limits, and the gotchas. Five opinionated research docs came back before a single line of integration code existed.

That hour of research paid for itself three times over. It surfaced that MailerLite hides link-level click data, that Microsoft Clarity caps you at ten API calls a day, and that YouTube gates its impressions and click-through numbers behind a heavier reporting API that arrives a day late. Every one of those would have been an expensive discovery mid-build, the kind that forces a schema rewrite after you already have data in the table.

The prompt that did the work was deliberately not a menu request. I asked each agent to be opinionated, to cite sources, and to sketch a schema, not to list options for me to evaluate. A research agent told to recommend is worth ten told to summarize.

The portable rule: front-load API research with parallel agents and make them argue for a design. The surprises you find on paper are free. The ones you find in production cost a migration.

#2: Wiring a platform in is how you finally understand your own business

The integration I expected to be plumbing turned out to be the most valuable thinking of the whole project. The moment I started pulling MailerLite data into the backend, I had to look at what was actually in the API: open rate, click rate, open-to-click rate, bounce rate, source quality. I had used MailerLite for two years and never thought about those numbers as a system. Building the pipeline forced me to.

That is when it stopped being a data pull and became strategy. Once the subscriber data sat in one queryable place, I could see that of 96 active subscribers, roughly 70 were champions or engaged. I could cluster by where they came from and how they behaved. The integration did not just move data. It handed me the marketing and funnel questions I should have been asking all along.

In my coaching experience, founders treat their tools as places to do work, not as sources of truth about the business. The act of integrating a platform into one backend breaks that habit, because you cannot pipe data you do not understand. You are forced to learn your own numbers.

The portable rule: connecting a platform is a forcing function. Treat each integration as a chance to finally understand what that channel is telling you, not as a box to tick.

#3: Do not trust the API or the dashboard. Verify with one real action

Every platform lied to me in some small way, and only a real action ever caught it. With Google Analytics I wired the YouTube-to-signup attribution, and the rows came back empty. I assumed the bug was in my code. It was not. An edge redirect upstream was stripping the UTM parameters off the URL before any page script could read them. No unit test would have found that. Only clicking a real tagged link and watching a real signup land surfaced where the data was dying.

YouTube was worse. I almost keyed attribution to the video title, then realized the title changes every time I A/B test it. The stable identifier is the video id, resolved back to the title in the views. And the API simply cannot tell you when you swap a thumbnail, because the thumbnail URL never changes. The fix is to hash the image and watch the hash, otherwise you are blind to the exact test you are running. Instagram returned comment counts that incremented while the comment content came back empty, which turns out to be the precise signature of an app stuck in development mode, not a permissions error.

The portable rule: do not trust the dashboard or the docs. Walk the chain with one real action, and when a call comes back empty, research the real cause instead of guessing. Ten minutes of verification beats an hour running in circles.

#4: Put the privacy firewall below the AI, not in front of it

The moment you connect an AI to your business data, every name, email, and comment becomes one careless query away from a transcript or a screenshot. Policing prompts is hopeless. The boundary has to be a database role the AI reads with that physically cannot touch personal data. I built that boundary from day one: the read-only role is scoped to the analytics data only, no writes, no personal-data tables, and it reaches the database through a private tunnel rather than a public endpoint. When I ask the brain about my newsletter, I cannot see a single email address, by design.

In my coaching experience, the founders who get burned by AI assistants are not careless. They built the boundary at the application layer, where one bug or one prompt can step over it. The boundary belongs in the layer below the one being prompted. Postgres roles are that layer.

I did not just trust my own design here. I hired an independent reviewer, an agent told to act as a senior backend architect with no stake in the code, to audit the whole system adversarially. Its sharpest line was the one I needed: the design is better than the code. A control I had documented as done was not yet built, which is more dangerous than a known gap because it looks finished. The hardening sprint that followed is the reason I trust the firewall now.

The portable rule: the privacy boundary lives in the database role, not the prompt, and you verify it with an adversarial review before you point an AI at the data.

#5: One brain you can ask beats six dashboards you check

This is the part that still feels like magic. Once every source lived in one database with a read-only connection into the chat, analysis stopped being a script I had to write, deploy, and run. It became a question. I asked Claude to look at my Search Console, Analytics, and Clarity data and tell me which articles had impressions but no clicks. Six minutes later I had a report. I took the first article it flagged, one with 8.000 impressions and almost no clicks, changed it, and two days later it was pulling 50% more impressions.

That was one small question. The bigger finding came from the same place. With every page scored across search, behavior, friction, and conversions, one verdict repeated across nearly every top post: climb SEO. My top fifteen articles pull over 130.000 search impressions in a month with almost no conversions, because the whole library ranks just below the click zone. The highest-impact move was the post already ranking just outside the top five, the one closest to winning rather than the biggest in the library. The data named an opportunity I would not have picked myself, a launch-checklist cluster I had been underrating. You can see how I think about that surface in my product launch checklists guide.

In my coaching experience, most founders have more analytics than they will ever act on. The data is rarely missing. It just sits in tools they open out of guilt and close without a decision. One queryable brain turns a pile of numbers into a weekly to-do list.

The portable rule: stop building dashboards you check and build one source you can ask. Analysis you have to assemble by hand rarely happens. Analysis that is one question away gets done every week.

What is next

The backend is live and it never stops getting hungrier. As I write this I am wiring in Twitter threads and the next channels, and every product I touch, whether it is christianstrunk.com or the Product Bakery community I am building now, flows into the same database, separated by a tag. If you want the architecture decisions behind all of this, the planning session is its own episode: designing a backend for a one person AI company. This is where that plan became real. If you are mid-migration to AI-assisted building and want a second pair of eyes before you pour data into a shape you cannot easily change, that is exactly the kind of work I do in my product coaching engagements. Subscribe so the next channel lands when it goes live.