João Pedro Gaspar

Livra

Um app de leitura inteiro, feito sozinho: iOS, Android e web, 600 usuários cadastrados no primeiro mês. Por baixo, 6 APIs de catálogo convergindo numa identidade canônica de livro.

usuários cadastrados no primeiro mês
600usuários cadastrados no primeiro mês
plataformas: iOS, Android e web
3plataformas: iOS, Android e web
Cloud Functions no repositório
203Cloud Functions no repositório
pessoa: design, front, back e nativo
1pessoa: design, front, back e nativo
Cliente
Projeto próprio
Papel
Design, front-end e back-end serverless
Ano
2026
Stack
React 19Vite PWAFirebaseCloud FunctionsCapacitorStripeGemini
Em produção
uselivra.com ↗

O que foi meu

  1. 01Tudo, sozinho: produto, design, front-end, back-end e operação.
  2. 02Uma identidade canônica de livro sobre seis APIs de catálogo, com as regras de cache e custo que mantêm a busca barata.
  3. 03A economia travada no servidor (moedas, XP, ofensiva), escrita só por Cloud Functions.

O app, anotado

Telas da versão que está nas lojas. Cada numeral aponta uma coisa na tela e diz o que roda por baixo dela.

Prints de produção.

30323436
FIG. 4aInício
  1. 30: Ofensiva. Só Cloud Functions escrevem, em transações idempotentes por usuário, motivo e dia.
  2. 32: Livro físico conta páginas, Kindle conta porcentagem. Um modelo de progresso, duas entradas.
  3. 34: Marcar progresso é o que alimenta a ofensiva, o XP e a liga da semana.
  4. 36: Lura, a bibliotecária de IA. O Gemini escolhe, e cada escolha é checada contra o catálogo real antes de virar card.
40424446
FIG. 4bLigas
  1. 40: XP e posição são calculados no servidor. O cliente nunca escreve moeda nem posição.
  2. 42: Zonas de subida e queda da semana: quem sobe, quem fica, quem cai.
  3. 44: Moedas pela posição final. Contrato desde que chegaram usuários reais: mudar exige decisão registrada.
  4. 46: Quatro divisões, do Bronze ao Diamante.
505254
FIG. 4cModo foco
  1. 50: Uma sessão de leitura cronometrada.
  2. 52: Presa ao livro e à página em que você está: a sessão termina como progresso.
  3. 54: Som ambiente. Dois deles se desbloqueiam com moedas ganhas no app.
606264
FIG. 4dLura
  1. 60: Escolha por humor: para você, leve, suspense, fantasia.
  2. 62: Toda indicação é um livro que existe no catálogo. O modelo não consegue inventar um título.
  3. 64: O motivo é escrito para esta leitora, a partir do que já está na estante dela.
01 / 14

Ofensiva. Só Cloud Functions escrevem, em transações idempotentes por usuário, motivo e dia.

O caminho mais curto até o catálogo

Um código de barras, lido no aparelho, e depois a mesma reconciliação que a busca usa. Gravado em aparelho.

FIG. 4eScanner em lote, da câmera à estante.

01 / 06

Aponte para o código de barras da contracapa. A leitura é no aparelho. Sem código? “Fotografar a capa” manda para a IA multimodal.

FIG. 4Quatro das seis fontes de catálogo convergindo numa obra canônica.Google BooksApple BooksCBLOpen Librarywork/torto-arado← apple · google · isbn≠ []o mesmo livro, 4 respostas diferenteslido no celularjá está salvo?6 fontes ao mesmo temposem nº de páginassem editoracapa erradaquase vaziao melhor dado de cadaresenhas seguem o livronunca guarda resposta vaziaas falhas dela viram suas1 livro · 1 registro10121416reconciliação18um registro20código de barras22livros salvos24
01 / 10

Problema ·Nenhuma base de livros sozinha funciona para o Brasil. Cada uma erra alguma coisa, e o mesmo livro aparece quebrado, ou repetido.

FIG. 4Quatro das seis fontes de catálogo convergindo numa obra canônica.

Quatro respostas para um livro

Toda fonte responde, nenhuma totalmente certa. Reconciliar escolhe cada campo da fonte confiável para ele. Depois derrube a CBL.

Simulação. Dados ilustrativos, mecanismo real.

Google Books

título
Torto arado
autor
Itamar Vieira Junior
editora
Todavia
páginas
—
capa
thumb 128px
ids
google-…

Apple Books

título
Torto Arado
autor
Itamar Vieira Junior
editora
—
páginas
✓
capa
hi-res
ids
apple-…

CBL

título
Torto arado
autor
Vieira Junior, Itamar
editora
Todavia
páginas
✓
capa
catalog card
ids
isbn:978…

Open Library

título
Torto arado
autor
Itamar Vieira Junior
editora
—
páginas
—
capa
—
ids
OL…

Registro canônico

Quatro respostas parciais. Nada para mostrar ainda.

Um layout, quatro paletas

Temas são vendidos no app. Toda tela troca de pele, do perfil à liga.

Prints de produção.

Linho

Café

Alcova

Aurora

FIG. 4fO mesmo perfil em Linho, Café, Alcova e Aurora.

Contexto

O leitor brasileiro vive entre catálogos que não conversam: Skoob tem acervo nacional mas o produto parou no tempo; Goodreads ignora o Brasil; nenhum tem um loop de hábito de verdade. O Livra é um diário de leitura gamificado — streak, ligas semanais, economia de moedas, modo foco — desenhado para quem já transforma leitura em conteúdo no TikTok e no Instagram.

O problema técnico central

Não existe uma fonte de dados de livros que resolva o Brasil. Google Books tem volume mas é ruidoso e não retorna contagem de páginas na busca; a Apple tem as melhores capas mas precisa de localização forçada; a CBL é a autoridade em edição nacional mas às vezes serve a ficha catalográfica como capa; Open Library é só fallback. Nenhuma sozinha resolve — a orquestração é o produto.

O que eu construí

Uma busca unificada que consulta até 6 fontes em paralelo, detecta o tipo de consulta (ISBN vs. texto livre) e reconcilia tudo numa identidade canônica de obra × edição: o mesmo livro chegando como apple-X, google-Y ou isbn:Z converge para um único documento — o que impede cards duplicados, resenhas fragmentadas e capas inconsistentes. Avaliações são chaveadas por obra, não por edição, para que edições diferentes compartilhem as mesmas resenhas.

Em volta do núcleo: scanner barcode-first (decode local via ZXing, custo zero) com IA multimodal só como fallback de foto de capa; recomendações geradas pelo Gemini mas validadas contra o catálogo real antes de virarem card; e um catálogo que se auto-cura — abrir um livro com metadados pobres dispara enriquecimento em background, então navegar melhora a base.

Por que foi feito assim

  • Economia só no servidorMoedas, XP, streak e status PRO só são escritos por Cloud Functions, com transações idempotentes por {userId}_{reason}_{dayKey}. O cliente nunca é confiável para dinheiro — nem o meu.
  • Regra “nunca cachear lista vazia”Uma fonte que falha e retorna [] envenenaria o cache pelo TTL inteiro, sumindo com livros. Toda camada de cache valida antes de persistir.
  • Custo como requisito~40 reads por busca viraram camadas de cache com TTLs distintos (5min ISBN, 24h texto, 7 dias CBL); a cota do Google Books virou métrica observável — um 503 em produção me ensinou a diferença entre cota diária e soft rate limit, e o fix foi stagger + circuit breaker, não “tentar de novo”.
  • Defesa em profundidade como padrãoCada bug corrigido na origem (server), com defesa no client (auto-cura) e script de limpeza para os dados já gravados — o que permite evoluir um catálogo vivo sem migrações traumáticas.

Status

No ar na App Store, no Google Play e na web (versão 1.10 nas lojas). 600 usuários cadastrados no primeiro mês, com um app construído e operado por uma pessoa. As métricas que eu acompanho são de engenharia: custo por busca, convergência de identidade, integridade da economia.

Próxima prancha · FIG. 1Roland / Boss →