Match the channel to the buyer, even when it does not scale
Building scheduling software for dental clinics
Doru's cold email campaign for Dentor produced nothing; walking into clinics and pitching owners in person produced customers. Cold email is the default because it scales from a laptop, but it assumes a buyer who reads cold email and trusts links from strangers. A local, high-trust, offline buyer like a dentist is the opposite of that. The channel has to match where the buyer's trust actually lives, not your preference for staying behind a screen. Early on, the unscalable channel is often the only one that converts, so do it until you have proof and a reference list.
Related advice
When cold email dies, sell in person
Cold email is the default first channel because it scales from a laptop, but it assumes your buyer lives in their inbox and trusts a stranger's link. For a local, high-trust, offline buyer like a dentist, that assumption is wrong, and Doru found it out the direct way: the cold campaign produced nothing, walking into small clinics and pitching the owner produced customers. The uncomfortable truth for builders is that the channel has to match the buyer, not your preference for staying behind a screen. Early on, the least scalable channel is often the only one that converts, because in-person presence carries the trust a cold email cannot manufacture. Do the unscalable thing until you have proof and a reference list, then worry about scaling it.
In a regulated vertical, the data class is the product spec
When Dentor stores diagnoses and dental images, it is handling special-category health data under Article 9 of the GDPR, which is prohibited by default and allowed only under strict conditions. For a vertical SaaS in a regulated space, that data class dictates the architecture before a single feature does: encryption, pseudonymization, access control, a DPIA, and a processor agreement are not add-ons, they are the schema. Find out which regulated data class you are touching before you design the first table, and let it shape the product from day one. Retrofitting compliance onto a finished app is far more expensive than building for it from the start.
Sell the operational relief, not the feature list
Dentor's feature list (booking link, reminders, patient records, auto-generated site) means nothing to a dentist until it is translated into relief: fewer interrupting phone calls and fewer empty chairs from no-shows. Buyers do not purchase capabilities, they purchase the removal of a daily pain. Lead with the specific operational misery your product ends, in the buyer's own words, and keep the feature list for the spec page. The clinic owner does not care how it works; they care that Monday stops being chaos.
Turn compliance from a burden into a selling point
The Article 9 requirements that make Dentor expensive to build are the same requirements clinics are quietly anxious about for their own data handling. Done properly and shown honestly (not a "GDPR Compliant" badge, but a real, explained posture on consent and data protection), compliance becomes a reason to choose you over the informal setup a clinic uses today. In a regulated market, the burden everyone else avoids is the differentiator. Do the hard work, then let prospects see that you did it, because their fear of getting it wrong is part of why they will pay you.
Extracted from
Building Dentor in the Most Regulated Data Class There Is