Localhub · End to end product design · 2026
Nobody wants a CRM
I spent twenty years building product for CVC, Natura and Porto. When I set out to build my own, I started from what looked like an obvious premise. Local businesses need a CRM. Discovery knocked that down in the first week. The pain that makes a clinic owner reach for their wallet is not organising contacts. It is losing a customer who was already in hand.
This case is about what changes in a product when you accept that your premise is wrong.
- Role
- Founder, product designer and engineer. Discovery, information architecture, design system, implementation and running it in production.
- Team
- Solo, with AI as the pair. Real customers as the validation bench.
- Constraints
- One executor, zero media budget, and an audience with no patience for software. If it needs training, it is dead.
I started by modelling the hypothesis before asking
I wanted to walk into those conversations with a formed hypothesis instead of a generic question. I built five personas by segment (healthcare, law, aesthetics, pet care and accounting), wrote an exploration script in the Mom Test format, and used synthetic personas to stress the hypotheses and find where they broke. That generates hypotheses, and it told me what to ask.
The evidence came from three real sources.
First, prospecting conversations. I ran Localhub's own prospecting myself, which turned into more than three hundred conversations with local business owners. These are not formal interviews and I will not call them field research. They are sales conversations, with the bias that carries. But it is where I heard the same sentence over and over.
Second, real customers in operation. Trimat, G13, Patriot Insights and a dental clinic went into the system and gave me actual usage behaviour.
Third, the behaviour of the product itself. Once it was running, the database became my best research source. I come back to this, because it is what proved me wrong a second time.
What knocked the premise down
Nobody asked for a CRM. What kept surfacing was the same scene. The customer sent a message, nobody replied in time, and they went to the competitor. The pain has a name, and it is the slow reply. And the second pain, almost as frequent, is a quote that went out and died with nobody following up.
I stopped designing a place to store contacts and started designing a system that leaves nobody without an answer. The product promise became no customer forgotten.
I organised the findings into an opportunity tree and prioritised three. First, the slow reply. Second, rescuing stalled quotes. The third I called breaking the scar, because almost every owner had been burned by some agency or some system before, and arrived suspicious. That third one became no feature at all. It became a positioning and copy decision, and it was the hardest to accept, because you cannot solve it with a screen.
The decisions, and what each one cost
The owner is never going to open a dashboard
The persona that kept showing up does not sit at a computer. She serves customers, and checks her phone between one and the next.
The main screen became a list of what to do now, in place of the dashboard. It is called “My day” and answers one question, what is the next action. The whole design system was born mobile first and in dark mode.
The executive dashboard with charts, which is what I wanted to build and what every competitor puts on the home screen. It exists, but it is not the front door. I lost the pretty screen and gained daily use.
Reactivating a cold base is worth more than prospecting
When I crossed the stalled quote pain with what customers already had in their database, it was clear the money was already inside. Local businesses pile up a dead base for years.
The sales agent was born with reactivation at its core, and prospecting as the add on. It is counterintuitive, because prospecting is an easier promise to sell.
Positioning the agent as a prospecting machine, which was the commercially attractive pitch and what the market expected to hear.
Automating messages burns the customer's phone number
Here the research was technical and the finding came from outside the user. Bulk active sending on WhatsApp gets the number banned, and that number is the owner's asset.
I built a guardrail that refuses to send to anyone without opt-in, with a daily volume ramp and a typing delay. The cadence postpones a send to protect the number. The product is deliberately slower than it could be.
Instagram automation. The API exists, but I did not have Meta approval, and sending DMs through an unsanctioned path put the customer's account at risk. It became a copilot. The system writes the message and a person sends it. Automatic sold better. Assisted is what shipped.
Where the data proved me wrong again
Weeks after everything was live, I went to the database to pull numbers and found behaviour I did not expect. Fifty one distinct leads had generated more than twelve thousand cadence enrolments, an average of two hundred and forty per lead, and every single execution was being refused by the opt-in guardrail.
Two readings came out of that. The first is that the guardrail worked, because it refused more than twelve thousand send attempts in twenty four days to protect customers' numbers. The second is that the engine was wrong, because it kept trying to contact people it already knew it could not contact, and the data said almost none of the leads in the base had opt-in.
The design was right at the lock and wrong at the flow.
I fixed it at the source. Whoever cannot receive no longer enters the sequence, and when permission is missing the enrolment closes with its own state. I also separated, in the log the customer reads, a deliberate refusal from a technical failure. Governance working was being displayed as a broken system.
In the same review I found the intent engine was structurally unable to classify any lead as hot, because its reachable ceiling sat below its own threshold. Fixed as well.
What is live, and what I will not claim
The system runs in production across twelve provisioned accounts, paying customers among them, and covers the full cycle of a local business, with capture, pipeline, scheduling, cadences, email, documents with signature and billing. Ninety four tables, every one of them with row level isolation and more than three hundred access policies, maintained by one person.
I am not going to present a conversion metric here. The product is new, real transactional volume is still small, and the number I could show would come largely from a demo account. I would rather state what I can stand behind.
The most useful part was the most uncomfortable
My discovery was right about the pain and wrong about the behaviour. People described the problem as disorganisation and behaved like people with a permission and time problem. Only usage data revealed that, and it only surfaced because I went looking after launch.
If I started over, I would have instrumented behaviour before writing the first screen.
