Our mum ran a BEMER device rental operation across Hungary. Ten-plus medical wellness devices, each loaned to a client for weeks or months at a time. Contracts tracked in Excel. Payment status tracked in Excel. Return dates tracked in Excel. Three files that were never quite in sync, audited by hand at the end of every month.
We did not think of a product. We watched.
The spreadsheet that outgrew its owner
The files made sense to her. She had built them, tuned them over years, and understood their quirks better than anyone who might have tried to help her. But they had a failure mode she could not patch: as the number of active devices grew, the reconciliation work grew with it. Cross-referencing between sheets. Searching for the version that had the latest entry. A full day, every month, to produce a view of the business she already knew existed somewhere in the files.
The breaking point was not a crash. It was not a data loss event. It was exactly this: she asked us at Christmas whether we could build something that just stopped her losing track. Not a product. Not a tool to sell. Something that would let her trust her own data again.
That sentence is specific in a way that a market research report never is. She did not say "spreadsheets are limiting my growth." She said she could not trust her own data.
A year of observation before a single line of code
We had been watching the spreadsheet for over a year before that Christmas. Not conducting interviews. Not mapping a user journey. Just being close enough to know that the problem was real, persistent, and specific to a person doing a real job.
That distinction matters. Observation-first ideation is specific. You are looking for a person doing a real job with a visible workaround, not a market segment with an underserved need. The person is visible. The workaround is visible. The cost of the workaround is visible, in hours or errors or lost trust. A market segment is an abstraction. A person tracking device returns in a spreadsheet on a Tuesday morning is not.
The spreadsheet was the workaround. It had been the workaround for years. She had not complained loudly. She had adapted. The adaptation was the signal.
The Christmas ask, and what we decided to do
She asked at Christmas. By mid-February, six weeks later, she was using a Streamlit prototype daily.
The decision we had to make was not whether to build. It was whether to build something purpose-built or try to configure an existing tool.
Decision: Build custom vs. configure an existing CRM
- Options considered: configure an existing CRM (HubSpot, Airtable, a spreadsheet-to-app tool like AppSheet), build a lightweight custom tool in Streamlit on Firebase, pass entirely and point her to an existing BEMER management tool if one existed.
- Chosen: build custom in Streamlit on Firebase.
- Rationale: the existing CRMs are built for sales pipelines, not rental inventory. The core data model is wrong. Configuring around a wrong data model produces something harder to use than the spreadsheet it replaces. No existing BEMER distribution tool surfaced that handled multi-device individual rental tracking at the right granularity. The Streamlit plus Firebase path let us move in days, not months, and gave us a working prototype inside a month.
- Tradeoff: we own the maintenance. If we walk away, the tool stops evolving. That was acceptable because the alternative was a tool she would not use.
The Streamlit version was not pretty. Auth on Firebase took twelve hours across two evenings to get right. The table layouts were functional, not designed. None of that mattered. She started using it.
The silent endorsement
Mum's first endorsement was silent. She opened the app on a Tuesday morning instead of the spreadsheet and didn't announce it. She just used it.
There was no feedback session. No survey. No "what do you think?" She had the spreadsheet and she had the app, and she chose the app. That choice, made without being asked, was the only signal that counted.
Within a week, two of her friends who ran the same kind of rental operation were asking to use it. The feedback they gave was specific in the way feedback is when the tool is real and the problem is real. "Add a column for the date the device left." "Make the status colour change when they're late." Vague feedback is polite. Specific feedback means the person has actually used the thing and found a friction point worth naming.
We kept building.
What the build actually solved
The month-end reconciliation, which used to eat a full day, now runs in minutes. One view. All devices. Current status, return dates, payment state. No cross-referencing between files. No version hunting.
That number, one day to a few minutes, is not a product claim. It is the specific arithmetic of removing a specific manual process from a specific person's month. Every founder who has ever spent a day in a spreadsheet they did not trust knows the feeling. They also know that the spreadsheet is survivable. The problem is rarely the spreadsheet. The problem is that the spreadsheet has become the job instead of a tool for doing the job.
The CRM replaced the spreadsheet so completely that the reconciliation she used to dread is now an afterthought.
Observation first is not slow. It is precise.
The year of watching before building is not a long lead time. It is the thing that made the six weeks to prototype possible. We did not spend that six weeks figuring out what the tool needed to do. We knew exactly what it needed to do because we had watched the person it would serve for long enough to understand her actual failure mode.
The ideation method for VitalRegistry was proximity. We were close enough to see the workaround. We waited long enough to know it was persistent. We listened closely enough to understand what trust in data actually meant to someone who had lost it.
She asked us at Christmas whether we could build something that just stopped her losing track. Not a product. Not a tool to sell. Something that would let her trust her own data again.
That is the brief. Everything we built came from that brief.
The principle, and the question
Observation-first ideation is specific. You are not looking for a problem space. You are looking for a person, a real job, and a workaround they have already built themselves to survive the gap. The workaround is the product specification. Your job is to replace the workaround with something better.
The founders who build things nobody asked for usually skipped the workaround. They went from "there should be a product that does X" to building X, without ever finding the person who was doing X manually and asking why the spreadsheet had gotten so complicated.
Is there someone in your network running a real operation on a spreadsheet they built themselves and understand better than anyone else? That spreadsheet is not a problem. It is the most accurate specification of what a real tool would need to do.