Systèmes et données
Concurrence, tolérance aux pannes, et le modèle de données sur lequel tout le reste repose. La personne qui décide comment un système se comporte le pire jour, pas le meilleur.
Elixir, OTP, Ash, Oban, Postgres
00 Le studio
Trois ingénieurs. Pas d'organigramme.
Nous ne sommes pas une entreprise qui a développé une couche de management. Nous sommes trois ingénieurs seniors qui ont continué à coder, pris les projets auxquels nous croyions, et en répondons nous-mêmes.
Démarrer un projetPourquoi nous existons
- 01 Ici, le logiciel est généralement vendu par des gens qui n'ouvriront jamais le code
- 02 Le travail est décroché par un senior et livré par qui était disponible
- 03 L'équipe disparaît la semaine suivant le lancement, quand les vrais problèmes commencent
- 04 Personne n'est responsable quand un système ne tient plus la charge deux ans après
↓
Nous avons construit le studio que nous aurions voulu embaucher : les personnes qui cadrent votre projet sont celles qui l'écrivent, et elles sont toujours là en année deux.
Avec qui vous travaillez
Trois fondateurs, à égalitéNous ne publions pas de titres. Les titres décrivent une hiérarchie, et il n'y en a pas ici — chaque fondateur possède un domaine, y a le dernier mot, et écrit du code en production chaque semaine.
Produit et interface
L'apparence, la sensation et la cohérence du logiciel à mesure qu'il grandit. Conçoit l'interface et la construit — pas une passation entre deux personnes qui ne se parlent jamais.
SvelteKit, Next.js, TypeScript, systèmes de design
Infrastructure et livraison
Où le logiciel tourne et comment il y arrive. Rend les mises en production routinières et les pannes visibles, pour que personne ne les découvre par un client.
Cloudflare, Terraform, CI/CD, observabilité
Comment nous travaillons
Vous parlez directement à ceux qui construisent
Pas de chargé de compte, pas de relais. La personne qui répond à votre question est celle qui a écrit le code dont il s'agit.
Nous livrons pour votre échéance, pas la nôtre
Un mois ou un an — le calendrier suit ce dont vous avez réellement besoin. Un MVP ou une première version fonctionnelle ne reste pas en phase de découverte pendant un trimestre ; il est mis en ligne et commence à recueillir des retours.
Rien n'est fusionné sans revue
Chaque changement est relu par un autre fondateur avant d'être déployé. Les revues vérifient d'abord l'approche, le style ensuite.
Nous savons dire non
Si un projet ne correspond pas — mauvaise stack, mauvais calendrier, mauvais problème pour nous — nous le disons plutôt que de prendre le travail et d'apprendre sur votre budget.
Nous restons impliqués
Tout vous appartient — vos dépôts, vos comptes cloud, vos données. Nous ne retenons rien en otage, et nous continuons à le maintenir et à l'améliorer bien après le lancement.
Ce que nous croyons
Une technologie sans surprise, choisie délibérément
Nous utilisons Elixir, Phoenix, SvelteKit et Terraform parce qu'ils sont documentés, faciles à recruter et éprouvés — pas parce qu'ils sont nouveaux.
La deuxième année est le vrai test
N'importe quoi peut fonctionner pour une démo. Ce qui compte, c'est de savoir si ça peut encore être modifié sans risque une fois que ceux qui l'ont construit sont partis.
La scalabilité est une décision de conception
Les systèmes ne deviennent pas scalables plus tard. Soit la concurrence et la gestion des pannes sont pensées dès la première ligne, soit la solution est une réécriture.
Petit et senior bat grand et hiérarchisé
Trois personnes qui codent toutes avancent plus vite qu'une équipe où la majorité de l'effectif sert surtout à coordonner le reste.
Où nous sommes
Basés au Maroc, nous travaillons à distance avec des clients où qu'ils soient. Nous travaillons en anglais, en français et en arabe — les trois mêmes langues dans lesquelles nous construisons nos logiciels.
Maintenant parlez-nous du vôtre.
Un court appel, une réponse honnête sur si nous sommes la bonne équipe, et un périmètre sur lequel vous pouvez budgétiser.
Démarrer un projet hello@elixiria.ma