Ten BEMER distributors. Rental devices tracked in Excel. A month-end reconciliation that used to eat a full day. We built VitalRegistry in six weeks of part-time work and the reconciliation now runs in minutes. Before you call an agency and ask for a quote, here is what that build actually cost, what drove the number up, and the framework we use to estimate a project before a line of code exists.
The Receipt From a Real Build
VitalRegistry is a web CRM for BEMER device distributors: rental tracking, client records, contracts, payments, and reminders in one place. The stack is React on the frontend and Firebase on the backend. Ten active users, each managing ten to thirty devices.
The total engineering time was roughly seven months of part-time work across two people. That breaks into two distinct phases with very different cost profiles.
Phase 1: Streamlit prototype. Six weeks, evenings and weekends. Firebase Auth, Firestore, basic CRUD, and table views close to the spreadsheet layout users already knew. Six weeks from mum asking us at Christmas whether we could build something to a Streamlit prototype she used daily. Auth, devices, clients, and the table views she needed were live and in her hands by mid-February. The first version was not pretty. It was usable, which was the only metric that counted.
Phase 2: React rewrite. Five months. Component library, real routing, design system, mobile layouts, contract generation, in-app reminders, calendar sync.
Two people. No billing rate. But if you translate the hours into typical agency rates for two mid-level engineers in Central Europe (around EUR 50-80/hour each), the total engineering cost lands somewhere between EUR 25,000 and EUR 45,000. A Western European or US agency for the same scope would quote EUR 60,000 to EUR 120,000.
Four Factors That Moved the Number
These are the four variables that determined where inside those ranges VitalRegistry landed.
Scope Clarity at Kickoff
The initial Streamlit scope was tight: track rental devices, track clients, stop losing return dates. No integrations, no reporting, no multi-tenant billing. Every feature outside that core adds weeks. Every ambiguous requirement adds debugging cycles at the end when time is most expensive.
The scope stayed narrow because the problem was concrete. One person, ten devices, one specific failure mode. That specificity is the most undervalued input in a custom software project.
Stack Choices
- Options considered: Postgres with custom Auth, Supabase, Firebase, thin Node API on top of any of the above.
- Chosen: Firebase end-to-end. Firestore for data, Firebase Auth for login, Firebase Hosting for the frontend.
- Rationale: generous free tier for the user count we were at. Google-backed, so no betting on a startup that might shut down. Firestore and Firebase Auth ship with most of what a CRM needs out of the box.
- Tradeoff: locked into Google's data model and pricing curve. Migration off Firestore is the bill we will pay if usage scales hard.
Managed services like Firebase cut build time at low-to-mid user counts. At scale, the cost curve inverts. Picking the right stack for your projected user count at eighteen months, not your projected user count at five years, is the decision with the most direct impact on initial build cost.
Domain Knowledge of the Problem
The reason a BEMER rental CRM took six weeks for the first working version, and not six months, is that one of us had lived with the problem domain for years. The data model was correct on the first draft because we understood which fields actually mattered and which ones sounded important but never got used.
Domain ignorance is expensive. An agency that does not deeply understand rental management for medical devices will spec the data model by asking questions you do not know how to answer yet. The discovery process that fills that gap costs money, and the gaps that survive discovery show up as rework in month three.
Mid-Build Scope Change
Streamlit's hosting cost would have broken us past twenty concurrent users. That single number triggered the React migration.
- Options considered: stay on Streamlit and accept the cost cliff, partial rewrite (Streamlit for admin, React for users), full React rewrite.
- Chosen: full React rewrite.
- Rationale: Streamlit runs on the server, not the client. Past twenty concurrent users, hosting math broke. A real product also needed a real design system. The Streamlit prototype proved demand. The rewrite shipped the product.
- Tradeoff: five months of part-time engineering work and a UI users had to relearn.
The React rewrite was not a mistake. It was the right decision at the right point in the project. But it was also the largest single cost driver. Any mid-build scope change of that magnitude will do the same.
Building for fifty concurrent users from day one on the right stack costs less overall than building for ten and rewriting at twenty. The agency that lets you start on a cheaper stack without running the user-count math is not saving you money.
The Cost Estimate Framework
Run these four questions before calling anyone.
1. Can you write down the problem in two sentences? If the answer requires a meeting and a whiteboard, the discovery phase alone will cost EUR 5,000 to EUR 15,000 before any code exists. Founders who can hand over a precise problem statement cut that phase in half.
2. Do you have a current tool, and do you know what it costs you per month in time? This is the question most founders skip. Track time spent working around the tool for four weeks. Hours of manual data entry, reconciliation, copy-paste between systems. Multiply by your effective hourly rate. That number is the cost of staying put, and it is the number that changes the math on custom software.
The CRM replaced spreadsheets so completely that the end-of-month reconciliation, which used to eat a full day, now runs in minutes. That is the receipt every debate about founders outgrowing their platforms comes down to: hours saved per week, multiplied by the number of weeks left in your career.
A full day of reconciliation per month at EUR 50/hour is EUR 600/month. Over two years that is EUR 14,400. Against an EUR 25,000 build cost, the break-even is under two years. That math is never on the table when founders call an agency. It should be the first thing on the table.
3. Are you building for a fixed user count or an unknown one? For internal tools and small operator networks (under fifty users), managed services cut build cost. For products you plan to open to thousands of users, the infrastructure math at scale matters more than the day-one cost. Do not let an agency optimise for day-one cost if your roadmap ends at ten thousand users.
4. Who in your business understands the problem domain deeply enough to answer questions without a meeting? Agencies charge for discovery. Discovery is largely a domain-transfer problem. The more of that transfer you can do upfront, in writing, with concrete examples, the cheaper the discovery phase. The faster the discovery phase, the cheaper the build.
The Number Founders Get Wrong
Before calculating what custom software will cost, calculate what staying on the current tool is costing.
Month-end reconciliation that eats a full day. Support tickets that require manual cross-referencing between three systems. Data exports that take an afternoon and still require cleanup before they are usable. These do not appear on any invoice. They do not show up in any vendor comparison. Founders absorb them as the background cost of running a small operation, and they never add them up.
The total cost of staying on your current tool is almost never calculated before the custom software conversation starts. That uncalculated number is the hidden line item that changes the math. Run it first. The build cost is the wrong number to start with.
Ranges by Project Type
For founders comparing options, here are realistic ranges based on scope, not on what agencies quote on their websites.
Internal tool (under ten users, tight scope, managed backend): EUR 8,000 to EUR 20,000. This is the VitalRegistry Phase 1 range. Proof of concept, usable, not pretty. If the problem is clear and the team has domain knowledge, this range is achievable in eight to twelve weeks.
Operational CRM (ten to fifty users, custom data model, reporting, basic integrations): EUR 25,000 to EUR 60,000. This is the full VitalRegistry range including the React rewrite. Expect four to seven months with a two-person team.
Product with external users (fifty-plus users, auth, billing, support, scale considerations): EUR 60,000 to EUR 150,000 and up. Stack decisions matter more here. Discovery is a real phase, not a conversation.
These ranges assume a team with domain knowledge of the problem. Without it, add thirty to fifty percent for discovery and rework.
The Starting Point
The build cost is not the first number to run. Run the cost of staying put first. Four weeks of time-tracking on your current process will surface the real budget for custom software. If the break-even is under two years, the build is not expensive. It is overdue.
If you are at that point and want a second opinion on scope or stack, the contact is on czaban.dev.