case/projetos/receitou
02/10
Receitou (cliente)·CTO & Tech Lead·Trabalho para cliente - em produçãoEm uso real por médicos

Receitou

Da situação clínica a uma prescrição pronta pra colar no prontuário em menos de 30 segundos - organiza o que o médico já sabe; a decisão final é sempre dele.

CTO
sócio com equity, time de 5
<30s
do sintoma ao prontuário
Card + PIX
checkout transparente, sem redirect
CTO & Tech Lead · sócio com equity · time de 5 com os médicos fundadores
time

CTO & Tech Lead · sócio com equity · time de 5 (incl. outro dev) · API + Web. Em uso real por médicos. O Receitou é um SaaS para médicos plantonistas (pronto-socorro e UBS). O médico digita uma situação clínica, recebe uma prescrição revisada por especialista com dose, frequência, via e duração já preenchidas, edita qualquer linha e copia formatada pro prontuário. Lidero a direção técnica junto com o outro dev: sou dono do frontend ponta a ponta e dividimos o backend, da busca clínica fuzzy ao checkout transparente e ao programa de Sócio Fundador. Python/FastAPI sobre PostgreSQL, Next.js 16 no front, Stripe pra cartão e AbacatePay pra PIX.

01

O que ele resolve

Num plantão cheio de PS ou UBS, o médico não tem 90 segundos pra reconstruir uma prescrição que ele já fez cem vezes, nem pra caçar PDF em grupo de WhatsApp pra conferir a dose de um antibiótico pediátrico. O Receitou transforma 'eu sei isso, só preciso rápido e certo' em: digita a situação, recebe a prescrição revisada, edita, copia pro prontuário em menos de 30 segundos. Ele de propósito não substitui o médico - organiza o que ele já sabe, e a decisão final é sempre dele.

02

Busca que aguenta plantão das 3h

Digita 'cefaleia', 'cefalea' ou 'cefaléia' - simplesmente funciona. A busca é híbrida sobre PostgreSQL: similaridade por trigramas (pg_trgm) em texto normalizado sem acento (extensão unaccent), tolerante a erro de digitação e plural, com fallback de substring via LIKE. O resultado é ranqueado por relevância e agrupado por classe farmacológica, então o médico varre as opções do jeito que ele pensa.

CTO
sócio com equity, time de 5
03

O modelo de dados é o produto

O conhecimento clínico é modelado com cuidado: situações → sinônimos → medicamentos → posologias (dose, frequência, via, duração) → grupos farmacológicos, com um flag is_suggested marcando a recomendação principal por classe. É um catálogo curado por especialista, não texto raspado - e é por isso que o médico confia o suficiente pra colar num prontuário real.

04

Fluxo de cópia + biblioteca pessoal

O médico liga os medicamentos que quer, edita qualquer linha (tudo é editável), reordena e copia o texto formatado pra área de transferência. Cada médico ainda monta uma biblioteca pessoal das receitas que mais usa, acessível por ⌘K em qualquer tela, isolada por usuário atrás de auth JWT com acesso por papel - um papel de admin curador edita o catálogo compartilhado; usuário comum não.

05

Feito como produto, não como script

FastAPI com clean architecture (domínio → aplicação → infraestrutura → apresentação), migrations com Alembic, ciclo de assinatura Stripe agnóstico de gateway 100% orientado a webhook (trial → ativa → atrasada → cancelada), e log de analytics em toda busca e cópia de prescrição pro catálogo melhorar a partir do uso real. Testado com pytest (unit + integração) e Playwright E2E.

decisões & tradeoffs
  • Por que Python/FastAPI se a maior parte do meu stack é TypeScript?
    FastAPI + contrato tipadoEu escolho o stack que cabe no problema, não a minha zona de conforto. A tipagem do FastAPI mais o OpenAPI gerado deram ao frontend Next.js um client tipado de graça, e o ferramental de dados do Python encaixou bem no formato do catálogo clínico.
  • Por que busca fuzzy com pg_trgm em vez de Elasticsearch?
    pg_trgm dentro do PostgreSQLO catálogo é curado e limitado - não é um corpus web-scale. O pg_trgm dá ranqueamento tolerante a erro e plural com zero infraestrutura extra pra rodar, monitorar ou pagar. Um cluster de busca seria custo e operação sem benefício nessa escala.
  • Por que assinatura agnóstica de gateway e orientada a webhook?
    Máquina de estado via webhookStripe hoje, trocável amanhã. O status da assinatura nunca é virado na mão - o webhook é a fonte de verdade (trial, ativa, atrasada, cancelada), então a reconciliação fica correta mesmo quando um pagamento falha ou tenta de novo.
  • Por que isolamento por médico + catálogo só do curador?
    Papéis em JWT, bibliotecas isoladasConfiança é o jogo inteiro numa ferramenta clínica. As receitas salvas de cada médico são só dele, e o catálogo compartilhado só pode ser editado por um papel de admin curador - então o que o médico cola no prontuário continua revisado por especialista.
Histórico
em evolução
  1. Ago 2026UX de favoritos refeita após validação com médico usuário
  2. Jul 2026Programa de sócio fundador com reserva de vaga atômica
  3. Jun 2026PIX recorrente via AbacatePay e checkout mobile-first
  4. Jun 2026Checkout vira transparente com Stripe Elements, sem redirect
  5. Mai 2026Lançamento: paywall, trial, e-mail transacional e Meta CAPI server-side
  6. Abr 2026Receitas salvas, logs de busca e primeira integração Stripe
  7. Jan 2026Primeiro commit: catálogo clínico, auth e busca fuzzy

Em uso real por médicos, com catálogo curado por especialista e fluxo sintoma→prontuário em menos de 30 segundos. Construído desde o primeiro commit como CTO e sócio com equity, liderando a direção técnica com o outro dev: clean architecture em Python/FastAPI, busca tolerante a erro com pg_trgm endurecida com match por fronteira de palavra, bibliotecas por médico com acesso por papel, checkout transparente de cartão e PIX, e um programa de sócio fundador com reserva de vaga atômica.