Solutions · Dental clinics
A dental clinic website is judged by one thing: whether the person finds the service they need, with its price and its unit — per tooth, per jaw, per session — and whether they know whether it is covered by insurance or not. The rest is décor. We build the structure that holds this and the panel from which the staff changes it themselves.
Already builtThe work can be verified from outside right now: the public data of a district dental centre we manage are served as a structured file — 89 services, each with category, subcategory, name, price, unit of measure and an eligibility indicator for compulsory insurance, of which 27 are marked as eligible; 7 categories and 10 subcategories, verified by us on 06.09.2026. The second part of the proof is the securing, with a diff in history: on takeover, the administrator password was compared in the browser and ended up in the public JavaScript package, and writes to the application programming interface could be made by anyone on the internet. The correct clarification, so we do not attribute to ourselves more than is ours: the first version of the site is not ours. The contribution that can be shown with diff is takeover, securing, types, continuous integration and dependency hygiene.
A dental clinic does not sell “services”. It sells a very long list of tariff items with units that do not resemble anything from another field: per tooth, per jaw, per extraction, per treated case, per session, per visit, per procedure. The person searching online is not looking for the clinic, but for their item: how much does an extraction cost, is it paid per tooth or per visit, is it covered by insurance. A website that answers this is useful; one that has a “Prices” page with an attached PDF is not.
The second thing that reality of a clinic requires is for the list to be changeable without a developer. Tariffs change, doctors change, the emergency schedule is announced differently in winter. If every change goes through a developer, the list stays old and, in a few months, patients come with last year’s price. The structure we build keeps the public data — services and team — in structured files read both by the API and directly by the visible part of the website, and the staff edit them from a panel.
The third thing, which no one asks for in the brief and which matters most, is who can write to that list. When we took over the project we write about here, anyone on the internet could send a write to the API, and the panel password ended up in the JavaScript bundle served to the browser — because its verification was done in the browser. We moved verification to the server: the password no longer leaves the server, a signed token valid for twelve hours is returned, with a limit of eight attempts per fifteen minutes per IP address and constant-time comparisons; the API listens only on the local address, so the web server is the only public path.
The marker for coverage under compulsory insurance deserves a separate sentence, because it is the field with the highest value for the patient and the highest risk for the clinic: it is an assertion with consequences. That is why it lives as institution-edited data, not as text written by us on a page; we build the field, the display and the ability to correct it in a minute.
What it covers
The data structure of each service has category, subcategory, name, price, unit of measure and an eligibility indicator for compulsory insurance. The units are the real ones of the field — tooth, jaw, extraction, treated case, session, visit, consultation, anaesthesia, procedure, investigation, intervention — because a price without a unit produces exactly the conversation reception wants to avoid.
Category and subcategory, not a flat list. In the work we write about: 7 categories and 10 subcategories across 89 services. Scale matters — below one hundred items, a two-level taxonomy is enough; above a few hundred, the structure becomes a different discussion and we say so before, not after.
The eligibility indicator is attached to each service, in public data, and is editable by the clinic. In the cited work, 27 out of 89 services are marked as eligible. We do not determine what is covered by insurance, and we do not infer it: it is the institution’s statement, with consequences for the patient, and it must be correctable by it at any time.
Not a single “Services” page. The site has 22 screens, from services and prices to emergencies, orthodontics, implants, paedodontics, transparency and feedback. The reason is practical: someone searching for “dental emergency” on Sunday evening does not want a general page, and a section page has something to say about opening hours and what is done in it.
Services and the team are edited from a panel, and writes require a valid token; reads remain public, so the site works without authentication. The consequence for the clinic: a price change goes live the same day, not in the next development iteration.
Authentication is done on the server and returns a token signed with HMAC-SHA256, valid for 12 hours, with a maximum of 8 attempts per 15 minutes per IP address and constant-time comparisons. The signing secret is generated automatically, in a file with restricted permissions, kept outside the repository. These are numbers from the code, not general principles — they can be read and challenged.
It listens only on the local address, so the front web server is the only public route; the allowed domain list is explicit, and the request body is capped at 1 MB. Writes require a token, reads do not. It is a standard configuration — the problem is that, when it is missing, it cannot be seen from the outside until the day someone finds it.
The check that compiles and verifies types also does something that few projects do: it searches for secrets in the built package and fails if it finds one. It is directly tied to the bug fixed in intake — a password had ended up in the public package precisely because nothing checked for this. On top of that, dependency updates on a weekly cadence.
It does not confirm an appointment on its own: it collects the request, and confirmation requires either a person or a connection to the clinic’s appointment system — a separate task, with its own conditions. It does not publish clinical information written by us: content about treatments is the responsibility of the specialists. And it does not decide what is covered by insurance.
Traseul
The first delivery is the list of tariff items with the unit for each and the coverage marking, in the form kept by the clinic. If the list does not exist in a structured form — and usually it exists as a spreadsheet or as a document — we structure it, and the clinic confirms it. Design comes afterwards, because it depends on how many items there are.
The public screens and the panel from which they are edited are not made separately, because otherwise displayed fields appear that cannot be edited. We deliver the site with the real data loaded, not with filler content — a clinic site full of placeholder text cannot be assessed by anyone.
Server-side authentication, signed token, attempt limit, API only on the local address, allowed domain list, request body cap. We deliver the result of an external verification: what can be read without authentication and what cannot be written.
We hand over the accesses, the commissioning document and a short training for the person who will change prices and the team. Delivery is not considered complete until someone from the clinic has, on their own, made a change that appears on the site.
The data
The rules differ from one industry to another. These are the ones that apply in dental clinics.
A case
The situation
When taking over a dental centre site, the admin panel had two problems that could be seen only from the inside. First: the password was compared in the browser, so it reached the public JavaScript package. Second: write requests to the API could be made by anyone on the internet, and the port was exposed directly.
What we built
We moved the check to the server: authentication returns a token signed with HMAC-SHA256, valid for 12 hours, with a limit of 8 attempts per 15 minutes per IP address and constant-time comparisons; the signing secret is generated independently, with restricted rights, outside the repository. The API was kept listening only on the local address, with the web server in front, allowed domain list and request body capped at 1 MB. Writes to services and the team require a token; reads remained public. On top of all that, continuous integration that compiles, checks types and rejects the package if it finds a secret in it.
What came out
The clinic’s public data can be checked from the outside today: 89 services, each with category, subcategory, price, unit and insurance coverage indicator, of which 27 are marked as eligible. What has changed is who can write to them.
What the case does not say
We did not build the first version of the site. From the repository history, some of the commits belong to external developers. The contribution we can show with diff is the handover: security, continuous integration, types, dependencies.
Questions
Yes — that is half of the work. The services and the team are edited from a panel; writes require authentication, reads remain public. Our recommendation: at handover, the person who will handle it makes the change in front of us, so we know it works from their hand, not from ours.
As an indicator on each service, in the same data you edit. In the work we cite, 27 of 89 services are marked as eligible. We build the field and the display; what is eligible is the institution’s statement, because it has consequences for the patient and for the clinic.
Because in dentistry the price is not per visit. It is per tooth, per jaw, per extraction, per treated case, per session. A price displayed without a unit produces exactly the conversation reception has ten times a day and, worse, the patient’s feeling that they were told something else on the phone.
It can collect the request. Confirming a time slot requires either a person who checks the schedule, or a connection to the clinic’s appointment system — it is a separate job, with compatibility checking beforehand. We do not call a form that sends an email “online booking”.
The clinic’s specialists. We do not write clinical information and do not “optimise” it for search, because that would mean formulating medical statements on behalf of a medical institution. We structure it, ask the questions the text must answer, and publish it after it is confirmed.
Yes, and the work we write about here is exactly that. What we do first in a takeover: we look at what can be written from the outside, where the passwords are, and what ends up in the package served to the browser. In the cited case, the administrator password ended up in the public package, and writes could be made by anyone. We moved verification to the server and closed the writes.
As soon as it is saved, because the public data is read from the same source you edit. What we do not promise is the speed at which results are updated in search engines — that does not depend on us and we cannot guarantee it.
It is set at implementation: where they go, who sees them, how long they are kept and what is never requested in the form. In a clinic, the message often contains a description of a health issue, so it is not “a lead”, it is a category of data with a strict regime — and its handling is set out in the clinic’s published policy.
Only if you want it to. Some of our work carries attribution in the footer, others do not — it depends on the client. We mention this because it is a question clinics ask and because, when the site carries no attribution, we do not present ourselves as authors without their consent.
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.