L'agence nous propose de développer notre outil en mode SaaS : qu'est-ce que ça implique pour nous ?

C'est le piège classique des agences. Vous aviez un besoin interne qui se règle pour 15-20k, ils ont requalifié le projet en SaaS pour doubler la facture. Est-ce que vous avez une équipe marketing, du support ou un réseau commercial pour vendre ce soft à d'autres boîtes ? Si la réponse est non, cette infrastructure ne servira strictement à rien.

Pour arbitrer, faites bien la distinction : 1) Outil interne : collé à vos process actuels, zéro besoin d'hyper-flexibilité. 2) SaaS : demande des réglages modulables, un panneau d'administration complexe et une passerelle de paiement pour s'adapter aux process d'autres boîtes. Si l'urgence c'est d'optimiser votre boîte, commencez par un simple outil pour votre équipe.

Pour notre propre activité logistique, on s'est lancés il y a trois ans avec la même motivation. On a payé 55 000 dollars pour faire construire une architecture SaaS. Le produit est devenu super beau mais on n'a pas trouvé le temps de le vendre à d'autres boîtes ; nos concurrents ne voulaient pas saisir leurs propres données dans notre système. On s'est retrouvés à payer 600 dollars de plus par mois en serveurs et maintenance.

Être éditeur de logiciel et être grossiste en produits alimentaires, c'est complètement deux métiers différents. Gérer un SaaS, ça veut dire : que ton téléphone sonne à minuit quand le serveur plante, des clients externes qui contestent leurs factures et des demandes constantes de nouvelles fonctionnalités. Quand le cœur de métier de ta boîte c'est la logistique, tu es prêt à ouvrir un centre de support logiciel du jour au lendemain ? Si la réponse est non, demande un logiciel interne plutôt qu'un SaaS.

Quand ils mettent en place une architecture multi-tenant, la séparation des bases de données sera logique ou physique ? Même si vous ne vendez pas à l'extérieur, les cycles de maintenance, de test et de mise à jour des systèmes codés en SaaS sont bien plus pénibles que ceux d'outils internes monolithiques qui ne servent qu'une seule entreprise.

Demandez un devis révisé à l'agence : « Si vous développez le même outil en simple panneau web mono-tenant juste pour notre usage interne, quel serait le budget et le délai ? » Le devis va probablement diminuer de moitié. En mettant les deux chiffres côte à côte la décision devient beaucoup plus facile.

les agences montent souvent la tête au client comme ça pour ajouter un produit stylé à leur portfolio. perso j'y mettrais pas les pieds faites-vous faire un truc simple qui répond à vos besoins, comme ça vous gardez vote argent et votre temps.

en fait l'idée n'est pas si mauvaise que ça, s'il y a vraiment un créneau comme ça dans le secteur ça peut devenir une super source de revenus complémentaires plus tard. franchement mais vous pouvez réduire le budget en disant à l'agence « on veut d'abord utiliser la première vresion en interne, gardez la base de données extensible pour plus tard mais ne faites pas encore les modules genre facturation ».

Ce qui est écrit correspond exactement à ce que nous avons vécu. Ce que tout le monde fait ne signifie pas que c'est la bonne chose.

Si le périmètre s'agrandit, il faut augmenter soit le délai, soit le budget. Il n'y a pas de troisième option. Bien sûr, cela change si votre situation est différente.

J'y pensais aussi. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois. Je le note au cas où.

J'aimerais poser une question... Tout va bien les trois premiers mois les problèmes arrivent au quatrième.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Trois avis différents sont sortis ils se complètent tous. genre mettre en place un processus de demande de changement n'ralentit pas le travail il l'accélère.

C'est mon avis je ne l'écris pas comme une vérité absolue.

Pourriez-vous préciser un peu ? Le calendrier de paiement doit être lié aux étapes du projet pas au calendrier lui-même.

Bien sûr cela change si votre situation est différente.

Il est rare de trouver un texte qui explique les choses aussi clairement. Tous ceux qui se pressent sur développement SaaS se heurtent au même obstacle.

Tout va bien les trois premiers mois, les problèmes arrivent au quatrième. C'est mon avis, je ne l'écris pas comme une vérité absolue.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Pourriez-vous préciser un peu ? Mettre en place un processus de demande de changement n'ralentit pas le travail, il l'accélère.

J'ai vécu exactement la même chose il y a deux ans. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

Voilà, désolé si je me suis étendu.

Je parle du point de vue du fournisseur, c'est mon côté. Quand on décide sans mesurer, on revient toujours au même point.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.