← Studio ZurichDon't buy Salesforce

Don't buy
Salesforce.

Alexander Schmidtpeter
Studio Zurich

Tech Talk
October 2026

Why we built a custom CRM →
01 / 30

The fine print

*…if you have the technical skills.

A standard CRM isn't bad

For standard sales with many seats, it's often the right call.

The math has changed

AI has dramatically lowered the cost of custom software.

Today: a decision framework

When does building pay off — and what do you need?
02 / 30

Agenda

What we'll cover in the next 30 minutes.

  1. 01The thesisWhy not an off-the-shelf CRM — and the fine print.02 min
  2. 02The caseA CRM as the company's operating system — and what buying would have cost.05 min
  3. 03What AI changedFour and a half months, one human, many agents: numbers, stack, ownership.06 min
  4. 04The catchSecurity, performance, control — so nothing ends up in the bin after six months.06 min
  5. 05Requirements firstTestable requirements, a hands-on exercise and a live demo.07 min
  6. 06Build or buy?Decision matrix, self-check and what you actually need.04 min
  7. →Q&AYour questions — anything goes.15 min

30 min talk · 15 min Q&A

03 / 30

Question for the room

Who here has worked with a CRM — HubSpot, Pipedrive & co.? And who is genuinely happy with it?

→ Show of hands

04 / 30

The case

A CRM that is really the company's operating system.

Contacts

buyers, partners, lenders

Properties & units

inventory, floor space, status

Offers

with a custom pricing engine

Projects & tasks

boards, teams, deadlines

MaBV

German regulatory duties

Property management

after the sale

Sales portal

a separate app for partners

PDF & email

offers, exposés, notifications
05 / 30

Question for the room

Your guess: what does it cost to customize a CRM until it fits this company — over the first three years?

→ Show of hands

06 / 30

The classic path

Buy, customize, customize, customize.

  1. 01

    Per-seat licenses

    plus add-ons for portal, CPQ, data

  2. 02

    Implementation partner

    discovery, concept, customizing

  3. 03

    Custom objects & Apex

    for every piece of domain logic

  4. 04

    Change requests

    for every new requirement

Ballpark · assumption

6–7

figures in the first three years

Licenses, implementation partner, add-ons and ongoing change requests — before the first custom process is properly in place.

07 / 30

The customization paradox

You pay to make standard software feel custom.

BREAK-EVENSAAS + CUSTOMIZINGBUILT WITH AISTANDARDCUSTOM →COST

Schematic, not to scale.

08 / 30

Question for the room

And building it yourself: how many people and how much time does a system like this take?

→ Show of hands

09 / 30

What changed

AI flipped the math.

Building · before

5–10 developers

12–24 months to a first version

Expensive, slow, risky

→ Buying was almost always the sensible choice.

Building · today

1 senior + AI agents

Weeks to the first module in production

Iterations in days, not change requests

→ The question is no longer “can we?” but “are we willing to own it?”

10 / 30

The proof · real numbers from the repo

Four and a half months. One human. Many agents.

4.5

months from zero to production

1

developer — plus Claude as the team

976

commits

233

merged pull requests

~200k

lines of TypeScript

89

database tables

191

migrations

2

apps: internal + sales portal

11 / 30

The stack

Boring technology. On purpose.

Frontend

Next.js 16 · React 19

Two apps in a monorepo (Turborepo), shared UI kit.

Data

Postgres via Supabase

Auth, storage, row-level security. The database decides who sees what.

Operations

Vercel + CI/CD

Staging, preview deployments, protected migrations.

Domain logic

Custom packages

Pricing engine, PDF generation, email, i18n.

Quality

Gates, not hope

Types, tests, database tests, migration rules.

AI

Claude Code

Agents work by fixed house rules in the repo (AGENTS.md).
12 / 30

Ownership

Code owner, not licensee.

  • Your data is yours

    Plain Postgres. No export ticket, no lock-in.

  • No per-seat pricing

    New users cost next to nothing.

  • Features in days

    Not in the vendor's next release cycle.

  • Ask in plain language

    AI writes the SQL — directly on your data.

Plain language → SQL

› How many offers are open right now?

select count(*) from offers
where status = 'open';

› Which contacts did we gain this month?

select name from contacts
where created_at >= date_trunc('month', now());

› Which units are still available?

select name from units
where status = 'available';

Illustrative example

13 / 30

Division of labor

AI writes the code. You build the guardrails.

AI agents

Implementation across all layers

Migrations, tests, types

Refactorings in minutes

Research in the official docs

Human

Architecture & data model

Domain knowledge & priorities

House rules, gates, reviews

Accountability for operations

AI without guardrails = a lot of technical debt, very fast.

14 / 30

Question for the room

What goes wrong first if you just let AI agents do their thing?

→ Shout it out

15 / 30

The catch

Agents build fast. Including the wrong things.

Without control · after 6 months

✕Three versions of the same function

✕Permission logic scattered across app code

✕Pages that collapse under real data

✕Nobody dares to change anything

With control

✓One data model, one source of truth

✓Permissions in the database — tested

✓Performance measured at production scale

✓Every change checked by gates

01

Security

02

Performance

03

Control

16 / 30

Pillar 1 · Security

Security belongs in the database, not in the prompt.

  • Permissions in Postgres

    Row-level security decides who sees which row — not the app code.

  • Every function registered

    One central permissions package. If an entry is missing, the tests fail.

  • Identity from the server

    Who acts comes from the session — never from the form.

  • Dangerous commands disabled

    Production only via the protected pipeline.

Real, from the repo · package.json

"db:deploy:hosted":
  "echo 'ABORTED: use the protected GitHub staging workflow.' && exit 1",
"db:link":
  "echo 'ABORTED: linking to a remote project from local is forbidden. CI links inside the runner.' && exit 1",
"db:secrets":
  "echo 'ABORTED: setting Supabase secrets from local is forbidden. …' && exit 1",

→ No agent can touch production by accident.

17 / 30

Pillar 2 · Performance

Working is not the same as scaling.

  • Agents optimize for “it works”

    Not for “it works with 100,000 records and 50 concurrent users”.

  • Measure at production scale

    Staging never has production's data volume — benchmarks run with realistic volume.

  • Trace load back to the click

    Every expensive query has a cause in the frontend, e.g. overly aggressive prefetching.

  • Heavy work out of the request

    Images, PDFs and exports run in the background — not while someone waits.

Real, from the repo · package.json

"db:benchmark:contacts":
  "node scripts/test-database-local.mjs benchmark",
"db:benchmark:tasks":
  "node scripts/test-database-local.mjs benchmark-tasks",

→ Performance is a test, not a hope.

18 / 30

Pillar 3 · Control

House rules as code — not as a request.

  • AGENTS.md

    The working agreement every agent reads first — with clear MUST rules.

  • Gates, not trust

    Types, lint, source and database tests check every change automatically.

  • No exceptions

    No allowlists, no “temporary” workarounds — root causes get fixed.

  • The human approves

    No commit, no push, no merge without an explicit OK.

Real, from the repo · AGENTS.md (excerpt)

# AGENTS.md
The working agreement every agent and human reads first.

- MUST NOT commit, push, or merge without the user's
  explicit approval of that exact change set.
- MUST let registered database enforcement decide
  authorization; MUST NOT recreate row permission
  logic in application code.
- MUST fix root causes with durable solutions […];
  MUST NOT introduce temporary workarounds or
  bypass safeguards.

45

MUST rules

355

test files

4

git hooks

19 / 30

Question for the room

What makes a good discovery for you?

→ Show of hands

20 / 30

Requirements first

The most expensive problem isn't the code — it's the misunderstanding.

  1. 01

    Elicit

    Interviews, observation, existing workflows.

  2. 02

    Analyze

    What's a must, what's a wish?

  3. 03

    Specify

    User story and testable acceptance criteria.

  4. 04

    Validate

    With a prototype and real users — before building.

Real, from the repo · issue template (excerpt, translated)

## Goal / user story
As a … I want …, so that …

## Scope and non-goals
- Included in this step: …
- Explicitly not included: …

## Acceptance criteria
- [ ] When …, then …

## Open decisions
Assumptions are not approvals.

→ A captured issue is not yet approval to build.

21 / 30

Your turn · requirement check

What's wrong with these requirements?

22 / 30

From conversation to prototype

You validate requirements with prototypes — not documents.

  1. 01 →ConversationNotes from the meeting with the business.
  2. 02 →User storyClaude writes the story and acceptance criteria.
  3. 03 →PrototypeClaude Design builds a clickable mockup.
  4. 04 →FeedbackThe business clicks through — the same day.
  5. 05BuildClaude Code implements — under the house rules.

The bottleneck is no longer building — it's a clear requirement.

23 / 30

Live demo · briefing from the business

From briefing to prototype — live.

Context

  • Mid-sized B2B provider of software for manufacturing, about 40 employees.
  • Six people in sales — today everyone works with Excel and Outlook.

Goal

  • No lead gets lost anymore.
  • Every morning, sales sees what's due today — management sees the forecast.

Roles

  • Sales: maintains leads and opportunities.
  • Head of sales: approves large offers and owns the forecast.
  • Marketing: delivers leads from the website, trade fairs and campaigns.

Workflow

  • 1 · Capture a lead — source, company, contact person.
  • 2 · Qualify by budget, need, decision-maker and timeline.
  • 3 · Create an opportunity with value and probability.
  • 4 · Stages: first meeting → offer → negotiation → won or lost.
  • 5 · Every opportunity gets a next step with a due date.

Business rules

  • Every open opportunity needs a next step with a date.
  • Offers from CHF 50,000 require approval by the head of sales.
  • Lost opportunities need a loss reason.

KPIs

  • Pipeline value per stage
  • Weighted forecast for the quarter
  • Conversion lead → customer
  • Overdue next steps

Prototype

  • Lead list with scoring
  • Pipeline as a kanban board
  • Opportunity detail view with activities
  • “My day” start page for sales

Turn this into a clickable prototype with realistic sample data.

24 / 30

The honest trade-off

Building means: you own the responsibility.

Security

Auth, permissions, updates, pen tests.

Operations

Monitoring, backups, incidents.

Compliance

GDPR / Swiss FADP, retention, audit.

Bus factor

What if that one person is gone?

Maintenance

Framework updates never stop.

No ecosystem

No ready-made marketplace apps.
25 / 30

Vote

And you? Buy or build — what would you decide for this company?

→ Show of hands — I'll count.

Buy

0

Hybrid

0

Build

0

0 votes

26 / 30

Decision matrix

Build or buy?

Technical capability →

Standard · strong

Buy + integrate

Don't build. Build integrations and automations around it.

Unique · strong

Build your own

This is where competitive advantage lives. Exactly our case.

Standard · weak

Buy

Pipedrive, HubSpot & co. — adapt your process to the tool.

Unique · weak

Network / partner

Find technical partners — or budget for an enterprise CRM plus an implementer.

Process uniqueness →

27 / 30

Self-check · click along

When should you consider building your own?

Score

0/7

Buy

Use Pipedrive, HubSpot or another off-the-shelf CRM and adapt your processes.

28 / 30

Prerequisites

What you actually need.

01

One accountable person

Senior, owning product and architecture.

02

Domain expertise in the room

Someone from the business who tests every week.

03

Managed infrastructure

Postgres, auth, hosting — don't run it yourself.

04

Guardrails as code

Tests, CI, migration rules, house rules for agents.

05

A first slice

One module in production, then iterate — no big bang.

29 / 30

Don't buy
Salesforce.

Do the math first.

Questions?
studio-zurich.ch

30 / 30