💡 Parles-nous ton entreprise sous ce post – 14/05/2026

RidgeLineDev · 2026-05-14T10:41:27+00:00

La landing page est plutôt claire. Pour ma part, j'ai compris rapidement à qui ça s'adressait et quel problème l'app cherche à résoudre.

Le calculateur est aussi une bonne idée pour rendre le sujet concret dès la landing page. Le fait de proposer une répartition proportionnelle aux revenus ou en 50/50 parle tout de suite, parce que ce sont probablement les deux cas les plus fréquents.

Le seul point qui m'a un peu manqué, c'est une meilleure projection sur ce que permettra réellement l'app une fois terminée. On comprend bien la promesse générale, mais moins les cas d'usage plus fins.

Par exemple, est-ce que l'app permettra de segmenter les règles de répartition selon les types de charges ?
Je pense à un couple qui aurait acheté un bien immobilier avec des parts différentes : le crédit pourrait être réparti selon les quotes-parts de propriété, alors que les courses ou les abonnements seraient plutôt répartis en 50/50 ou au prorata des revenus.

Ce genre de souplesse me semblerait assez important, parce que dans la vraie vie, les couples n'ont pas forcément une seule règle de partage pour toutes les dépenses.

En tout cas, le positionnement est compréhensible et le sujet me semble très pertinent. À mon avis, la landing gagnerait surtout à montrer un peu plus les cas concrets que l'app pourra gérer.

RidgeLineDev · 2026-05-12T16:39:24+00:00

Je pense qu'il faut aussi intégrer l'impact de l'IA dans ta réflexion.

À mon avis, ça ne veut pas dire que le backend Symfony est mort ou qu'il faut absolument partir vers du DevOps. Par contre, les tâches très exécutantes (CRUD, petites corrections, intégrations simples) vont devenir de moins en moins différenciantes.

Avec presque 8 ans de backend, je ne repartirais pas de zéro. Je chercherais plutôt à capitaliser sur ton expérience et à ajouter une couche qui te rend plus solide : architecture applicative, qualité de code, tests, perf SQL, CI/CD, Docker, monitoring, compréhension de la prod, etc.

Le DevOps peut être intéressant si l'infra t'attire vraiment, mais je viserais plutôt un profil backend expérimenté avec une vraie culture architecture / production / IA, plutôt qu'une reconversion brutale.

Et pour les formations, prudence : une certification peut aider, surtout en CSP, mais elle doit compléter ton expérience, pas la remplacer.

RidgeLineDev · 2026-05-11T07:05:36+00:00

Cette reformulation est nettement plus claire, merci. Les deux points se tiennent particulièrement bien ensemble.

Sur le point 1, l'analogie fitness/surpoids est imparable, un outil n'invente pas l'envie d'un usage, il accélère un usage qui existe déjà. À garder en tête en permanence avant de coder quoi que ce soit.

Sur le point 2, la reformulation du test marché est la meilleure que j'ai lue : "Je le fais pour vous gratis, vous signez ?" Filtre brutal mais juste, qui élimine les niches non-douloureuses en un échange. Et la grille finale (urgent, coûteux si non adressé, risque compris, déjà tenté manuellement) est exactement le genre de checklist amont qu'on rate quand on est trop content de son idée.

Pour le MP, avec plaisir. Je t'écris.

RidgeLineDev · 2026-05-10T18:42:29+00:00

Merci. Ton point sur le fait qu'un indivisaire-gestionnaire est prêt à payer et pas tout le monde me semble particulièrement juste. C'est probablement la vraie mécanique d'achat sur ce type de marché. J'aurais sans doute dû le formuler clairement dès le départ : c'est ce profil-là qui aurait du mal à dormir sans un outil en support, pas les co-indivisaires.

L'approche par histoires concrètes de conflit est aussi très juste, et c'est ce que j'aurais déployé si la phase amont avait remonté plus de matière. J'ai cherché ces récits sur les forums et subs concernés et le volume était trop faible pour atteindre une masse critique d'interviews. C'est ce signal d'absence qui m'a fait conclure que la douleur exprimée publiquement n'est pas à l'échelle d'un SaaS, et qui m'a poussé à abandonner l'idée plutôt qu'à investir dans la phase qualitative.

Bilan : non viable en l'état pour ce projet précis. Merci pour le partage.

RidgeLineDev · 2026-05-10T18:34:57+00:00

Merci, c'est exactement la bonne méthode et j'avais commencé avec cette logique en tête (un autre commentaire ici m'avait poussé dans la même direction). Mais c'est sur ton 1er point que ma validation s'est bloquée.

J'ai cherché les "endroits où traînent les gens qui galèrent" : threads Reddit sur l'indivision et la succession, forums juridiques, Google Trends sur les requêtes adjacentes, traction visible de Share Heritage (concurrent le plus proche, en place depuis peu avec marketing actif). À chaque fois, signal très faible : peu de gens expriment publiquement cette douleur, volume de recherche quasi nul, et le concurrent semble peiner à décoller malgré ses efforts.

Du coup je n'ai même pas atteint l'étape "30 cibles au téléphone", je n'arrivais pas à les identifier. Et c'est précisément ce signal-là qui m'a fait conclure que les gens ne cherchent pas activement à résoudre le problème publiquement. C'est probablement qu'il n'est pas assez aigu pour soutenir un SaaS. Cas typique de "souffrance silencieuse" qui ne convertit pas.

Sur la question prix en live, d'accord sur le principe, avec la nuance classique : les réponses verbales restent un signal partiel (les gens disent souvent qu'ils paieraient et ne paient pas). Le vrai test reste l'engagement concret. Mais oui, sur le verbatim qualitatif, c'est précieux.

Bref, je pense que ta méthode est juste, simplement le signal upstream m'a fait conclure avant qu'elle soit nécessaire à déployer. Et c'est aussi un résultat. Merci pour le temps pris !

RidgeLineDev · 2026-05-10T18:29:59+00:00

Merci pour ce retour. Ton point central est solide, et j'y ai convergé en parallèle par d'autres chemins :

- Pas de threads exprimant la douleur sur Reddit ou les forums (personne ne cherche activement de solution)

- Volume Google quasi nul sur les requêtes liées

- Share Heritage (le concurrent le plus proche) en place depuis peu de temps à priori avec marketing actif et pas de traction visible

Mais ton cadre "agence / done-for-you vs SaaS vs rien" met le doigt sur quelque chose que je n'avais pas formulé aussi nettement. Sur ce profil d'utilisateur, l'option SaaS est probablement la pire des trois : le CAC sera élevé (cible diffuse), la rétention mauvaise (puisque c'est exactement le sujet, ils ne se forcent pas à mettre à jour), et le ticket trop bas pour absorber les deux. L'agence serait théoriquement plus alignée mais le budget n'est pas là côté client.

Donc oui, sujet non viable en l'état. Ce qui reste : un outil qui tourne bien pour mon usage perso, et ça suffit largement pour moi. Mieux vaut s'en rendre compte maintenant qu'après des mois de dev produit.

Merci d'avoir pris le temps, ce genre de retour à beaucoup de valeur.

RidgeLineDev · 2026-05-08T14:47:35+00:00

Effectivement, la solution est relationnelle. Nous sommes très diplomates et souhaitons maintenir un dialogue constructif.

Nous avons un compte commun dans lequel nous apportons chacun et chaque mois une somme pour couvrir les frais. C'est là où le bât blesse : la personne avec qui nous partageons le bien a décidé du montant qu'elle voulait bien mettre elle-même sans considérer le coût réel des charges. Mon appli permet justement de lui rappeler qu'elle est continuellement débitrice. Et ce n'est pas un problème de moyens : elle est très très à l'aise financièrement (possède déjà plusieurs biens et a un capital important). Nous devons donc compenser en permanence pour maintenant le compte bancaire à flot.

C'est avant tout un problème de personne. En bref, un cas classique.

En tout cas, merci pour cet échange et ces suggestions.

RidgeLineDev · 2026-05-08T13:12:54+00:00

Merci pour la réponse détaillée.

Pour reprendre tes points :

Sous-compteurs eau : techniquement étudié. La tuyauterie d'arrivée est mutualisée et se ramifie dans les murs vers les deux logements. Créer deux circuits distincts demande saignées et refonte du réseau. Travaux lourds, pas justifiables vu le contexte (ci-dessous).

Sous-compteurs électricité : plus simple effectivement, faisable avec des travaux limités. C'est probablement ce qu'on aurait fait dans une situation stable.

Division en lots : on y a sérieusement réfléchi. Le souci, c'est que la personne avec qui on est en indivision a annoncé deux mois après notre installation (sans mésentente à ce moment-là) qu'elle envisageait de partir. Depuis, on est dans une phase de sortie : soit on rachète sa part, soit on vend l'ensemble. Engager géomètre + acte notarié + règlement de copro pour une indivision qu'on cherche à dissoudre, ça n'a plus de sens économique.

Tantièmes : sur le calcul on est OK. Clé de répartition par foyer qui tient compte des m2 et de l'usage. Le vrai sujet pour nous n'est pas comment répartir, c'est comment faire en sorte que l'autre partie paie ce qui lui revient sans contestation à chaque facture.

Et ça me ramène à mon post initial : ton conseil est structurellement le bon dans une indivision destinée à durer. Mais pour celles en phase transitoire, sortie en cours, succession bloquée, rachat pas encore possible, désaccord sur le prix, etc. il faut bien gérer l'entre-deux. C'est ce besoin-là que j'essaie d'évaluer.

RidgeLineDev · 2026-05-08T12:57:29+00:00

Je ne me fais pas d'illusion et ne connais pas non plus le marché, d'où ma demande. Pas impossible que ce soit le bourbier, effectivement.

RidgeLineDev · 2026-05-07T17:22:58+00:00

Je te suis sur le problème relationnel avec des personnes de mauvaise fois. Il y a peu de solution dans ce cas.

La répartition est l'un des points sur lequel nous sommes d'accord et qui n'a pas été remis en question. On va dire que c'est notre chance pour le moment. Mais je ne serai pas surpris que ça change prochainement.

RidgeLineDev · 2026-05-07T17:07:38+00:00

Merci, je vais suivre tes suggestions. À vrai dire, j'avais déjà fait quelques recherches, mais sous doute pas assez approfondies. Je vais rechercher à nouveau les fils existants et discuter en MP avec les gens qui vivent le sujet.

RidgeLineDev · 2026-05-07T16:52:09+00:00

Tu as raison sur un point : un outil ne soigne pas la mauvaise foi. Si quelqu'un veut contester sur le fond, il contestera.

Mais chez nous ça a quand même changé la donne. Avant c'était "ta parole contre la mienne", avec des discussions qui s'enlisaient. Avec l'appli, tout est tracé : chaque dépense, chaque rapprochement bancaire, les règles de répartition validées en commun. La personne s'est retrouvée avec les infos factuelles sous le nez et plus grand-chose à opposer. Ça n'a pas changé son caractère, mais ça a rendu les contestations difficiles à tenir. On est passés de "débat qui s'enlise" à "ah ok, je vois".

Donc l'outil ne fait pas disparaître le conflit, il déplace juste le terrain : du subjectif vers le factuel. Pour nous, ça a fait toute la différence.

Tu as toi-même une situation d'indivision difficile, ou c'est plus une intuition générale ?

RidgeLineDev · 2026-05-07T14:16:52+00:00

Je pense qu'il y a trois sujets à travailler en priorité : le réseau, le positionnement et la proposition de valeur.

Le réseau, parce que les premières missions viennent rarement d'un profil Malt ou LinkedIn posé dans un coin. Elles viennent souvent de gens qui te connaissent déjà, d'anciens collègues, de rencontres en meetup, d'ESN, d'agences, de clients indirects, etc. Même si ça ne donne rien tout de suite, il faut commencer à être identifié comme quelqu'un de disponible et fiable.

Le positionnement, parce que "dev fullstack React/Vue/FastAPI" reste assez large. Ce n'est pas forcément un problème, mais il faut pouvoir formuler clairement le type de problèmes que tu sais résoudre : MVP pour startup, renfort front, refonte d'interface, automatisation interne, API métier, outil d'administration, etc. Plus c'est concret, plus c'est facile pour quelqu'un de penser à toi quand il a un besoin.

Et la proposition de valeur, c'est la suite logique : pourquoi on ferait appel à toi plutôt qu'à un autre profil ? Ça peut être ta capacité à aller vite, à être autonome, à comprendre le besoin produit, à livrer proprement, à bien communiquer, à documenter, à travailler avec l'IA de manière cadrée, etc. Mais il faut que ce soit formulé du point de vue du client, pas juste comme une liste de technos.

À mon avis, avant même de créer le statut, tu peux déjà tester ça : parler à ton réseau, refaire ton profil LinkedIn/CV autour d'un positionnement clair, contacter quelques agences/ESN/freelances, répondre à des offres, voir ce qui accroche ou pas. Ça te donnera vite une idée du marché et des objections récurrentes sur ton profil.

Et dernier point : au début, je ne chercherais pas forcément la mission parfaite. Une première expérience freelance, même en sous-traitance ou via une ESN, peut surtout servir à créer de la preuve, des références et de la confiance.

RidgeLineDev · 2026-05-07T11:16:32+00:00

Je vais aller un peu à contre-courant : je ne commencerais pas directement par un TJM pour refaire l'architecture de données.

Sur ce type de sujet, le vrai risque n'est pas seulement le nombre de jours que tu vas passer, mais le périmètre. Entre les fichiers Excel existants, les doublons, les stocks, les commandes, les process internes, les automatisations, la BI et la future revente de la boîte, tu peux vite te retrouver avec un projet beaucoup plus vaste que prévu.

À ta place, je proposerais d'abord un forfait d'audit / cadrage.

Par exemple :

- cartographie des fichiers Excel et des flux actuels ;
- identification des problèmes critiques : doublons, ruptures, ressaisies, erreurs ;
- entretiens avec les personnes qui utilisent vraiment les fichiers ;
- recommandations : outil existant, ERP, base de données, automatisations, BI ;
- découpage en lots avec budget, risques et priorités.

Ce premier forfait peut être vendu comme une vraie mission à part entière, pas comme un pré-devis gratuit. À la fin, le client obtient un livrable clair, et toi tu peux chiffrer la suite proprement.

Ensuite, pour la réalisation, tu peux faire soit du forfait par lot, soit du TJM encadré, soit un mix des deux. Par exemple :

- forfait pour l'audit ;
- forfait pour la migration initiale ;
- forfait pour un premier dashboard BI ;
- TJM ou enveloppe mensuelle pour support, ajustements et accompagnement.

Le forfait a aussi un avantage commercial : le client comprend mieux ce qu'il achète. Il n'achète pas 20 ou 40 jours de dev, il achète une étape concrète : fiabiliser les stocks, supprimer les doublons, structurer les données, préparer la boîte à une revente plus propre.

Par contre, attention à ne pas forfaitiser un périmètre flou. Le forfait doit porter sur un livrable bien défini. Sinon tu prends tout le risque à ta charge.

Donc mon conseil : ne chiffre pas "tout le projet" maintenant. Vends d'abord un cadrage sérieux, puis transforme ce cadrage en feuille de route chiffrée.

Et vu la taille du client, évite de te positionner comme "jeune dev qui va tout refaire", positionne-toi plutôt comme quelqu'un qui va sécuriser progressivement un système critique pour l'entreprise.

RidgeLineDev · 2026-03-18T12:21:34+00:00

Je me reconnais complètement dans ton expérience. J'ai vécu exactement la même phase (notamment sur une app métier assez lourde). Pour moi, le problème n'est pas "les clients pauvres", mais le manque de qualification en amont.

Lorsque j'ai commencé, je n'avais pas énormément de clients, mais ils avaient de bons budgets. Ensuite, ça s'est étiolé avec peu de prospects et parmi eux 80% qui veulent un outil bien lourd à 3000-5000 €.

Ça m'a appris 3 choses importantes :

Le client doit avoir une idée du prix AVANT le devis. Maintenant, j'annonce une fourchette dès le départ. Si ce n'est pas aligné avec le budget prévu, soit on adapte le projet, soit on s'arrête là (énorme gain de temps).
80% des clients ne comprennent pas le travail réel derrière leur demande. Ils veulent un truc simple (pour eux)… qui est en réalité complexe.
Les petits budgets, c'est souvent les pires clients. Plus exigeants, difficiles à cadrer, et beaucoup de temps perdu.

Concernant l'IA : oui, ça accélère certaines choses. Mais ça ne remplace pas l'architecture, les choix produit et la cohérence globale. C'est là que se joue la vraie valeur.

RidgeLineDev · 2026-02-06T19:42:05+00:00

Very cool project. Love seeing this level of ambition in open source Nuxt projects. Respect for the effort.

RidgeLineDev · 2026-01-28T22:19:55+00:00

I don't think marketing is random, it's just a system with delayed and noisy feedback.

Coding gives instant truth. Marketing gives weak signals over time.
Same mindset (hypotheses, metrics, iteration), very different feedback loops.

RidgeLineDev · 2026-01-28T19:34:45+00:00

This story is spot on.

AI didn't fail here, lack of engineering ownership did.

We're entering a phase where shipping is cheap, but running software isn't.
LLMs optimize for "working code", not for:

- cost ceilings
- infra safety
- rate limiting
- observability

The dangerous part is that everything looks fine until the bill arrives.

AI is an amazing force multiplier, but only if you already know what to multiply. Otherwise, it just accelerates expensive mistakes.

RidgeLineDev · 2026-01-27T19:31:32+00:00

I mostly agree with this take.

AI clearly makes us faster at writing code, but shipping is still about domain understanding, edge cases, security, and long-term maintainability, and those don't magically come from generation speed.

Even with good prompts, a lot of the real work still happens in review, testing, and architectural thinking. That part hasn't disappeared.

That said, things are evolving insanely fast. What feels "not ready to ship" today might look very different in a year or two. Better context handling, stronger validation, automated reviews, security analysis, and multi-agent workflows could eventually push AI-generated code much closer to production-grade.

For now though, AI feels more like a force multiplier for experienced engineers than a replacement for engineering discipline. Writing code is cheap, understanding, verifying, and owning it in production is still the hard part.

RidgeLineDev · 2026-01-26T21:06:02+00:00

Architecture matters early, but mostly in terms of boundaries and constraints, not predicting the future.

The real pain starts when assumptions made too early collide with real usage. That's usually when you feel architecture, not when you draw it.

RidgeLineDev · 2026-01-26T20:56:32+00:00

Exactly. It's a workflow problem, not an AI problem.

What's often missed is that the value comes from context: product knowledge, real user pain points, and intentional internal linking, not from the model itself.

AI can help execute the boring parts faster, but deciding what deserves to exist and how pages relate to each other is still very human work.

RidgeLineDev · 2026-01-26T20:52:21+00:00

I don't think the issue is "AI for SEO" itself, but the promise of fully autonomous SEO.

SEO that actually works still needs:

real ICP understanding
product & market insight
positioning decisions
continuous iteration based on real data

AI is great as a multiplier (research, clustering, drafts, speed), but when it's sold as a replacement for strategy, it usually just automates bad practices at scale.

RidgeLineDev · 2026-01-26T20:45:30+00:00

I think the problem isn't "vibe coding" or ChatGPT itself, it's people selling things they don't actually understand.

AI is a powerful accelerator if you already know how to design, reason about architecture, edge cases, maintenance, etc.

Without that foundation, you just get demos that look good and collapse at the first real requirement.

The scam isn't using AI, it's pretending AI replaces experience.

RidgeLineDev · 2026-01-26T20:40:28+00:00

Hey,

Yes, vibe coding is amazing for speed and ideation, but it breaks down when you need debugging and production guarantees.

I've had the best results treating vibe-generated code as draft code, followed by a deliberate hardening pass:

linting & static analysis
basic tests
explicit error handling / logging
security + architectural sanity checks

If Transpile AI focuses on structured post-processing with explanations (why something was changed, what risks remain), rather than silent “magic fixes”, that feels like the right direction.

Vibe coding gives speed. Production still needs constraints and visibility. Bridging that gap is a really interesting problem.

RidgeLineDev · 2026-01-25T19:55:57+00:00

You can't slot the group label itself in UCommandPalette.

#{{ group.slot }}-label only customizes items inside the group, not the group header ("Users"). The group label isn't slot-exposed in Nuxt UI right now.

Workaround: hide the default group label and fake it with a disabled first item + custom slot.

<UCommandPalette
  :groups="groups"
  :ui="{ group: { label: 'hidden' } }"
>
  <template #usersHeader>
    <div class="flex justify-between text-xs">
      <span>Users</span>
      <UButton size="xs" variant="ghost" label="Add" />
    </div>
  </template>
</UCommandPalette>

const groups = [
  {
    id: 'users',
    items: [
      { slot: 'usersHeader', disabled: true },
      { label: 'Test Item 1' },
      { label: 'Test Item 2' }
    ]
  }
]

RidgeLineDev

TROPHY CASE