Xano

Notre point de vue sur Xano

Xano règle un vrai problème : permettre à une agence Webflow de livrer des applications fonctionnelles sans monter une stack DevOps complète. Là où il fallait avant un backend Node, une DB Postgres provisionnée, une CI/CD et un hébergement, Xano fournit l'ensemble dans une interface visuelle.

Le tradeoff existe. On perd la liberté totale du code custom, on accepte un vendor lock-in modéré, on dépend de la roadmap de Xano. Mais sur 80 % des projets Webflow + app, le rapport effort sur résultat est imbattable.

Quand on choisit Xano

• Dashboard client ou espace membre. Auth, gestion de profils, données privées par utilisateur. Xano + Wized excelle sur ces cas.
• Marketplace ou plateforme à deux faces. Profils, listings, messagerie, transactions. La modélisation Xano gère ça proprement.
• Logique métier complexe. Calculs, workflows conditionnels, intégrations API multiples. Plus puissant qu'Airtable ou Supabase basique.
• Volume modéré à fort sans équipe DevOps. Jusqu'à plusieurs millions d'utilisateurs sans gérer un seul serveur.

Quand on déconseille Xano

• Site marketing pur. Si le besoin est juste un blog et des pages, Webflow CMS suffit. Xano serait du sur-engineering.
• Volumes très massifs ou ultra-temps réel. Au-delà de plusieurs dizaines de millions d'utilisateurs ou pour des cas latency-critical, du custom Postgres + Node performera mieux (un Supabase en low-code est très bien)
• Équipe technique mature en Postgres direct. Si le client a déjà une équipe back, Supabase donne plus de contrôle SQL pour un coût similaire.
• Budget zéro et MVP éphémère. Le plan Xano démarre payant. Pour tester un MVP en 48 h, Supabase free tier ou Firebase peuvent suffire.

Comment on l'utilise concrètement chez Justa

1. Modélisation de la base avant la première ligne

On dessine le schéma de données dans Figma ou dbdiagram.io avant d'ouvrir Xano. Tables, relations, index, règles métier. Cette étape évite 80 % des refontes qu'on voit chez les équipes qui foncent dans l'interface.

2. Function Stack rigoureusement nommée

Chaque endpoint API a un préfixe par domaine, un suffixe par action (exemple : auth/login, user/get-profile, subscription/cancel). Le code Xano devient lisible comme un projet bien structuré. L'intégration récente avec un IDE est aussi hyper intéressante pour faire du code facilement.

3. Authentification JWT propre

On utilise systématiquement le JWT avec refresh token, pas les sessions cookies. Plus simple à débugger côté Wized et plus sécurisé.

4. Couche Wized comme front

Webflow gère le visuel et le marketing, Wized fait le pont avec Xano pour l'app authentifiée. Cette séparation rend chaque couche maintenable indépendamment.

Les limites qu'on gère

• Pricing par requêtes. Au-delà d'un certain volume, le coût grimpe. On optimise les batchs et on cache côté Wized quand c'est pertinent.
• Debug parfois opaque. Les erreurs Xano peuvent être obscures. On instrumente avec des logs explicites dans chaque function stack.
• Versioning limité. Pas de git natif. On exporte régulièrement les configs et on documente les changements dans un changelog manuel.
• Cold start sur petits plans. Sur les plans entrée de gamme, les premières requêtes après inactivité peuvent ramer. À considérer dans le choix du plan.

Alternatives qu'on connaît aussi

• Supabase. Notre alternative open source. Plus de contrôle SQL, écosystème moderne, mais courbe d'apprentissage plus exigeante. Pertinent quand l'équipe est tech.
• Firebase. Bien pour les apps mobiles et le temps réel. Vendor lock-in Google plus fort.
• Cloudflare : D1 + un Worker est top pour une mini web-app