The CRM I built three times.

01 · Discovery

The problem

My business runs in Hebrew and in shekels, across leads, quotes, orders, projects and billable hours. The CRMs I tried were built for someone else: generic pipelines, English first, and a monthly bill for features I never opened.

I wanted one place where a lead becomes an opportunity, then an order, then a project with its hours, without copying anything by hand.

• Lead to order to project
• Hebrew first, shekels native
• One place, no copying

02 · Two false starts

Two CRMs that didn't survive

The first attempt took a week. I prompted screens one after another: a dashboard, leads, deals, a calendar, a price calculator. Fifteen pages looked finished. The moment they had to run on a real database, it came apart: fix loops, then rollbacks, until two pages were left.

The second started from a better interface and even a full database design, fifteen tables with roles and permissions. But the screens still ran on sample data, and the two were never connected. Both failed for the same reason.

1. 2025 · one week

   Attempt 1

   Fifteen screens prompted one by one, on sample data.

   Came apart on a real database.

2. Late 2025

   Attempt 2

   A new interface, and a fifteen table design beside it.

   Never connected, never used.

3. 2026 · six months

   OneCRM OS

   The plan first, then the screens, on real data from day one.

   Runs my business every day.

03 · Blueprint

Structure first, this time

Between the second and third attempts, the Vibe Arc method took shape, and Studio proved it on my own product. So OneCRM OS started where the others never did: with the data model and how every record connects, agreed before a single screen.

Then the modules came in order, each on real data from the first day, and a build tracker became the source of truth for every phase, task and prompt. The modules are the same ones I wanted in 2025. What changed was the order.

• Data before screens
• Real data from day one
• One tracker for every phase

04 · What broke

Five problems, and how I fixed them

1. One open tab ran the database hot.

   A browser tab left open kept asking the database for updates, about 21,000 requests a day, until it hit its limits and started timing out.

   The fix: Background tabs now stop asking, nine queries became one, and updates arrive live instead of on a timer. Hourly load dropped from about 1,000 requests to 70.

2. The first diagnosis was wrong.

   The obvious fix for slow queries was more indexes, so I added twelve.

   The fix: Then I measured. Every table was small enough to live in memory, and eleven of the twelve indexes were never used. I cancelled the rest of that plan: measure before you fix.

3. Security came in waves.

   A tool that holds client data needs more than a login. Reviews kept finding gaps: data that could cross between workspaces, a calendar sync that skipped a check, server functions that said too much.

   The fix: Each gap was closed where it lives: isolation enforced in the database itself, public sign up switched off, and every database function locked down by default.

4. Ten minutes became ten hours.

   The hours and minutes switch on time entries reset itself, so a quick 10 minute entry was saved as 10 hours and quietly inflated a project.

   The fix: The app now remembers the unit you chose and warns you when an entry looks implausible.

5. Two screens, two revenues.

   The dashboard and the analytics page disagreed on revenue: one counted by payment date, the other by order date.

   The fix: Every metric is now calculated once, in one place, and each screen only displays it.

Two CRMs failed for the same reason: I built screens before structure.

05 · Result

Where it stands today

6

months building the version that stuck

1,792

commits, shipped in small steps

21

screens, from first lead to final payment

21

tools for its AI assistant, in the app and in Telegram

OneCRM OS runs my business every day. Leads arrive through Telegram, quotes become orders, time rolls up from task to project to order, and a morning digest tells me what needs attention.

It is internal for now. The same method that finally made it work is the one I use to build tools for clients.