A founder asked me last month whether they should build their own CRM.

The honest answer was: it depends. But not in the vague, hand-wavy way people usually mean. It depends on specific, mappable things. Things you can write down before you spend a single dollar.

The build-vs-buy question sounds like a technology decision. It isn’t. It’s a systems decision about who owns the process, who maintains it, and what happens when something breaks at 2 AM on a Sunday.

When buying works

Off-the-shelf tools are excellent when the process they serve is standard. If your sales pipeline follows the same shape as ten thousand other companies, a $20/month Notion workspace or a $50/seat Airtable base will handle it. You don’t need a custom database for a process that already has a name.

Buying works when:

• The process is common. CRM, project management, invoicing, basic reporting. These are solved problems. The tool already exists because thousands of businesses needed the same thing before you.
• The team is small. Five people can adapt to a tool’s constraints. They learn its quirks, work around its edges, and move on. The friction is manageable.
• Flexibility matters more than control. You want to change the workflow next quarter without rewriting code. Drag-and-drop beats deployment pipelines when the requirements shift monthly.
• Nobody can maintain custom software. This is the one most people skip. If nobody on your team can debug a Postgres query or update an API endpoint, a custom tool becomes a liability the moment the person who built it leaves.

Most businesses should start here. Not because off-the-shelf tools are better, but because buying is reversible. Building usually isn’t.

When building works

Custom tools earn their cost when the off-the-shelf option requires more workarounds than actual work.

Building works when:

• The process is genuinely unique. Not “we’re special” unique — structurally unique. Your data model doesn’t fit standard columns. Your workflow has branching logic that no template accounts for.
• Data ownership matters. You need to control where data lives, who accesses it, and how it’s backed up. A Supabase instance with proper row-level security is a different thing than a shared Airtable base where anyone with the link can export everything.
• The workaround ratio exceeds 40%. If you’re spending 40% of your time in the tool working around the tool, you don’t have a tool. You have a constraint dressed as a solution.
• Maintenance capacity exists. Either someone on the team can maintain the system, or you’ve budgeted $200/month for someone who will. Without this, custom tools decay on a predictable timeline.

The math is straightforward. A custom internal tool might cost $2,000 to build and $200/month to maintain. A SaaS tool might cost $20/month per seat. At ten seats, you’re paying $200/month either way — but one of them fits your process exactly and the other one almost does.

“Almost” is where the real cost hides.

The hidden cost of buying

Workarounds accumulate. They’re small at first. A manual step between two automations. A Notion page that should update automatically but doesn’t. A Zapier chain that breaks every month and takes an hour to debug.

Each workaround is trivial. Together, they form a parallel system — an invisible layer of manual labor that holds the official system together. Nobody documents it. Nobody accounts for the time it consumes. It just exists, distributed across the team, eating hours that never show up in any report.

The Airtable automation that doesn’t quite trigger correctly. The Monday.com board that requires someone to manually move cards because the status logic doesn’t match reality. The Google Sheet that someone maintains alongside the “real” system because the real system can’t produce the report the CEO wants.

This is the tax on buying. It’s real, and it compounds.

The hidden cost of building

Custom tools need maintenance. Not occasionally — continuously. APIs change. Dependencies update. The business evolves and the tool doesn’t, unless someone makes it evolve.

If nobody maintains the custom tool, it becomes the exact same problem it was built to solve. A rigid system that doesn’t match how work actually happens. Except now it’s worse, because there’s no vendor to call, no community forum to search, and no upgrade path.

I’ve seen custom tools go from “this changed everything” to “nobody uses it” in under a year. Not because they were badly built. Because nobody was responsible for keeping them alive.

The build decision is also a maintenance decision. If you can’t answer “who maintains this after it ships?” — don’t build it.

The decision framework

Before choosing a tool, map the process. Not the dream process. The real one. The one with the exceptions, the edge cases, and the step where someone calls another person because the system can’t handle what just happened.

Then ask three questions:

1. Does a standard tool cover 80% or more of this process? If yes, buy. Accept the 20% gap. It’s cheaper than maintaining custom software.
2. Is the remaining gap causing real cost? Not annoyance — cost. Lost revenue, compliance risk, hours that should go elsewhere. If the gap is just inconvenient, live with it.
3. Can you maintain what you build? Not “can you build it” — can you maintain it? Building is a one-time event. Maintenance is forever.

Most businesses should buy first. Use the tool until buying breaks. When buying breaks — when the workarounds cost more than the subscription, when the data model can’t hold what the business needs, when the gap between the tool and the process becomes a structural problem — then build.

Not before.

The founder’s answer

The founder who asked about building a CRM? They didn’t build it. Their sales process was standard. Their team was six people. Nobody on staff could maintain a database.

They bought a $30/seat CRM, added two Zapier automations, and moved on with their quarter.

Six months later, their onboarding process — which was genuinely unique — broke every project management tool they tried. They built a custom onboarding system on Supabase. It cost $3,000. Their operations lead maintains it.

Both decisions were right. Because they understood the system before they chose the tool.

---

Related

• Service: Operational Systems & Backend Architecture — Backend architecture, automation pipelines, and AI workflows.
• Article: The Difference Between Automation That Helps and Automation That Compounds — Why most automation doesn’t stick, and what makes the difference.
• Article: Workflow Automation vs Systems — Why automating a broken process just breaks faster.

---

Hrvatski

Jedan osnivač me prošli mjesec pitao treba li izgraditi vlastiti CRM.

Iskren odgovor bio je: ovisi. Ali ne na onaj maglovit način kako ljudi obično misle. Ovisi o specifičnim, mapljivim stvarima. Stvarima koje možete zapisati prije nego što potrošite i jednu kunu.

Pitanje izgraditi-ili-kupiti zvuči kao tehnološka odluka. Nije. To je sustavna odluka o tome tko je vlasnik procesa, tko ga održava i što se događa kad se nešto pokvari u 2 ujutro u nedjelju.

Kada kupnja funkcionira

Gotovi alati su izvrsni kada je proces koji služe standardan. Ako vaš prodajni lijevak prati isti oblik kao deset tisuća drugih tvrtki, Notion radni prostor od 20 dolara mjesečno ili Airtable baza od 50 dolara po korisniku će to obaviti. Ne trebate prilagođenu bazu podataka za proces koji već ima ime.

Kupnja funkcionira kada:

• Proces je uobičajen. CRM, upravljanje projektima, fakturiranje, osnovni izvještaji. To su riješeni problemi. Alat već postoji jer su tisuće tvrtki trebale istu stvar prije vas.
• Tim je malen. Pet ljudi se može prilagoditi ograničenjima alata. Nauče njegove posebnosti, zaobilaze rubove i nastavljaju dalje. Trenje je podnošljivo.
• Fleksibilnost je važnija od kontrole. Želite promijeniti tijek rada sljedeći kvartal bez prepisivanja koda. Povuci-i-ispusti pobjeđuje procese implementacije kada se zahtjevi mijenjaju mjesečno.
• Nitko ne može održavati prilagođeni softver. Ovo je ono što većina ljudi preskoči. Ako nitko u vašem timu ne može otkloniti grešku u Postgres upitu ili ažurirati API endpoint, prilagođeni alat postaje obveza onog trenutka kad osoba koja ga je izgradila ode.

Većina tvrtki bi trebala početi ovdje. Ne zato što su gotovi alati bolji, nego zato što je kupnja povrativa. Izgradnja obično nije.

Kada izgradnja funkcionira

Prilagođeni alati opravdavaju svoju cijenu kada gotova opcija zahtijeva više zaobilaženja nego stvarnog rada.

Izgradnja funkcionira kada:

• Proces je zaista jedinstven. Ne “mi smo posebni” jedinstven — strukturno jedinstven. Vaš podatkovni model ne stane u standardne stupce. Vaš tijek rada ima razgranatu logiku koju nijedan predložak ne pokriva.
• Vlasništvo nad podacima je bitno. Trebate kontrolirati gdje podaci žive, tko im pristupa i kako se sigurnosno kopiraju. Supabase instanca s pravilnom sigurnošću na razini redaka je drugačija stvar od dijeljene Airtable baze gdje svatko s linkom može izvesti sve.
• Omjer zaobilaženja prelazi 40%. Ako 40% svog vremena u alatu trošite na zaobilaženje alata, nemate alat. Imate ograničenje prerušeno u rješenje.
• Kapacitet za održavanje postoji. Ili netko u timu može održavati sustav, ili ste predvidjeli 200 dolara mjesečno za nekoga tko hoće. Bez toga, prilagođeni alati propadaju po predvidljivom rasporedu.

Matematika je jasna. Prilagođeni interni alat može koštati 2.000 dolara za izgradnju i 200 dolara mjesečno za održavanje. SaaS alat može koštati 20 dolara mjesečno po korisniku. S deset korisnika, plaćate 200 dolara mjesečno u oba slučaja — ali jedan od njih točno odgovara vašem procesu, a drugi skoro odgovara.

“Skoro” je mjesto gdje se skriva pravi trošak.

Skriveni trošak kupnje

Zaobilaženja se nakupljaju. Na početku su mala. Ručni korak između dvije automatizacije. Notion stranica koja bi se trebala automatski ažurirati, ali se ne ažurira. Zapier lanac koji se kvari svaki mjesec i treba sat vremena za popravak.

Svako zaobilaženje je trivijalno. Zajedno, tvore paralelni sustav — nevidljivi sloj ručnog rada koji drži službeni sustav na okupu. Nitko ga ne dokumentira. Nitko ne računa vrijeme koje troši. Jednostavno postoji, raspodijeljen po timu, jedući sate koji se nikad ne pojave ni u jednom izvještaju.

Airtable automatizacija koja se ne aktivira baš kako treba. Monday.com ploča koja zahtijeva da netko ručno pomakne kartice jer logika statusa ne odgovara stvarnosti. Google Sheet koji netko održava uz “pravi” sustav jer pravi sustav ne može proizvesti izvještaj koji direktor želi.

To je porez na kupnju. Stvaran je i raste s vremenom.

Skriveni trošak izgradnje

Prilagođeni alati trebaju održavanje. Ne povremeno — kontinuirano. API-ji se mijenjaju. Ovisnosti se ažuriraju. Posao evoluira, a alat ne, osim ako ga netko ne prilagodi.

Ako nitko ne održava prilagođeni alat, on postaje točno isti problem koji je trebao riješiti. Krut sustav koji ne odgovara načinu na koji posao zapravo funkcionira. Osim što je sada gore, jer nema dobavljača za nazvati, nema foruma zajednice za pretražiti i nema puta nadogradnje.

Vidio sam prilagođene alate koji su od “ovo je sve promijenilo” došli do “nitko to ne koristi” u manje od godinu dana. Ne zato što su bili loše napravljeni. Nego zato što nitko nije bio odgovoran da ih održi živima.

Odluka o izgradnji je ujedno i odluka o održavanju. Ako ne možete odgovoriti na pitanje “tko ovo održava nakon što se isporuči?” — nemojte graditi.

Okvir za odluku

Prije odabira alata, mapirajte proces. Ne idealni proces. Stvarni. Onaj s iznimkama, rubnim slučajevima i korakom gdje netko zove drugu osobu jer sustav ne može obraditi ono što se upravo dogodilo.

Zatim postavite tri pitanja:

1. Pokriva li standardni alat 80% ili više ovog procesa? Ako da, kupite. Prihvatite 20% praznine. Jeftinije je od održavanja prilagođenog softvera.
2. Uzrokuje li preostala praznina stvaran trošak? Ne dosadu — trošak. Izgubljeni prihod, rizik usklađenosti, sati koji bi trebali ići drugamo. Ako je praznina samo neugodna, živite s njom.
3. Možete li održavati ono što izgradite? Ne “možete li to izgraditi” — možete li to održavati? Izgradnja je jednokratni događaj. Održavanje je zauvijek.

Većina tvrtki bi trebala prvo kupiti. Koristiti alat dok kupnja ne prestane funkcionirati. Kada kupnja prestane funkcionirati — kada zaobilaženja koštaju više od pretplate, kada podatkovni model ne može držati ono što posao treba, kada praznina između alata i procesa postane strukturni problem — tada gradite.

Ne prije.

Osnivačev odgovor

Osnivač koji je pitao o izgradnji CRM-a? Nije ga izgradio. Njihov prodajni proces bio je standardan. Tim je imao šest ljudi. Nitko u tvrtki nije mogao održavati bazu podataka.

Kupili su CRM za 30 dolara po korisniku, dodali dvije Zapier automatizacije i nastavili s kvartalom.

Šest mjeseci kasnije, njihov proces uključivanja novih klijenata — koji je bio zaista jedinstven — slomio je svaki alat za upravljanje projektima koji su isprobali. Izgradili su prilagođeni sustav uključivanja na Supabaseu. Koštao je 3.000 dolara. Njihov voditelj operacija ga održava.

Obje odluke bile su ispravne. Jer su razumjeli sustav prije nego što su odabrali alat.

---

Povezano

• Usluga: Operativni sustavi i backend arhitektura — Backend arhitektura, automatizacijski cjevovodi i AI tijekovi rada.
• Članak: Razlika između automatizacije koja pomaže i automatizacije koja se kumulira — Zašto većina automatizacije ne opstaje i što čini razliku.
• Članak: Automatizacija tijeka rada nasuprot sustavima — Zašto automatiziranje pokvarenog procesa samo brže kvari.