How We Built Bigpop.ai — Inside Our Multi-Agent Marketing CRM

Bigpop.ai is the AI marketing platform that runs our own agency, and it's also a productised SaaS we sell to other agencies. This post is the technical companion to the case study.

Why we built our own

We started Bigpop.ai with off-the-shelf tooling. HubSpot for CRM, Lovable for demo generation, Jasper for copy, Canva for socials. By month four we'd hit three problems:

1. No shared context. Every tool wanted its own version of "this lead." Sales notes lived in HubSpot; demo URLs in Lovable; outreach drafts in Jasper. Stitching them together was 6 hours/week of manual work.
2. Per-seat pricing taxed scale. We hired our second AE; SaaS bill jumped $980/month.
3. No customisation. When we wanted to tweak how a demo was generated, we couldn't. Lovable's prompt was a black box.

So we shipped our own.

The architecture

A single Next.js 16 app deployed to Cloudflare Workers via OpenNext. Database is Neon Postgres (Sydney region). The AI layer is Gemini 3 Flash for text and Gemini 3 Pro Image for images.

[Next.js App] → [Cloudflare Worker] → [Neon Postgres]
                      ↓
               [Multi-Agent Orchestrator]
              ↓                ↓               ↓
   [Lead Sourcing]    [Demo Generator]   [Content Pipeline]

There are five primary agents, each scoped narrowly:

• LeadSourcingAgent — given an ICP brief, returns N qualified company records.
• WebsiteAnalysisAgent — given a URL, returns design + marketing scores + opportunity list.
• DemoGenerationAgent — given a lead, generates a personalised redesigned demo page.
• ContentGenerationAgent — given a brief, returns a social or blog post.
• OutreachAgent — given a lead with prior context, returns a personalised outreach email.

The orchestrator isn't fancy — it's a TypeScript class that holds a Prisma instance, calls each agent, and writes structured output back to the database with a token-usage log.

Why narrow agents beat one fat agent

Early on we tried a single mega-prompt that did the whole pipeline. It worked maybe 60% of the time. The failure mode was always the same: as the prompt grew, the model started skipping or merging steps.

Splitting into five specialised agents took us from 60% to ~94% reliable end-to-end. Each agent has a tight schema (we use Zod) and a bounded scope. Failures are easy to inspect — the orchestrator logs which step broke.

Token usage as a first-class concept

Every AI call writes a row to a UsageRecord table. Every record has a client ID, an agent type, and the token counts. This means we can show, in real time, what a given client is costing us in raw model spend.

It also means we can price intelligently. We know our gross margin per generated lead within ±3 cents. That's an unfair advantage when negotiating retainers.

Edge deployment was non-trivial

Next.js 16 + Cloudflare Workers via @opennextjs/cloudflare works — but only if you keep two things in mind:

1. No native Node modules. bcrypt is out (replaced with bcryptjs). node-cron is out (use Cloudflare Cron Triggers).
2. Prisma needs the Neon serverless adapter. Standard Prisma client opens TCP connections; Workers don't allow them. Switch to @neondatabase/serverless for the data driver.

Once those two are right, the rest is the same Next.js you'd ship anywhere — just deployed via wrangler deploy to a Worker, with custom domains attached.

Where we'd do it differently

Two things, in hindsight:

1. Start with the data model, not the agents. We rewrote our Lead schema four times. Every rewrite cost a day of agent re-prompting. Spend a week on the schema before you write the first agent.
2. Build the cost dashboard before the second agent. We added it in month three. Should have been month one. Without per-agent token economics, you'll over-engineer the wrong agents.

What's next

Currently shipping a public API so other agencies can plug into the same orchestration layer with their own data. If you want early access, contact us.

If you want the full case study, read it here.