Lunarie, uma biblioteca inteligente para livros digitais e físicos
Uma biblioteca que organiza ebooks com nomes confusos e envia os livros ao Kindle.
Resumo
Resumo executivo
A Lunarie é um projeto pessoal que organiza bibliotecas de ebooks e livros físicos e envia os ebooks ao Kindle. Nasceu de uma dor minha: os arquivos tinham nomes ilegíveis e o Kindle não os listava na ordem de leitura. Desenhei a interface e construí o produto com o Claude, que agora entra em beta.
Cliente
Projeto pessoal
Ano
2026
Papel
Product Designer
Ferramentas
Claude, Lovable, Midjourney, Storybook, Supabase, GitBook, GitHub
- Plataforma
- Lunarie, aplicação web (app e landing)
- Usuários
- Pessoas com acervo próprio de livros, digitais ou físicos, incluindo quem lê no Kindle
- Escopo
- Produto, design system e implementação do app e da landing, do zero
- Contribuição
- Pesquisa, decisões de produto, design system, implementação com IA e documentação no GitBook
Contexto
Contexto do projeto
Eu usava o Skoob para acompanhar a leitura, o Calibre para editar metadados e o e-mail da Amazon para enviar ao Kindle. A Lunarie reúne organização e envio num lugar só.
Restrições
Restrições do projeto
Custo de operação baixo
A única renda prevista é doação, sem garantia. Supabase, Resend, Groq e as APIs de livros rodam em planos gratuitos com limite de uso. Isso moldou a Decisão 02.
Sem API da Amazon para enviar ao Kindle
O único caminho é o e-mail do Kindle, que só recebe arquivos de remetentes autorizados na conta da Amazon (ver Decisão 03).
Formatos sem leitura de título e autor
Em MOBI e AZW3 o app não lê título e autor, então a organização depende do nome do arquivo e da entrada manual (ver Decisão 04).
Dependência de um provedor de IA com limite de uso
O plano gratuito do Gemini não funcionava sem billing. O Groq, que o substituiu, descontinuou o modelo usado e parou o enriquecimento por IA até a troca (ver Decisão 04).
Meu papel
Meu papel
Defini o problema a partir da minha necessidade de organizar meus livros e usei minha experiência em UX para levar um produto da ideia ao app publicado, estudando IA ao mesmo tempo. Para construir, aprendi GitHub, Supabase, Resend e Storybook pelo caminho.
Decisões de produto e design
Eu decidia o que entrava no produto e em que ordem, com a skill PM sugerindo prioridades no Asana. Desenhei a interface direto no Lovable e depois refatorei os componentes de Tailwind para shadcn, com os tokens da Lunarie documentados no Storybook.
Construção com IA, testes e documentação
Construí com o Claude conectado ao Supabase e ao GitHub, com cinco skills que criei: PM, UX, Arquiteta, QA e Technical Writer. A skill de QA escreve os cenários de teste, que executo e registro no Asana. A documentação fica no GitBook.
Decisões
Decisões de produto
O raciocínio por trás de cada escolha, incluindo o problema, as alternativas consideradas e por que a decisão final fazia mais sentido.
Padronizar o nome do arquivo com modelos editáveis
Problema
Os arquivos chegavam ao Kindle com nomes que não identificavam o livro nem a ordem da série.
Decidi
Cada livro recebe um nome montado com Título, Autor, Série e Volume. Em Configurações, a pessoa edita um modelo para séries e outro para livros avulsos.
Em vez de
Impor um único padrão de nome a todas as pessoas.
Porque
O formato que ajuda na leitura varia de pessoa para pessoa.
Trade-off aceito
Série sem número recebe volume 01, o que pode numerar errado um livro ainda sem número. Os acentos saem do nome, o que pesa mais em PDFs.
Impacto esperado
- Os livros chegam ao Kindle com o nome padronizado.
Não guardar o arquivo depois da importação
Problema
O plano gratuito do Supabase tem 1 GB. Só os meus 177 arquivos ocupavam 376 MB, então 2 ou 3 usuários a mais estourariam o limite.
Decidi
Ao terminar um lote, a pessoa envia ao Kindle, baixa em .zip ou conclui. O arquivo é removido em seguida, e a janela de conclusão avisa isso antes.
Em vez de
Pagar um plano maior ou cortar funcionalidades.
Porque
Com doação como única renda, o custo precisa ficar baixo. O espaço ia todo para os arquivos importados, então cortar telas não resolveria.
Trade-off aceito
Reenviar um livro exige importar o arquivo de novo.
Impacto esperado
- O espaço por conta deixa de crescer com o uso.
- A validar no beta: se a etapa extra atrapalha a conclusão da importação.
Automatizar o envio por e-mail em vez de depender de uma API
Problema
Sem API da Amazon, eu enviava os livros ao Kindle por e-mail, na mão.
Decidi
A pessoa cadastra o e-mail do Kindle e autoriza o remetente do app uma vez na Amazon. O onboarding e as Configurações explicam esse passo, e vários livros seguem num único e-mail.
Em vez de
Manter o envio manual, um e-mail por importação.
Porque
O e-mail do Kindle funciona sem API, e o app já renomeia os livros antes de enviar.
Trade-off aceito
A autorização acontece no site da Amazon, e o app não consegue conferir se ela foi feita.
Impacto esperado
- Os livros chegam renomeados, com histórico de envios no app.
IA como último recurso de uma cadeia de fontes verificáveis
Problema
Deixar a IA preencher os metadados seria o caminho mais curto. Mas um modelo de linguagem pode inventar uma série ou um gênero que parece plausível.
Decidi
O app preenche os dados em ordem de confiança: lê o arquivo e consulta o Google Books e o Open Library. A IA só entra quando a pessoa clica em Completar informações, para lacunas como a sinopse, e nada já preenchido é sobrescrito. A pessoa revisa cada livro antes de confirmar.
Em vez de
Deixar a IA preencher os metadados direto, sem consultar antes o arquivo nem as APIs de livros.
Porque
Arquivo, ISBN e APIs podem ser conferidos, a IA não. Por isso ela só decide o que sobrou, com gênero de uma lista fixa e série aceita só quando o autor confere.
Trade-off aceito
A revisão é livro a livro, sem opção em massa, o que pode cansar quem importa muitos livros. Quando o modelo da IA foi descontinuado, não havia alerta automático, só um painel de diagnóstico no /admin.
Impacto esperado
- Os dados vêm de fontes conferíveis antes de a IA entrar
Aprendizados
Aprendizados
Defina o design system antes da primeira tela
Comecei sem design system e precisei refatorar todas as telas para shadcn, o que levou quase um dia. Hoje o PRD e o design system vêm antes do primeiro componente, e o Storybook é a fonte de verdade entre app e landing.
Depender de IA gratuita exige monitoramento
Quando o modelo foi descontinuado, o enriquecimento parou sem aviso. Como a IA fica no fim da cadeia, o arquivo e as APIs seguiram funcionando.
Medir o uso da própria conta antes de abrir o produto
Medir meu próprio uso mostrou que o plano gratuito não aguentaria nem 3 usuários a mais, a tempo de mudar o escopo antes do beta.
Próximos passos
O que vem a seguir
A Lunarie ainda não tem usuários. O beta Primeira Estante, com 20 pessoas convidadas, vai validar o produto com o PostHog e uma pesquisa enviada após 30 dias de uso.
- Abrir o beta e medir a ativação. O beta funciona se 15 das 20 pessoas importarem um livro e enviarem ao Kindle. Com menos de 10, reviso o fluxo antes de convidar mais gente.
- Testar o valor frente às alternativas gratuitas. A pesquisa compara a Lunarie com o jeito anterior de organizar e pede uma nota de 0 a 10 de recomendação. O PostHog mostra se o uso se repete por semana.
- Confirmar que a dor não é só minha. A pesquisa pergunta se a leitura no Kindle era desorganizada antes. Quem desiste antes dos 30 dias aparece no funil do PostHog.
- Medir a disposição de pagar. Antes de escolher entre preço único e assinatura, vou incluir essa pergunta na pesquisa.
- Revisar os trade-offs com o que o beta mostrar. As perguntas abertas mostram se a revisão livro a livro e o reenvio por reimportação incomodam.