Je ne cherchais pas à créer une firme de conseil.

Mon parcours est passé par l'assurance qualité, puis le développement logiciel, puis des rôles d'ingénieur fondateur, puis celui de CTO dans une startup en phase initiale — où j'ai porté absolument tous les chapeaux techniques qui existaient. Architecture, recrutement, processus, décisions produit, infrastructure, alignement des développeurs avec les priorités d'affaires. Tout ça, souvent en même temps.

Ce parcours m'a donné quelque chose que je ne tiens pas pour acquis : une vision complète de la façon dont les décisions techniques se concrétisent réellement à l'intérieur d'une entreprise. Pas seulement le code — mais les gens qui l'écrivent, les fondateurs qui en dépendent, les échéanciers qui y sont rattachés, et ce qui arrive quand l'un de ces éléments se désynchronise.

La période pro bono

Pendant un peu plus de six mois avant de lancer Helix, je faisais du conseil pro bono. Pas par stratégie — ça a commencé organiquement, en aidant des fondateurs et des équipes avec lesquels j'avais des liens à traverser des problèmes techniques.

Ce que j'ai constaté, de façon constante, c'est que le fossé n'était pas le talent. La plupart des équipes avaient des gens compétents. Le fossé était dans la façon dont le travail technique était structuré, communiqué et livré. Des exigences insuffisamment claires avant le début du développement. Des développeurs construisant les bonnes choses dans le mauvais ordre. Des fondateurs sans suffisamment de visibilité pour corriger le tir avant que de petits problèmes ne deviennent des problèmes coûteux.

Cette demi-année m'a clairement montré qu'il y avait un vrai marché pour ce que je faisais déjà. Helix en a découlé naturellement.

La question de la propriété du code

Celle-ci est personnelle.

J'ai vécu ça côté client. J'ai travaillé dans une entreprise qui avait fait appel à un développeur externe pour construire une partie centrale du produit. Quand la relation s'est terminée, maintenir ce code et continuer à le faire évoluer est devenu un problème sérieux. L'entreprise ne possédait pas vraiment ce qu'elle avait payé pour construire.

Cette expérience est directement la raison pour laquelle la propriété du code est un principe chez Helix — et non une simple politique. Tout ce que nous construisons va dans des dépôts sous votre compte. Vous pouvez prendre le travail, l'étendre, le confier à une autre équipe, ou passer à autre chose. Le logiciel vous appartient, sans conditions, dès le premier jour.

Pourquoi il n'y a pas de gestionnaires de comptes

Je ne suis pas un vendeur de métier. Je suis un bâtisseur, un ingénieur, un planificateur — quelqu'un qui fait livrer les choses.

La structure sans gestionnaire de compte n'est pas une décision de coûts — c'est le reflet de ce qui aide vraiment les clients. Quand vous travaillez avec Helix, vous travaillez directement avec les personnes qui construisent votre produit. Aucune couche pour traduire entre ce dont vous avez besoin et ce qui est construit. Moins de transferts, moins de pertes en traduction, et une équipe qui est responsable parce qu'il n'y a nulle part où se cacher derrière le processus.

Ce que le mot « vraiment » signifie

Le texte de ce site dit des choses comme « des plateformes web qui livrent vraiment » et « un partenaire de développement sur lequel vous pouvez vraiment compter. » Ce mot fait un vrai travail.

J'ai été dans la salle quand les choses ne livraient pas. J'ai vu des produits prometteurs stagner parce que la fondation technique n'était pas solide, le processus n'était pas aligné, ou l'équipe n'avait pas le bon accompagnement au bon stade. Je sais à quoi ressemble une bonne exécution — et ce que ça coûte quand elle est absente.

Le « vraiment » vient de cette expérience. Ce n'est pas une ligne marketing. C'est la chose précise que nous sommes là pour faire différemment.

Ce que je veux pour les entreprises avec lesquelles nous travaillons

Je veux voir votre idée réussir. Je suis adaptable sur les outils et les processus — je ne vous imposerai pas une méthodologie, mais je vous guiderai vers ce qui a du sens pour votre stade actuel. Je sais comment recruter et motiver des développeurs logiciels en SaaS. Je sais comment aligner des équipes sur les exigences et les maintenir en mouvement.

Ce que je ne ferai pas, c'est vous vendre un rêve ou gonfler le travail. L'objectif est de livrer des résultats — et de vraiment me soucier que ce que nous construisons ensemble mène quelque part.

C'est autour de ça qu'est bâti Helix. Ça a pris du temps d'en arriver là, mais c'est là que j'ai toujours été destiné à aller.