Comment j’ai développé le MVP de MerciCookie en quelques semaines
Notre blog a déménagé ! Retrouvez l’article ici : https://blog.mercicookie.com/comment-j-ai-developpe-le-mvp-de-mercicookie-en-quelques-semaines/
Vous faites peut-être partie des premier·e·s à avoir passé une commande sur notre site. En effet, notre service est opérationnel depuis environ 1 mois.
Nous avons commencé à travailler sur MerciCookie (pour rappel, il s’agit d’un service de cadeaux d’affaires simple et pensé pour les entreprises) avec Sabine cet été et activement à partir de septembre. Rapidement notre objectif a été d’être prêts pour les cadeaux de fin/début d’année. C’était l’idéal pour tester au plus vite notre idée.
Mon premier commit date du 27 septembre. J’avais commencé à mettre la stack technique en place à ce moment-là. Le dev a vraiment commencé mi-octobre.
Le site est fonctionnel depuis le 20 novembre, date à laquelle nous nous sommes servi de notre propre site pour envoyer nos premiers coffrets afin de remercier des gens qui nous avaient aidés. La première commande que nous avons reçue a été passée le 26 novembre (nous avions communiqué sur le lancement de la beta le jour même).
Je vais vous raconter les contraintes que j’avais et les choix que j’ai fait pour développer le MVP de MerciCookie en quelques semaines.
Les contraintes
Contraintes de temps
- Avec Sabine, nous travaillons quand nous voulons, si nous voulons et où nous voulons. Cela fait partie des valeurs qu’on voulait avoir dès le départ.
- Il y avait (plein) d’autres choses à faire que le dev pour que nous soyons prêts fin-novembre
Contraintes techniques
- Il y a du paiement en ligne donc le site doit être sûr et fiable
- Je devais avoir l’esprit tranquille donc pas de dette technique, mise en place de tests…
- Je suis un développeur Ruby on Rails (qui ne code pas régulièrement depuis quelques années)
Contraintes diverses
- Nous avons fait appel à un designer et un intégrateur pour avoir un site avec une belle UX.
Organisation
Afin d’avoir un regard extérieur, Sabine a été la Product Owner. C’est elle qui créait les tâches dans notre Trello, qui les priorisait et qui les testait à la fin (oui la colonne “Contrôle de Qualité”, c’est la sienne ! Ca donne envie n’est-ce pas !?).
Définition du MVP
Afin de maximiser nos chances d’être prêts fin-novembre nous devions réduire au maximum les fonctions à mettre dans le MVP.
Voilà la liste des fonctionnalités qui nous paraissaient indispensables :
- Un·e visiteur·se consulte des informations sur notre service, sur le coffret, sur la comptabilité liée aux cadeaux d’entreprise…
- Un·e visiteur·se crée un compte et sauvegarde sa CB
- Un·e utilisateur·rice édite son adresse d’expédition
- Un·e utilisateur·rice passe une commande (simple ou multiple, immédiate ou différée)
- Un·e utilisateur·rice consulte et télécharge ses factures mensuelles
- Notre Maitre-Cookie peut consulter les commandes à préparer et les marquer expédiées
- Nous pouvons consulter facilement la liste des utilisateur·rice·s, commandes…
Stack technique
Application
Afin d’aller vite et d’être sûr de ce que je fais, je suis parti sur une techno que je connais bien, Ruby on Rails. Le timing était beaucoup trop court pour que je me risque à tester des techno qui me font de l’œil et que je connais moins.
La deuxième stratégie pour aller vite a été de coder le moins possible en me reposant sur des services/gem existants.
Voilà quelques gems bien pratiques que j’ai utilisées pour gagner du temps :
- simple_form — Pour générer simplement les formulaires
- devise — Pour gérer l’authentification (création de compte, login, perte de mots de passe…)
- activeadmin — Pour le backoffice admin et Maitre-Cookie
- high_voltage — Pour facilement faire des pages statiques
- aasm — Pour gérer les états des commandes avec une machine à état
- mail_form — Pour les commandes en batch
- haml-rails — Parce que… c’est bien plus lisible que du HTML
- bootstrap — Parce que je suis pas intégrateur
- rspec-rails — Pour les tests (toutes les fonctionnalités importantes sont testées par des tests d’intégration)
- vcr — Pour enregistrer automatiquement les réponses des API/services pour les tests
Coté service, j’ai gagné beaucoup de temps en me reposant sur Chargebee et Stripe pour toute la partie paiement (paiement récurrent, facture mensuelle, coupons de réduction…). Pour le moment, les pages pour le paiement sont hébergées par Chargebee, donc j’ai même pas eu besoin de coder ça. C’est bien mieux coté sécurité et j’ai gagné un temps considérable.
Hébergement et déploiement
Pour l’hébergement, l’application est hébergée sur Heroku, là aussi par soucis de gagner du temps. Pour le moment, nous avons 2 environnements (staging et production). L’ensemble nous coûte… 0€ par mois pour le moment !
J’utilise certains addons Heroku :
- Rollbar — Log de toutes les erreurs ont lieu en production
- Sendgrid — Envoi des emails
- NewRelic — Surveillance des performances de l’application (serveur et front)
- LogEntries — Consultation simplifiée des log de l’application
- Heroku Scheduler — Cron
- Codeship CI — Intégration/déploiement continu
Tout le code est hébergé sur Github.
Les DNS sont gérés par Cloudflare. En plus, cela me permet d’avoir du SSL, du HTML/CSS/JS minimisé et mis en cache, un CDN…
A chaque commit pushé sur Github, les tests sont exécutés via CodeShip CI. Si les tests réussissent, l’application est déployée en staging, sinon on a un gros message rouge dans Slack.
Pour le moment, je promeus la version de staging vers la production à la main, afin de me laisser la possibilité de tester en staging avant. Les tests commencent à être plutôt fiables, je songe à faire du déploiement continue vers la prod prochainement.
Les grandes étapes de l’application
Fin septembre l’application est créé et le sign up/in fonctionne.
Mi-octobre on peut créer des commandes et un thème de base (Bootstrap) est en place.
Fin octobre on peut consulter la liste des commandes passées et le back office (pour nous et la Maitre-Cookie) est créé. L’intégration avec Chargebee pour le paiement via Stripe est opérationnelle.
Début novembre nous commençons à gérer les envois de commandes par liste
Mi-novembre, je commence à faire une partie de l’intégration histoire de faciliter la tache à Erick qui va s’occuper du reste de l’intégration (que je ne sais pas bien faire).
Fin novembre, on travaille l’onboarding (on peut commencer à créer une commande sans être inscrit, on peut voir le dashboard avant d’entrer sa carte bleue… ). Ca a d’ailleurs été une belle galère car il a fallu quasiment inverser le process d’inscription en dernière minute suite à des retours utilisateurs.
On est passé de Inscription>Adresse d’exp>Carte Bleue>Commande à Commande>Inscription>Visualisation de l’interface utilisateur>Adresse d’exp>Carte Bleue
A ce moment, le site est utilisable. Nous nous en servons pour envoyer nos premières boites. Quelques jours après, nous ouvrons la beta au public et les premières commandes sont passées ! Le tout, sans bug !
J’ai quand même eu droit à quelques “Error R14 (Memory quota exceeded)” d’Heroku. Le problème a disparu en utilisant la gem “puma_worker_killer” et en passe WEB_CONCURRENCY à 1 pour le moment.
On paye 0€ par mois en ce moment pour faire tourner le site, on ne peut pas se plaindre s’il manque un peu de mémoire :)
Nous avons géré plusieurs centaines de commandes en un mois, le tout sans encombres (techniques, du moins). En décembre, j’ai ajouté quelques fonctionnalités pour nous aider à gérer le flow important de commandes : dashboard, possibilité de décaler une commande dans le temps, génération des étiquettes pour les messages personnalisés et les adresses…
Prochainement, je vais travailler sur une API pour que des clients puissent passer des commandes directement depuis leur CRM, leur back office, Zapier … si ça vous intéresse, contactez-nous pour qu’on en discute => hello@mercicookie.com
MerciCookie est un service de cadeaux d’affaires qui simplifie la vie des entreprises. Il permet d’offrir en quelques clics de superbes coffrets de cookies artisanaux “à tomber” à ses client·e·s, partenaires ou à son équipe !
