Les startups doivent se préparer au succès pour avoir du succès

Les entrepreneurs sont toujours à la poursuite du prochain jalon. Pendant un certain temps, il s'agit de faire votre premier dollar. Alors votre premier million. Si vous êtes chanceux – et bon – vous développez l'entreprise à un point où vous pouvez envisager une sortie. Parfois, c'est une introduction en bourse. Plus souvent c'est une acquisition.

Il est excitant de voir une grande entreprise s'intéresser à votre entreprise. Mais il est également stressant de passer sous le microscope d'un acheteur potentiel.

Le capot est en place. Maintenant, vous devez répondre à quelques questions fondamentales, y compris les plus importantes: Votre produit peut-il évoluer?

Vous avez toujours dit que c'est possible, mais le peut-il vraiment? Imaginez-vous tomber dans un Cisco ou un Microsoft ou un Salesforce avec une force de vente massive poussant votre produit. Gardez à l'esprit que l'échelle a un moyen de révéler tous vos raccourcis et hacks embarrassants. À quel point vous sentez-vous confiant maintenant?

Il est préférable de devancer les problèmes potentiels avant qu'ils ne surgissent. Les sociétés acquéreuses ont tendance à examiner certains aspects clés de votre produit, et c'est là que vous devez porter une attention particulière afin que les problèmes ne se posent pas dans les fusions et acquisitions.

Double-down sur la conception de données

Dans une application moderne, tout dépend des données et de l'évolutivité de votre base de données de transactions. L'infrastructure cloud évolutive a rendu l'architecture de données plus simple, mais elle doit toujours être l'une de vos principales priorités. Un acquéreur potentiel voudra voir que si vous servez 1 000 clients aujourd'hui, vous pourriez passer rapidement à 10 000 ou 100 000 clients.

Même si vous pouvez rapidement créer de nouveaux serveurs de base de données dans le cloud, vous rencontrerez des problèmes s'ils ne peuvent pas communiquer. Ce n'est pas aussi simple que d'exécuter dix serveurs de bases de données au lieu d'un seul. Du point de vue de la conception d'applications, vous avez toujours besoin d'eux pour travailler en harmonie. Il faut souvent des efforts supplémentaires pour rendre les données utiles sur les serveurs. Les carences dans ce domaine n'apparaîtront généralement pas avant que vous n'aggraviez, et à ce moment-là, il est trop tard. Si vous n'avez pas intégré la capacité depuis le début, il est extrêmement difficile d'ajouter plus tard dans le processus.

Ne pas oublier l'interface

L'évolutivité ne concerne pas seulement le back-end. Je connais une start-up dont les premiers clients comprenaient un service de partage de trajets pas encore très populaire. À l'époque, la plupart des clients de la startup ne conservaient que 20 transactions à la fois. L'application Web interne de la startup a été conçue pour gérer 50 – le double de la charge moyenne. Qu'est-ce qui pourrait mal se passer?

Le service de covoiturage s'est imposé, et soudainement, des centaines de milliers de transactions ouvertes ont été enregistrées dans la file d'attente. Personne n'avait pensé à paginer les données renvoyées par le serveur, donc chaque fois que quelqu'un accédait aux données de ce client, tout le système s'arrêtait alors que le serveur construisait une énorme table HTML.

La leçon que j'ai apprise était d'assumer un succès déraisonnable. Vous ne savez jamais quand la demande va grimper, donc à tous les niveaux de l'application, vous devez concevoir des ordres de grandeur supérieurs à ce que vous avez actuellement – pas seulement des services individuels, mais la messagerie entre services. Si vous extrapolez à partir des niveaux de trafic actuels, vous ne serez jamais prêt pour de grandes opportunités. Si vous n'êtes pas prêt à évoluer pour la croissance organique, vous ne serez pas prêt pour l'acquisition.

Respectez la résilience

La ​​résilience est étroitement liée à l'échelle – et tout aussi importante. Les choses vont se casser. Quand ils le font, ils doivent se séparer avec élégance. Quand la connectivité échoue, quand un bug pénètre dans votre code, est-ce que tout tombe en panne ou votre service arrête-t-il de faire une chose?

Avez-vous déterminé ce qui se passe quand différents composants échouent? Pouvez-vous automatiquement créer de nouveaux serveurs et distribuer le travail? Les nouveaux serveurs prennent-ils des tâches incomplètes?

Qu'en est-il de votre réseau? L'aspect le plus dangereux de votre infrastructure, du point de vue de la résilience, pourrait être le pare-feu. Certains administrateurs resserrent une règle de pare-feu, et soudainement les serveurs critiques sont coupés. Vous perdez l'accès aux processeurs de paiement tiers, aux services de carte, à tous les blocs de construction externes dont dépendent les applications modernes.

La meilleure approche consiste à commencer par un pare-feu totalement verrouillé, puis à rechercher des exceptions via un processus de demande de modification pour ouvrir les ports nécessaires. De cette façon, la sécurité a une trace de pourquoi chaque port est ouvert et n'a aucune raison de les fermer.

Verrouillez-le

Chaque organisation est vulnérable aux cyberattaques, aussi petites soient-elles. Mais une fois que vous intégrez dans une société Fortune 500, le niveau de menace augmente considérablement. Les criminels viendront à vous, mais ils peuvent. Les acquéreurs le savent et veulent voir à quel point vous avez verrouillé votre code et vos processus de sécurité.

Pour couvrir les bases, vous devez exécuter des tests de pénétration au niveau de l'application et du réseau. Il est souvent plus efficace de faire venir des consultants en sécurité de l'extérieur. Non seulement la plupart des startups manquent d'expertise en sécurité, mais il est difficile pour n'importe quelle organisation de trouver ses propres angles morts. Une perspective extérieure peut repérer les vulnérabilités à l'air libre.

Bien que cela puisse sembler beaucoup à gérer, c'est plus que faisable. Vous avez juste à le faire avant que les acheteurs potentiels viennent frapper. Cela signifie se concentrer sur les aspects les moins glamour de votre architecture quand il semble que tout le monde – clients, bailleurs de fonds, même vos propres employés – vous pousse à ajouter des fonctionnalités.

Personne ne veut acheter un "fixeur" s'il peut l'éviter, mais personne n'attend la perfection. Si vous avez le bon état d'esprit, et plus important encore, agissez dessus, vous serez en avance sur vos concurrents et dans la meilleure position possible pour faire le saut vers les majors.