The Build-vs-Buy Math Changed and Nobody Told You

If you run a small company, you know the subscription ritual. Chat is one tool. Tasks are another. Notes live somewhere else. The CRM is its own island. Leave requests happen over WhatsApp and get forgotten. Every one of these charges per user per month, and every one of them holds a different slice of your business data hostage in its own silo.

For a team of fifteen, a modest stack — a chat tool, a task manager, a notes workspace, a lightweight CRM, an HR tool for leave — runs $35–50 per user per month once you're past the crippled free tiers. That's $6,000–9,000 a year, forever, for tools that were designed for someone else's business and integrated with each other through duct tape, if at all.

We stopped paying it. Over the past several months, my company replaced that entire stack with one application we built ourselves. It started as a WhatsApp replacement for internal chat. It is now the productivity suite the whole company runs on. This post is about how that happened, what it actually costs, and — more usefully — why the build-vs-buy threshold has moved far enough that you should at least re-run the calculation for your own business.

Where we started

Dolphin Infotek is a twelve-person software company. We build compliance software for Indian capital markets — so we're technical, but we're not a product team with spare capacity. Like everyone else, our internal operations ran on a patchwork: WhatsApp for team chat (with all the personal/professional bleed that implies), a task tracker we'd built years ago, notes scattered across devices, a legacy CRM that nothing else could see, and a shared Outlook mailbox that two people triaged by hand.

The breaking point wasn't any single tool. It was the seams between them. A client emails a problem → someone pastes it into WhatsApp → someone else creates a task → the task knows nothing about the email → three weeks later nobody can reconstruct what happened. Every seam was manual work, and every manual step was a place where things fell through.

What we built

DolphinChat began with a narrow goal: get work chat out of WhatsApp. Flutter for the client (one codebase, and today it genuinely runs on iOS, Android, Windows, macOS, and the web), Supabase for the backend — managed Postgres, auth, realtime, storage, and serverless functions for one flat fee.

The chat part took shape quickly: channels, DMs, reactions, file sharing, even a one-time import of our WhatsApp history so nothing was lost. But the interesting thing happened after chat worked. Because everything sat in one Postgres database, every next feature was suddenly cheap:

• Channels tied to business objects. A channel isn't just a chat room — it can be linked to a client or a product. Slack can't do this, not because it's hard, but because Slack doesn't know what your clients are.
• Tasks from anywhere. Long-press a chat message → it becomes a task, assigned and linked back to the conversation. Emails in the shared mailbox become tasks automatically; when the handling agent files the mail into a "completed" folder, the task closes itself.
• Notes and a scribble pad. Rich-text notes, plus an Apple Pencil canvas for the iPad users. Notion subscription: cancelled.
• Leave management. Apply in the app, the approver gets a push notification, the announcement posts to the company channel. The entire "HR tool" category, which for a 12-person firm is 90% leave tracking, turned out to be one screen and two tables.
• Email intelligence. The shared mailbox syncs into the same database. AI classifies each incoming mail, a live client-status board tracks who's waiting on us, and every morning a scheduled AI agent reads the previous day's client emails and posts a status report — reds first — into the announcements channel before I've had coffee.
• CRM integration. Our legacy CRM syncs in daily. Client channels, client emails, client tasks, and client status all join up on one key. No Zapier, no webhooks between vendors, no "integration marketplace." Just SQL.
• An assistant that sees everything. Because chat, tasks, knowledge base, and emails share one database, the in-app AI assistant can answer "what's pending for client X?" with actual knowledge, and create or close tasks from a conversation.

None of these features would justify a standalone product. Together, wired into each other, they're worth more than the stack they replaced — because the integration is the product. That's the part you can't buy: SaaS vendors integrate at the seams, grudgingly. A shared database integrates at the core.

The honest math

What it costs to run: Supabase's paid tier at $25/month covers the database, auth, realtime, file storage, and every backend function. Web hosting is effectively free. Push notifications are free. The AI features run on API calls that cost us a few dollars a month at our scale. Apple's developer program is $99/year. Call it under $600 a year in infrastructure — versus the $6,000–9,000 SaaS equivalent, with headroom: user sixteen costs us nothing.

Now the part most "we built our own tools" posts skip: the costs that aren't subscriptions.

Building took real time. Months of iterative releases, built alongside running the company — not a weekend project. The reason it was possible at all is the same reason this post exists: AI-assisted development has changed what one busy person can ship. The recent two-factor authentication feature — TOTP enrollment, QR codes, admin controls, enforcement in database policy, deployed to all platforms — went from "we should have MFA" to shipped in roughly a day of working with Claude Code. Three years ago that alone would have been a fortnight, and the whole project wouldn't have started.

Maintenance is yours. When the Windows build broke against a new Flutter release, that was my evening. When a migration deadlocked against live traffic, mine too. Budget ongoing attention, not just the build.

Security becomes your job — genuinely. A SaaS vendor gives you SOC 2 paperwork and someone to sue. When you self-build, you are the security team. We take it seriously: row-level security on every table, per-user two-factor auth enforced at the database (not just in the UI, because a UI check is a suggestion), signed URLs for files, and a monthly automated security review that audits our own endpoints and keys — run, fittingly, by a scheduled AI agent. If your reaction to that paragraph is discomfort rather than a to-do list, that's a signal to keep buying.

Should you do this?

Not automatically. Here's the honest filter:

Buy, if you have zero development capability in-house and no appetite to acquire it; if your compliance regime demands vendor SLAs; or if your team is 100+ people where mature admin tooling starts earning its price.

Seriously consider building, if you're 5–30 people, at least one person can code (with AI assistance doing the heavy lifting), and — this is the real test — your daily pain is the seams between tools, not any single tool. Nobody should build their own Slack because Slack is expensive. You build because a chat message should become a task, a task should know its client, and a client should surface its emails — and no combination of subscriptions will ever give you that for your business objects.

If you do proceed, the playbook that worked for us:

1. One database from day one. This is the whole trick. Every feature you add joins against everything you already have. Supabase (or plain managed Postgres) makes this a solved problem.
2. Start with the highest-pain workflow, not the fanciest. For us that was getting chat out of WhatsApp. Ship that one thing, get the team living in it daily, and let real complaints pick the next feature.
3. One cross-platform codebase. Flutter or similar. Your team is on iPhones, Windows laptops, and browsers; maintaining three apps kills the economics.
4. Ship weekly to your own team. Your users sit next to you and can't churn. There is no better product feedback loop on earth.
5. Treat security as a feature you ship, not a property you assume. Do the boring work: RLS, MFA, key hygiene. Automate the auditing.
6. Let AI agents run the operations, not just write the code. Our daily client report, weekly ops brief, and monthly security review are all scheduled agents working against the same database. The suite doesn't just hold data — it works the data.

Where this ends up

Eighteen months ago, our internal tooling was a cost line and a source of friction. Today it's an asset: software shaped exactly like our business, that costs almost nothing to run, improves every week, and — because every feature compounds on a shared foundation — gets cheaper to extend over time, not more expensive.

The subscription stack made sense in a world where building was expensive. That world is ending. If you're an entrepreneur re-signing five renewal invoices this quarter for tools that still don't talk to each other, the most useful thing I can tell you is: the calculation has changed. Run it again.

I write about building software and a software company at the same time. If you want the technical deep-dives behind this post — the Supabase RLS migration, the MFA implementation, the AI agent routines — they're coming as separate articles. Subscribe if that's your kind of thing.