Programas de fidelidade costumam começar como uma cartela de papel e terminar como uma coleção de exceções operacionais. O App Sticker, produto da plataforma EatSticker, parte de uma ideia diferente: tornar a progressão visível, prazerosa e simples tanto para quem frequenta um estabelecimento quanto para quem o opera.

Em vez de pontos abstratos, a pessoa coleciona figurinhas em álbuns digitais. Cada visita pode começar por um QR Code; cada álbum tem regras, progresso e uma recompensa. Parece uma mecânica leve, mas por trás dela há uma pergunta de engenharia bem concreta: como conciliar uma experiência instantânea no celular com regras de negócio, autorização e operações que precisam ser confiáveis?

O produto é uma ponte entre duas jornadas

O sistema tem dois lados que precisam funcionar em conjunto.

Para o consumidor, o aplicativo oferece descoberta e acompanhamento de álbuns, progresso das coleções, pedidos de recompensa e notificações. Para o estabelecimento, há ferramentas para criar campanhas, configurar recompensas, administrar QR Codes, analisar pedidos e conceder figurinhas.

Essa separação é mais que uma decisão de interface. Os dois públicos têm ritmos e responsabilidades diferentes. O consumidor espera concluir uma ação em poucos segundos. O negócio precisa de controles, contexto e histórico antes de aprovar uma solicitação. Tratar ambos como a mesma aplicação teria simplificado o início, mas dificultaria a evolução de cada jornada.

QR Code é o início do fluxo, não a prova final

O QR Code reduz atrito: alguém visita o local, aponta a câmera e entra no contexto certo. Ainda assim, um código sozinho não deveria conceder uma vantagem sem limites.

Quando a pessoa já participa de um álbum, uma nova leitura pode criar uma solicitação de figurinha para avaliação pelo estabelecimento. Esse fluxo tem estado explícito — pendente, aprovado, rejeitado ou expirado — e protege as duas partes com limites de repetição, deduplicação, expiração e autorização por estabelecimento.

O resultado é um equilíbrio importante para produtos que conectam o digital ao presencial: a experiência pode ser rápida sem confundir conveniência com confiança.

Regras de negócio precisam morar no domínio

Uma recompensa não é apenas uma tela concluída. Ela depende de regras como prazo após completar o álbum, elegibilidade, configuração da campanha e plano contratado pelo negócio.

No backend, a plataforma organiza API, domínio, dados e workers como responsabilidades distintas. O domínio concentra as regras; a camada de dados usa Entity Framework Core e PostgreSQL; a API REST atende os aplicativos e o painel administrativo; e processos em segundo plano tratam tarefas que não pertencem ao caminho interativo da pessoa usuária.

Essa divisão é especialmente útil para planos e recursos. Por exemplo, a disponibilidade de figurinhas compartilhadas ou personalizadas é uma política de produto, não uma validação espalhada por telas. Centralizar essa decisão evita que versões diferentes dos aplicativos interpretem a mesma regra de maneiras incompatíveis.

Duas aplicações móveis, uma base de decisões

O App Sticker está em transição para aplicações de consumidor e negócio com Kotlin Multiplatform e Compose Multiplatform. O código compartilhado ajuda a manter autenticação, comunicação HTTP, serialização, regras de fluxo e componentes de domínio consistentes entre Android e iOS, enquanto integrações específicas de plataforma continuam onde fazem sentido.

Ktor faz a comunicação de rede; Supabase Auth cuida das sessões; Firebase atende a mensageria no Android; e cada app preserva sua própria navegação e linguagem de interface. É uma escolha que reduz duplicação sem fingir que os dois públicos ou as duas plataformas são idênticos.

Também há uma interface web administrativa em React, TypeScript e Vite. Ela complementa o aplicativo de negócio com uma superfície adequada para tarefas operacionais, dados e gestão.

Notificações são um sistema, não um efeito visual

Um dos pontos mais ricos da arquitetura é a entrega de notificações. O aplicativo registra tokens de dispositivo; o domínio cria a intenção de notificar; e uma outbox registra o trabalho de modo transacional. Um dispatcher envia os itens para uma fila, e um worker processa email ou push, registrando eventos de entrega e atualizando o ciclo de vida.

Essa separação evita que uma ação importante — como aprovar uma solicitação — dependa da disponibilidade imediata de um provedor de push. Ela também cria uma trilha de auditoria e permite tratar falhas, tokens inativos e tentativas de entrega sem bloquear o fluxo principal.

Os aplicativos ainda tratam permissões e preferências de notificação como parte da experiência, em vez de uma solicitação abrupta no primeiro acesso.

A arquitetura que sustenta a experiência

Hoje, o conjunto combina:

  • .NET 8 e C# para API, domínio, jobs e workers;
  • PostgreSQL e Supabase para dados, autenticação e sessões JWT;
  • Kotlin Multiplatform e Compose Multiplatform nos apps mobile de consumidor e negócio;
  • React, TypeScript e Vite no painel administrativo;
  • Kubernetes na Oracle Cloud e GitHub Actions para empacotamento e entrega;
  • filas, outbox e provedores de email/push para o trabalho assíncrono.

Não se trata de usar muitas tecnologias por si só. Cada fronteira existe porque o produto precisa separar interação rápida, regra de negócio, persistência e processamento eventual.

O que este projeto continua ensinando

O App Sticker é um lembrete de que gamificação só funciona quando a operação por trás dela é confiável. Um álbum bonito não compensa uma recompensa ambígua; uma leitura de QR Code simples não elimina a necessidade de políticas; uma notificação útil depende de uma cadeia inteira de decisões corretas.

É exatamente essa combinação que torna o projeto interessante: levar uma experiência física e afetiva — completar uma coleção — para um sistema que precisa ser seguro, auditável, multilíngue e sustentável à medida que mais negócios e consumidores entram na plataforma.

Conheça a plataforma em app-sticker.com.