case/projects/receitou
02/08
Receitou (cliente)·CTO & Tech Lead·Client work - in productionIn real use by doctors

Receitou

From clinical situation to a prescription ready to paste into the chart in under 30 seconds - it organizes what the doctor already knows; the final call is always theirs.

7 doctors
onboarded in the first week of launch
CTO
leading a team of 5
<30s
from symptom to chart
CTO & Tech Lead leading a team of 5 (incl. 2 devs) + the founding doctor
team

CTO & Tech Lead leading a team of 5 (incl. 2 other devs) · API + Web · 5 months. In real use, with 7 doctors onboarded in the first week of launch. Receitou is a SaaS for on-call doctors (ER and public health units). The doctor types a clinical situation, gets a specialist-reviewed prescription with dose, frequency, route and duration already filled, edits any line, and copies it formatted into the patient chart. I built the product and, as CTO, lead a team of 5, owning every technology decision. Backend in Python/FastAPI, typo-tolerant search on PostgreSQL, a per-doctor prescription library and gateway-agnostic Stripe subscriptions.

01

What it solves

On a busy ER or UBS shift a doctor doesn't have 90 seconds to rebuild a prescription they've written a hundred times, or to dig through PDFs in a WhatsApp group to double-check a pediatric antibiotic dose. Receitou turns 'I know this, I just need it fast and right' into: type the situation, get a reviewed prescription, edit, copy into the chart in under 30 seconds. It deliberately doesn't replace the doctor - it organizes what they already know, and the final decision is always theirs.

02

Search that survives a 3am shift

Type 'cefaleia', 'cefalea' or 'cefaléia' - it just works. Search is a hybrid built on PostgreSQL: pg_trgm trigram similarity over accent-normalized text (the unaccent extension), tolerant of typos and plurals, with a LIKE substring fallback. Results rank by relevance and group by pharmacological class, so the doctor scans options the way they think about them.

7 doctors
onboarded in the first week of launch
03

The data model is the product

The clinical knowledge is modeled carefully: situations → synonyms → medications → strengths (dose, frequency, route, duration) → pharmacological groups, with an is_suggested flag marking the primary recommendation per class. This is a specialist-curated catalog, not scraped text - which is exactly why doctors trust it enough to paste it into a real chart.

04

Copy flow + personal library

The doctor toggles the medications they want, edits any line (everything is editable), reorders, and copies formatted text to the clipboard. Each doctor also builds a personal library of their most-used prescriptions, reachable with ⌘K from any screen, isolated per user behind JWT auth with role-based access - a curated admin role can edit the shared catalog; regular users can't.

05

Built like a product, not a script

FastAPI with clean architecture (domain → application → infrastructure → presentation), Alembic migrations, a gateway-agnostic Stripe subscription lifecycle driven entirely by webhooks (trialing → active → past-due → cancelled), and analytics logging on every search and prescription copy so the catalog improves from real usage. Tested with pytest (unit + integration) and Playwright E2E.

decisions & tradeoffs
  • Why Python/FastAPI when most of my stack is TypeScript?
    FastAPI + typed contractI pick the stack that fits the problem, not my comfort zone. FastAPI's typing plus auto-generated OpenAPI gave the Next.js frontend a typed client for free, and Python's data tooling fit the clinical-catalog shape cleanly.
  • Why pg_trgm fuzzy search instead of Elasticsearch?
    pg_trgm inside PostgreSQLThe catalog is curated and bounded - not a web-scale corpus. pg_trgm gives typo- and plural-tolerant ranking with zero extra infrastructure to run, monitor or pay for. A search cluster would be cost and ops with no benefit at this size.
  • Why a gateway-agnostic, webhook-driven subscription?
    Webhook-driven state machineStripe today, swappable tomorrow. Subscription status is never flipped by hand - the webhook is the source of truth (trial, active, past-due, cancelled), so reconciliation stays correct even when a payment fails or retries.
  • Why per-doctor isolation + a curator-only catalog?
    JWT roles, isolated librariesTrust is the whole game in a clinical tool. Each doctor's saved prescriptions are theirs alone, and the shared catalog can only be edited by a curated admin role - so what doctors paste into charts stays specialist-reviewed.

In real use by doctors, with a specialist-curated catalog and a sub-30-second symptom→chart flow. Built from zero and led end-to-end as CTO: Python/FastAPI clean architecture, typo-tolerant pg_trgm search, per-doctor libraries with role-based access, and gateway-agnostic webhook-driven subscriptions.