Développement sur mesure

Certains problèmes ne se résolvent pas avec un site web. Quand le besoin est un outil, une intégration ou un processus qui ne devrait plus se faire à la main, c'est cela que nous construisons.

Une équipe petite, expérimentée, et honnête sur le périmètre. Si un produit existant résout déjà votre problème, nous vous le dirons plutôt que de vous facturer pour le reconstruire.

Registre

Le type de projets que nous menons

Une bonne façon de décrire un logiciel sur mesure est par le problème qu'il élimine. Voici les cas de figure qui reviennent le plus souvent, et ce que nous finissons généralement par construire.

Types de problèmes et leur réponse habituelle
Le problème Ce que nous construisons
La même tâche manuelle, chaque jour, effectuée par une personne trop qualifiée pour ça Un outil interne où les étapes sont codées une bonne fois pour toutes : un formulaire, une file d'attente, un historique clair, et des permissions qui correspondent à la façon réelle de travailler de l'équipe.
Deux systèmes qui refusent de communiquer entre eux Une intégration qui prend en charge la correspondance entre eux, relance en toute sécurité quand un côté est indisponible, et vous prévient quand quelque chose nécessite une intervention humaine.
L'activité qui repose sur un tableur que personne n'ose toucher Une petite application web avec un vrai modèle de données derrière, pour que deux personnes puissent travailler en même temps et que les chiffres du trimestre dernier ne puissent pas être écrasés par accident.
Un rapport que quelqu'un assemble à la main chaque semaine Une tâche planifiée qui rassemble les données, les vérifie, et livre le rapport aux personnes concernées, avec un historique de chaque exécution.
Un parcours client greffé sur un site vitrine jusqu'à ce qu'il cède Une véritable application à sa propre adresse, partageant le système de design du site pour que tout continue à ressembler à une seule et même entreprise.
Quelque chose que personne ne peut chiffrer parce que personne ne l'a cadré Une courte étape de cadrage : la plus petite version fonctionnelle définie par écrit, avec les parties que nous ne construirions pas listées tout aussi clairement.

Discernement

Comment nous décidons quoi construire

  • La plus petite chose qui fonctionne, d'abord. Un outil restreint en production vous apprend plus en deux semaines qu'une spécification complète en un trimestre, et il peut être étendu une fois que vous savez quelles parties comptent vraiment.
  • Une technologie volontairement sobre. Nous choisissons l'option éprouvée plutôt que l'option intéressante. Un logiciel sur mesure se juge le jour où quelqu'un doit le modifier, pas le jour de son lancement.
  • Bien poser le modèle de données, tôt. Une interface se redessine à peu de frais, une donnée se restructure à grands frais ; la forme des données est donc arrêtée avant celle des écrans.
  • Acheter avant de construire. Si un produit sous licence couvre déjà votre cas, la recommandation honnête est de l'utiliser. Nous préférons construire la petite pièce qui le relie plutôt que vous facturer pour le réinventer.
  • Concevoir pour le second développeur. Du code lisible, une installation documentée, des tests qui expliquent l'intention. La mesure du travail, c'est si quelqu'un d'autre peut le modifier en toute sécurité.
Fig. 1 Interface, service, planification et stockage, dessinés avant même d'être écrits.

Standards

Ce que chaque projet livre systématiquement

Le même socle d'ingénierie que les sites web, parce qu'un outil interne est utilisé pendant des années par des personnes qui n'ont pas le choix d'en changer.

Un dépôt qui vous appartient

Historique complet, dans votre compte, avec une installation documentée assez clairement pour qu'une nouvelle machine fasse tourner le projet dès l'après-midi même.

Des vérifications automatisées

Tests et vérification des types s'exécutent à chaque modification, avant que quoi que ce soit n'atteigne les personnes qui en dépendent. Un test en échec bloque le déploiement.

Des déploiements en une commande

La publication est une étape unique et reproductible, et la version précédente n'est qu'un retour en arrière. Aucune mise en production assemblée à la main, aucun serveur non documenté.

Des interfaces accessibles

Les logiciels internes reçoivent le même support clavier, le même contraste et la même sémantique que le site public. Les équipes méritent le même niveau d'exigence que les clients.

Les secrets gardés hors du code

Les identifiants vivent dans un coffre-fort de secrets et atteignent le service en fonctionnement sous forme de variables d'environnement, jamais comme un fichier dans le dépôt.

Une voie de transfert

Comptes, domaines et dépôts peuvent être transférés vers votre propre organisation dès que vous le souhaitez, sans rien retenir en otage.

Périmètre

Où nous nous arrêtons

Être clair sur les limites fait partie de la confiance que nous inspirons. Nous sommes une petite équipe expérimentée : nous prenons les projets que nous pouvons bien mener, et nous disons non à ceux que nous ne pouvons pas.

Nous ne revendons pas de plateformes sous licence, nous ne staffons pas un projet que nous ne construisons pas nous-mêmes, et nous ne chiffrerons pas un problème qui n'a pas été cadré. Quand une partie du travail relève d'un spécialiste, nous vous le dirons clairement plutôt que de le découvrir à vos dépens.

Décrivez le problème sales@wwi.dev

Vous n'avez pas besoin d'une spécification pour commencer. Écrivez-nous via le formulaire de contact ou à sales@wwi.dev, et décrivez le projet avec vos propres mots.