indie.md
All people
Doru

Doru

Building scheduling software for dental clinics

Builder behind Dentor, an appointment-scheduling and practice-management platform for Romanian dental clinics. Dentor gives each practice a 24/7 online booking link, automated SMS and email reminders, centralized patient records, and an auto-generated website, so a clinic runs on software instead of a receptionist's notebook. Building a vertical SaaS in one of the most heavily regulated data classes there is: patient health data under GDPR.

Journeys

Events

Advice & Tips

Product Product

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.

Product Product

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.

Distribution Distribution

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.

Business & Legal Business & Legal

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.

Mindset Mindset

A hard-to-serve, regulated niche is a moat

Everything that makes Dentor hard (health-data compliance, slow offline buyers, in-person selling) is also what keeps casual competitors out. A market that punishes shortcuts and rewards patience is one where a committed builder can win and then defend the position. The difficulty is not a reason to avoid the niche, it is the reason the niche is worth owning. When you find a vertical where the barriers are real (regulation, trust, an unglamorous sales motion), the same walls that slow you down will keep the next person out once you are inside.

Distribution Distribution

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.

SEO SEO

Keep diacritics in your content, strip them from your URLs

On a Romanian site, the diacritics question has a practical answer. Google treats "programari" and "programări" as equivalent, so writing correct Romanian with diacritics in your body copy, headings, and titles carries no ranking penalty and reads as more credible to a human. Where diacritics genuinely cause trouble is in URL slugs, file names, and image alt text, where encoding breaks links and tooling. So the rule most Romanian practitioners settle on: diacritics in the content the reader sees, none in the identifiers the machine parses. The same logic applies to any language with accented characters.

Product Product

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.