Live: sobermark.com
One of two products I build and run solo under my LLC, Culmination Digital. Source is private.
SoberMark is a public directory of addiction-treatment providers where nobody can pay to rank higher. 10,900+ providers across all 50 states and territories, built from the public SAMHSA and NPPES datasets, searchable by location and level of care, with the information a person in crisis needs kept in front of the paywall. Always.
Why it exists
Most treatment directories are lead-generation businesses. The facility that pays the most appears first, and the person searching at two in the morning cannot tell a sponsored result from a good one. I wanted to see whether a directory built from the federal datasets, with a ranking policy that cannot be bought, would produce better results than the incumbents. It does, and it also turned out to be the harder engineering problem: public data is messy, duplicated, and stale in ways a curated listing never is.
How it's built
Next.js 16 App Router on Vercel, TypeScript strict, Postgres with PostGIS for the geospatial queries, Stripe wired for the provider-side features that are not open yet, and a Python ingest pipeline that pulls SAMHSA and NPPES, normalizes provider records, deduplicates across the two sources, and refreshes the search tables. Search is server-rendered for SEO: every provider and every city page is a real URL with structured data, because the visitor usually arrives from a search engine, not from the home page.
The compliance frame shaped the architecture more than any feature request. Care access is never behind a paywall. Claims about a provider ("verified", badges) are kept narrow and tied to what the data can actually support. The provider-facing lead routing is designed inside the patient-brokering and anti-kickback limits that govern this space, which means the obvious monetization (sell the lead to the highest bidder) is exactly the thing the product refuses to do.
The trade-offs
Building from public data means the directory is broad before it is deep: a listing can be accurate on address and services and still know nothing about waitlists or insurance acceptance today. The alternative, curating by hand, does not scale to 10,900 providers for one engineer. I chose breadth with honest labeling over a small curated set, and kept a verification path for providers who want to correct or enrich their record.
The no-pay-to-play rule also removes the easiest revenue. The provider features that exist are priced as subscriptions for tools, not for placement, and they are gated until the compliance work around lead routing is finished. That is a slower path to revenue and the only one I was willing to ship.
What is not built yet
Provider-side features are not open. Insurance-acceptance data is not reliable enough in the public sources to show. There is no multilingual surface yet. Those are the next three problems, in that order.