Auditoria Consolidada · Clinicafy — Auditoria cs-*

Clinicafy tem product-market fit latente (gestão médica vertical é carente de soluções acessíveis no Brasil), mas opera com Vercel Hobby (violação de ToS comercial), sem processos de vendas definidos e sem MRR documentado. A arquitetura foi construída com qualidade acima da média para o estágio, mas decisões de make-vs-buy (Firebase Auth + MySQL Hostinger + Cloudflare R2) criam complexidade de vendor lock sem budget para resolver. O CEO precisa escolher entre 'crescer rápido com infraestrutura arriscada' ou 'solidificar base antes de escalar'.

O stack Express+Prisma+MySQL é tecnicamente correto para o estágio, mas o server.ts monolítico com 2911 linhas representa débito estrutural severo. O alias Vite para mockFirestore.ts é uma gambiarra elegante porém perigosa: qualquer import de 'firebase/firestore' vira uma chamada HTTP sem o dev saber. DORA metrics: deploy bloqueado (auto-deploy quebrado + DATABASE_URL perdida), lead time desconhecido, MTTR potencialmente alto sem runbook.

O frontend usa lazy loading em todas as 26 páginas (App.tsx:40-64), design system via shadcn/ui e motion/react — práticas corretas de SR. O backend é um único arquivo de 2911 linhas sem separação de responsabilidades. Não há CI/CD pipeline configurado (sem .github/workflows/). O uso de 'npm run check' (tsc + vitest + build) é bom, mas não está automatizado em PR.

Resposta às 7 perguntas de forcing: Team=1, Cadence=diária, User-facing=sim, Budget=mínimo, Traffic p99=baixo (<100 RPS), Data=PII+saúde, SLO=99.5%. Profile: Solo founder, MVP-to-Series-A. Stack escolhida (React+Vite+Express+Prisma+MySQL) é adequada. Principal problema arquitetural: o alias Vite para mockFirestore cria um anti-pattern que coloca lógica de autenticação no cliente quando deveria estar no servidor, e cria débito de abstração de toda a camada de dados.

O frontend tem boas práticas de bundle splitting (26 lazy routes), PWA com workbox (vite.config.ts:16-51), OG tags completas e structured data JSON-LD. Problemas críticos: meta viewport com user-scalable=no (viola WCAG 1.4.4), sem Content-Security-Policy (detectado em produção), sem métricas de Core Web Vitals instrumentadas.

O backend tem auth robusta com fallback duplo (Firebase Admin SDK + Identity Toolkit API, server.ts:204-249). MercadoPago e Meta CAPI integrados com sanitização. Problemas graves: rotas /api/pacientes e similares respondem sem verifyAuth (HANDOFF.md:91), sem rate limiting global, sem connection pooling explícito no Prisma e CORS totalmente aberto (Access-Control-Allow-Origin: *).

O projeto tem um HANDOFF.md atualizado (2026-07-15) com documentação técnica detalhada — qualidade rara. Porém o README não existe como documento de onboarding. Sem .github/workflows, sem branch protection, sem CONTRIBUTING.md. Processo de desenvolvimento é 'push para main e Vercel builda' — sem pull request review, sem staging environment.

Na linha do 'Don't be a hero' do Karpathy: o mockFirestore.ts recria Timestamp, QuerySnapshot, DocumentReference, CollectionReference — 409 linhas de complexidade acidental. Bastaria uma camada simples de fetch com auth. O alias Vite para 'firebase/firestore' é inteligente, mas o que está atrás é desnecessariamente complexo. O App.tsx tem good parts (Suspense, lazy, motion) mas o onSnapshot simulation (long-polling provável) merece atenção.

26 páginas de funcionalidades (App.tsx:40-64) cobrem bem o JTBD de um médico generalista: agenda, pacientes, prontuário, financeiro, estoque, guias TISS/TUSS, módulo odonto. Porém o bloqueante atual (DATABASE_URL) impede deploy de 3 features completas. Sem product metrics, sem user research documentada e sem framework de priorização aplicado.

Clinicafy compete em gestão médica vertical no Brasil. Concorrentes principais: iClinic (R$299+/mês), DrZapp, Tasy (enterprise). O 'grátis para sempre' é uma vantagem de curto prazo, mas não é sustentável sem monetização sólida. Vantagem defensável potencial: integração TISS/TUSS nativa (complexidade regulatória como moat), multi-tenancy para grupos de clínicas e o shim Firestore→MySQL que permite migração de dados do Google AI Studio.

PRODUCT_EVENTS (server.ts:78-88) define 9 eventos críticos: signup_completed, checkout_started, purchase, first_appointment_created, first_consultation_completed, etc. Estes eventos são disparados mas enviados apenas ao Meta CAPI (se configurado) e Mautic — sem destino de analytics de produto (GA4, Mixpanel, Amplitude). Sem funil de ativação, sem retention cohorts, sem feature usage. Decisões de produto são cegas.

O projeto opera sem processo ágil definido. O HANDOFF.md (seção 5 'Próximos passos') é o único backlog existente — itens listados linearmente sem story points, sem critério de aceite, sem definition of done. 3 features completas estão prontas mas bloqueadas por um único impedimento técnico (DATABASE_URL). Um Agile PO removeria esse bloqueio como prioridade máxima antes de qualquer nova feature.

O produto tem 26 telas cobrindo jornadas médicas complexas (prontuário, TISS, agenda). OnboardingPage.tsx (20KB) existe — bom sinal. Problemas de UX: user-scalable=no impede zoom para usuários com baixa visão, sem tutorial interativo de primeiro uso, AgendaPage.tsx (54KB) e PatientDetails.tsx (66KB) são candidatos a sobrecarga cognitiva. Sem testes de usabilidade documentados.

O index.html tem copy bem estruturada com keywords corretas ('prontuário eletrônico', 'agenda médica', 'guias TISS/TUSS') e SEO metadata completa. Mas o título 'Software médico e app de gestão para clínicas' é genérico, sem gancho emocional. A LandingPage.tsx (52KB) tem potencial não explorado de storytelling. O produto resolve dores reais (burocracia médica) mas o copy não narra essa dor.

O backend tem rastreamento de UTM (server.ts:89-104), Meta CAPI via Conversions API (server.ts:293-342), integração Mautic (L114-115) e PRODUCT_EVENTS (signup_completed, checkout_started, purchase). A plataforma de demand gen está tecnicamente pronta — falta ligar as campanhas. Sem Google Ads, sem Facebook Ads ativas, sem funil de e-mail para leads. CheckoutPage.tsx existe mas sem teste de conversão.

AEO (otimização para resposta de IAs como ChatGPT, Perplexity, Gemini) requer: conteúdo em formato question-answer, citações de autoridade (CFM, ANVISA), FAQ schema e linguagem direta. O Clinicafy tem SoftwareApplication + Organization + WebSite JSON-LD (bom), mas sem FAQPage schema, sem HowTo schema para funcionalidades e sem conteúdo textual suficiente na landing para IAs citarem.

O modelo Freemium de gestão médica tem alta chance de PLG se bem executado: médico usa no dia-a-dia, convida equipe (TeamManagement.tsx existe), booking público gera leads orgânicos. Problemas: sem instrumentação de ativação (quando o usuário vira 'ativo'), sem email de onboarding para free users, sem push para upgrade. O booking público (BookingPage.tsx) é um viral loop não explorado.

Pricing: Grátis (0), Profissional R$149/mês, Vitalício R$2497 pagamento único. O plano Vitalício é uma armadilha clássica de SaaS early-stage: aparece como receita saudável mas destrói o MRR previsível. Sem instrumentação de CAC, LTV, churn ou MRR atual. Dunning configurado (D0/D3/D7/D10) mas sem evidência de que está rodando. Firebase Auth gratuito e Hostinger/R2/Vercel Hobby criam custo operacional próximo de zero — boa base para unit economics.

Do ponto de vista de gestão de projeto: o Clinicafy tem scope bem definido, stack documentada, HANDOFF atualizado — fundações sólidas. Mas sem timeline, sem milestone dates, sem risk register, sem stakeholder map. O bloqueio atual (DATABASE_URL) representa atraso de +10 dias sem escalação formal. Um PM resolveria isso em horas.

Clinicafy processa dados de saúde — categoria especial pela LGPD (Art.11). A exposição de rotas /api/pacientes sem auth (HANDOFF.md:91) configura violação direta do Art.46 (segurança adequada) e Art.48 (comunicação de incidente). CSP ausente, CORS aberto, sem DPO nomeado e sem Política de Privacidade específica para dados médicos. O risco legal é crítico para um produto de saúde.