Product In a regulated vertical, the data class is the product spec
Building scheduling software for dental clinics
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.
Related advice
Doru 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.
Doru For health data, compliance is an engineering posture, not a badge
The moment your product stores diagnoses, treatments, or medical images, you are processing special-category health data under Article 9 of the GDPR, which is prohibited by default and allowed only on a specific lawful basis such as the provision of health care or explicit consent. That triggers a higher bar than ordinary personal data: a data protection impact assessment, encryption and pseudonymization, access limited to staff bound by confidentiality, and a signed data-processing agreement that makes you the processor to each clinic's controller. A "GDPR Compliant" badge on the landing page is marketing; for health data it has to be a documented engineering and legal reality. When you build a vertical SaaS that touches a regulated data class, the binding constraint is not your feature set, it is the data class, and you should design for it from the first table you create.
Doru Match the channel to the buyer, even when it does not scale
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.
Doru 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