Ce que la première version doit permettre
Byte Force, au Technopark à Casablanca, écrit le plus petit logiciel qu'une personne peut déjà utiliser pour son problème. Si le vôtre attend encore d'être complet, le premier geste est de le décrire : [[/contact|parler du projet]].
Apprendre commence quand quelqu'un s'en sert
Cette note reprend un cadre public de Y Combinator. Une première version n'est pas un logiciel fini. C'est le plus court chemin pour mettre un geste réel entre les mains de quelqu'un, puis modifier ce geste. L'enquête, les entretiens et la comparaison des concurrents nomment la douleur. Ils ne disent pas si la solution tient, tant que personne ne s'en sert.
Le piège est de passer un an à préparer, lever, et recruter avant qu'un client touche une version qui marche. Le débutant qui livre trop vite et la personne qui livre exprès un petit morceau arrivent au même endroit : une version dehors. Celui qui veut d'abord tout comprendre n'y arrive pas.
La personne pressée, pas le public général
La personne dont le problème brûle accepte un outil imparfait, si ça l'avance aujourd'hui. Celle qui attend un produit poli ne l'adoptera pas, et ce n'est pas un client perdu : elle n'était pas le public de cette version. Airbnb, Twitch et Stripe sont des exemples publics de ce cadre, pas des projets de Byte Force. Leurs premières versions étaient étroites : un lit pendant un salon, une seule vidéo, des paiements encore en partie manuels.
Le premier iPhone est sorti sans boutique d'applications et sans vidéo. Le premier iPod cassait. Les versions connues sont venues après. Byte Force ne publie pas ces lancements comme les siens.
Couper la liste, garder le geste
Écrire la liste, puis retirer chaque ligne qui n'est pas nécessaire pour que la personne pressée commence aujourd'hui. Le reste attend une version suivante. On s'attache au problème de cette personne, pas au premier écran.
Une première séance qui casse ne ferme pas l'entreprise. L'associé ne part pas pour ça, et l'argent ne disparaît pas dans la nuit. On réécrit à la même personne une semaine plus tard, avec le geste corrigé. Un questionnaire dit où ça fait mal. Seule une version qu'on peut ouvrir dit si le logiciel le résout.
Byte Force ne promet pas un nombre de semaines valable pour tous. Le délai suit le nombre de rôles et de branchements. Une première version tient souvent en plusieurs semaines. Le logiciel sur mesure part du geste, pas du catalogue de fonctions.
Le cadre cité dit qu'il vaut mieux cent personnes qui s'en servent vraiment que cent mille qui passent. Ce n'est pas un chiffre de Byte Force. C'est le choix : apprendre sur un usage réel, pas sur une audience large qui n'a pas le problème.
Quand écrire
Écrivez si le logiciel est encore une liste, ou si une première version existe et que personne ne s'en sert. Dites le geste que la personne pressée doit pouvoir faire cette semaine, et ce qui peut attendre.
Le premier échange dure trente minutes et il est gratuit. La réponse part sous un jour ouvré. Écrire à Byte Force avec ce geste.
English
What the first version must allow
Byte Force, at Technopark in Casablanca, writes the smallest software a person can already use for their problem. If yours is still waiting to be complete, the first step is to describe it: talk about the project.
Learning starts when someone uses it
This note follows a public Y Combinator frame. A first version is not a finished product. It is the shortest path to put a real action in someone's hands, then change that action. Surveys, interviews and competitor lists name the pain. They do not say whether the solution holds until someone uses it.
The trap is to spend a year preparing, raising and hiring before a customer touches a version that works. The beginner who ships too fast and the person who deliberately ships a small piece arrive at the same place: a version outside. The person who wants to understand everything first does not.
The person in a hurry, not the general public
A person whose problem is urgent will use an imperfect tool if it moves them today. A person who wants a polished product will not adopt it, and that is not a lost customer: they were not the audience for this version. Airbnb, Twitch and Stripe are public examples of this frame, not Byte Force projects. Their first versions were narrow: a bed during a conference, a single video, payments that were still partly manual.
The first iPhone shipped without an app store and without video. The first iPod broke. The known versions came later. Byte Force does not publish those launches as its own.
Cut the list, keep the action
Write the list, then remove every line that is not required for the person in a hurry to start today. The rest waits for a later version. Stay with that person's problem, not with the first screen.
A first session that breaks does not close the company. A cofounder does not leave for that, and the money does not vanish overnight. You write to the same person a week later, with the action corrected. A survey says where it hurts. Only a version someone can open says whether the software resolves it.
Byte Force does not promise a number of weeks that fits everyone. The schedule follows the number of roles and connections. A first version often takes several weeks. Custom software starts from the action, not from a feature catalogue.
The frame cited here says it is better to have a hundred people who really use it than a hundred thousand who pass by. That is not a Byte Force figure. It is the choice: learn from real use, not from a wide audience that does not have the problem.
When to write
Write if the software is still a list, or if a first version exists and nobody uses it. Say the action the person in a hurry must be able to take this week, and what can wait.
The first conversation is thirty minutes and it is free. A reply goes out within one business day. Write to Byte Force with that action.