Produit sur mesure

Par lots fonctionnels. Chaque lot est cadré, développé, livré et testé avant de passer au suivant, avec un point d'avancement régulier. Vous voyez le produit tourner tout du long au lieu d'attendre plusieurs mois une grande démonstration. C'est aussi ce qui permet de réorienter entre deux lots sans tout casser.

Sur la base du périmètre issu du cadrage détaillé, pas sur une grille de tarifs par fonctionnalité. Vous recevez un seul total, avec le périmètre écrit qui le justifie. Le montant affiché en haut de page est un point de départ : sur ce type de projet, l'écart entre deux produits vient du métier, pas du nombre d'écrans.

Il évolue toujours, et c'est sain : les premiers retours d'usage apprennent des choses. La règle est simple : le périmètre peut bouger entre deux lots, pas au milieu d'un lot. Un changement significatif fait l'objet d'un avenant chiffré avant d'être engagé. Vous ne découvrez jamais une rallonge sur une facture.

Oui sur le développement, et c'est un choix. Vous parlez à la personne qui écrit le code et qui prend les décisions techniques, sans chef de projet intermédiaire. Sur le design poussé ou la rédaction, je travaille avec des indépendants que je connais, et je reste votre interlocuteur unique. Si votre projet demande plusieurs développeurs en parallèle dès le départ, je vous le dirai au lieu de prendre le contrat.

Un produit qui porte votre business ne s'arrête pas à la mise en ligne. Les évolutions et la maintenance se traitent au devis, ou à la journée selon mes disponibilités. Vous pouvez aussi reprendre la main avec votre propre équipe : tout est documenté pour ça.

C'est une question légitime quand on travaille avec un indépendant. Le projet avance par lots livrés et testables, et tout ce qui est produit est documenté au fur et à mesure pour qu'un autre développeur puisse reprendre. Si vous voulez une remise du code à chaque lot plutôt qu'à la livraison finale, on le prévoit au contrat. Dites-le moi avant la signature.

Oui, à condition de commencer par en faire l'état des lieux. Reprendre du code écrit par quelqu'un d'autre demande de comprendre ce qui tient et ce qui doit être refait. Je vous dirai franchement si la reprise est raisonnable ou si vous payez pour maintenir quelque chose qu'il vaut mieux reconstruire.

Principalement Angular côté interface, avec Symfony ou Firebase côté serveur selon le besoin, et Ionic avec Capacitor pour le mobile. Le choix se fait au cadrage, en fonction de votre produit et de ce que vos futures équipes sauront reprendre. Une technologie que personne ne sait maintenir est un mauvais choix, même si elle est bonne.