Como funciona
Posse real, não “whitelabel” emprestado
A maioria dos concorrentes (Toast incluído) publica a app na conta deles. Sair do sistema = perder a app + todos os utilizadores + as reviews acumuladas. VelOS faz o build e entrega; a conta de developer é sua, registada com o seu NIF. Se mudar de fornecedor, a app fica.
Branding total
Logo, cores, tipografia, ícone, ecrã de arranque, notificações push — tudo seu. O cliente abre a app e vê a sua marca, não “VelOS Branded App #4732”. O nome VelOS é invisível para o cliente final (princípio canónico: powered-by visível ao staff, invisível ao diner).
Notificações push nativas
Pedido pronto, promoções, lembretes de aniversário, novidades do cardápio. Sem dependência de SMS pago nem de WhatsApp Business. Notificações disparam do painel com 1 clique e chegam em segundos a todos os clientes que instalaram a app.
Mesma base que web e QR-mesa
Cardápio, pedidos, fidelidade, reservas — tudo partilha o mesmo backend Supabase. Quando actualiza um preço, actualiza em todos os canais (web + app + QR mesa). Não há 3 sistemas para sincronizar manualmente.
Actualizações sem revisão da App Store
Cardápio, fotografias, banners, promoções actualizam ao ar — não passam pela revisão da Apple/Google. Apenas mudanças estruturais à app (versão major, nova funcionalidade nativa) requerem submissão. No dia-a-dia, mexe e está no ar.
Porque “publicada na sua conta” é o detalhe mais importante
A maioria dos concorrentes (incluindo os internacionais) publica as apps brandeadas dos seus clientes na própria conta de developer. À primeira vista parece detalhe menor — “a app fica brandeada na mesma”. Não fica.
Quando publica na conta deles:
- Lock-in vendor extremo. Sair do sistema significa perder a app — todos os utilizadores, todas as reviews, todo o histórico de instalações. A pressão para ficar é enorme, mesmo que o serviço piore.
- A relação cliente é deles. O Apple ID que escreve a review, o Google Account que descarrega — pertencem ao “VelOS” (no caso deles), não ao seu restaurante. Não tem dados.
- Se o fornecedor sair do mercado, a app desaparece da loja. Já aconteceu várias vezes em SaaS de restauração nos últimos 5 anos.
VelOS recusa este modelo (Decision D10 — tenant-published, não VelOS-published). A app é submetida à App Store e Google Play na sua conta de developer (registada com o seu NIF). VelOS faz o build, faz a submissão por si, mas a propriedade fica sempre consigo.
Como funciona em 3 passos
- Cria a conta Apple Developer + Google Play Console. Apple custa €99/ano, Google custa €25 one-time. VelOS dá os passos exactos no onboarding — é uma compra com o NIF do restaurante. Não fica nada na conta VelOS.
- VelOS faz o build com a sua marca. Logo, cores, ícone, splash screen — recolhemos os ficheiros uma vez. O build é gerado, testado internamente, e submetido à App Store/Play em seu nome (autoriza-nos como “app manager” na sua conta).
- Apps na loja em ~2 semanas. Apple: ~7 dias de revisão típica. Google: ~3 dias. Total ~2 semanas do contrato à app instalável. Depois, todas as actualizações de cardápio são over-the-air; só novas versões major precisam re-submissão.
Perguntas frequentes
Os custos Apple/Google são fixos?
Apple: €99/ano (ano completo, recorrente). Google: €25 uma vez (lifetime, sem recorrência). Esses custos são da sua conta — VelOS não os cobra como markup. A factura VelOS é a mensalidade do plano (€349/mês para Completo Enterprise).
Quanto tempo demora a publicação?
Submissão inicial: ~7 dias Apple + ~3 dias Google. No total, conte com 2 semanas entre dar o sinal verde e ter a app no ar. Re-submissões (correcções de bug ou novas features) demoram tipicamente 1-3 dias após a primeira aprovação.
E se mudarmos de logo ou rebranding?
Re-submissão à App Store/Play. VelOS faz o novo build com os ficheiros novos, submete em seu nome, está aprovado em 1-2 semanas. O ID da app não muda — utilizadores existentes recebem actualização automática.
Ver todos os planos →
