Πώς να επιλέξετε Tech Stack για το πρώτο σας SaaS: ένας ειλικρινής οδηγός για ιδρυτές

Ρωτήστε δέκα μηχανικούς ποιο tech stack να χρησιμοποιήσετε για το πρώτο σας SaaS και θα πάρετε δεκαπέντε απαντήσεις, τρεις από αυτές με τη βεβαιότητα μιας θρησκείας. Οι περισσότερες από αυτές τις απαντήσεις είναι σωστές — για το άτομο που τις δίνει. Καμία τους δεν αφορά εσάς, το runway σας ή τους πελάτες που δεν έχετε ακόμη κερδίσει. Αν είστε ιδρυτής που κοιτάζει αυτή την απόφαση και νιώθει ελαφρώς άρρωστος, να αυτό που κανείς δεν λέει φωναχτά: το stack μετράει πολύ λιγότερο απ' όσο σας έχουν κάνει να πιστεύετε, και οι λίγοι τρόποι που όντως μετράει δεν είναι αυτοί για τους οποίους μαλώνουν online.

Έχω βοηθήσει αρκετούς πρωτάρηδες ιδρυτές να περάσουν από μια παρουσίαση σε ένα προϊόν για το οποίο πραγματικοί άνθρωποι πληρώνουν. Σχεδόν κανείς τους δεν ήταν τεχνικός. Σχεδόν όλοι έφτασαν έχοντας ήδη απορροφήσει μια τρομακτική ποσότητα από μύθους περί stack — ότι χρειάζονταν microservices, ότι κάποιο framework ήταν «νεκρό», ότι μια λάθος επιλογή θα τους καταδίκαζε. Και σχεδόν κάθε φορά, το stack αποδεικνυόταν μία από τις λιγότερο σημαντικές αποφάσεις που πήραν εκείνη τη χρονιά. Αυτό που σκότωνε τα projects ήταν το scope, η ασαφής ευθύνη και το να χτίζεις όμορφα το λάθος πράγμα. Ποτέ το framework.

Αυτός λοιπόν είναι ο οδηγός που δίνω σε εκείνους τους ιδρυτές προτού γράψουμε μια γραμμή κώδικα. Δεν θα σας πει να χρησιμοποιήσετε ένα συγκεκριμένο stack, γιατί όποιος το υπόσχεται χωρίς να γνωρίζει την επιχείρησή σας πουλάει κάτι. Αντ' αυτού θα σας δώσει έναν τρόπο να σκέφτεστε — ώστε ό,τι κι αν επιλέξετε, ή ό,τι κι αν προτείνει η ομάδα σας, να μπορείτε να το ελέγξετε με νηφαλιότητα ενηλίκου αντί να γνέφετε νευρικά καταφατικά.

Γιατί αυτή η απόφαση μοιάζει πιο δύσκολη απ' όσο είναι

Το ζήτημα του stack μοιάζει τεράστιο επειδή είναι η πρώτη επιλογή που ακούγεται μη αναστρέψιμη, και είναι τυλιγμένη σε μια γλώσσα που δεν μιλάτε. Λέξεις όπως Postgres, React, Kubernetes, serverless πετιούνται σαν η επιλογή μεταξύ τους να ήταν σαν την επιλογή των θεμελίων ενός κτηρίου — κάντε λάθος και όλο καταρρέει.

Όμως το λογισμικό δεν είναι κτήριο. Είναι πολύ πιο κοντά σε μια κουζίνα που μπορείτε να ανακαινίσετε ενώ ακόμη μαγειρεύετε. Οι επιτυχημένες εταιρείες ξαναγράφουν μέρη του stack τους διαρκώς· η εκδοχή ενός προϊόντος που βρίσκει τους πρώτους εκατό πελάτες της σχεδόν ποτέ δεν είναι η εκδοχή που εξυπηρετεί τους πρώτους εκατό χιλιάδες. Ο στόχος του πρώτου σας stack δεν είναι να αντέξει για πάντα. Είναι να σας επιτρέψει να χτίζετε, να αλλάζετε και να παραδίδετε αρκετά γρήγορα ώστε να μάθετε αν αυτό το θέλει καν κανείς. Αυτός είναι ένας εντελώς διαφορετικός — και πολύ χαμηλότερος — πήχης από το «τέλειο για την επόμενη δεκαετία».

Μόλις το αποδεχτείτε αυτό, η πίεση πέφτει στο μισό. Δεν προσπαθείτε πλέον να προβλέψετε το μέλλον. Προσπαθείτε να κάνετε ένα λογικό, αναστρέψιμο στοίχημα που σας πάει σε ένα λειτουργικό προϊόν και πληρώνοντες χρήστες. Και τα λογικά στοιχήματα είναι κάτι που ένας μη τεχνικός ιδρυτής μπορεί απολύτως να αξιολογήσει.

Τι είναι στ' αλήθεια ένα «stack», με απλά λόγια

Πριν αποφασίσετε οτιδήποτε, βοηθάει να απομυθοποιήσετε τη λέξη. Ένα tech stack είναι απλώς η συλλογή των εργαλείων που χρησιμοποιούνται για να χτιστεί και να τρέξει το λογισμικό σας. Μπορείτε να το σκέφτεστε σε τέσσερα επίπεδα, και δεν χρειάζεται να κατανοείτε κανένα τους σε βάθος — απλώς χρειάζεται να ξέρετε ότι υπάρχουν.

• Το frontend — αυτό που οι χρήστες βλέπουν και πατούν στον browser ή στην εφαρμογή τους. Είναι το κομμάτι για το οποίο σας κρίνουν όλοι.
• Το backend — η λογική και οι κανόνες που τρέχουν σε έναν server: ποιος μπορεί να κάνει τι, τι συμβαίνει όταν το κάνει, πώς κινούνται τα χρήματα.
• Η βάση δεδομένων — εκεί όπου πραγματικά ζουν οι πληροφορίες σας: χρήστες, παραγγελίες, συνδρομές, οτιδήποτε θα σας συνέτριβε να χάσετε.
• Η υποδομή — οι servers και οι υπηρεσίες που κρατούν όλα τα παραπάνω online, με backup και προσβάσιμα στις 3 το πρωί.

Όταν κάποιος λέει «θα χρησιμοποιήσουμε ένα μοντέρνο JavaScript stack» ή «Rails πάνω σε Postgres», περιγράφει επιλογές σε αυτά τα τέσσερα επίπεδα. Αυτό είναι όλο. Κάθε SaaS, από ένα project δύο ατόμων μέχρι μια εισηγμένη εταιρεία, είναι κάποια εκδοχή αυτών των τεσσάρων πραγμάτων στοιβαγμένων μαζί. Τα μεγαλόσχημα διαγράμματα αρχιτεκτονικής είναι ακριβώς αυτό, σχεδιασμένα με περισσότερα κουτάκια.

Τα πράγματα που πραγματικά μετράνε (και αυτά που δεν μετράνε)

Εδώ είναι που οι περισσότερες συμβουλές περί stack αστοχούν: βελτιστοποιούν για πράγματα που δεν επηρεάζουν τα πρώτα δύο σας χρόνια και αγνοούν αυτά που τα επηρεάζουν. Ας είμαι ωμός και για τις δύο λίστες.

Τι μετράει στ' αλήθεια

Ποιος μπορεί να το χτίσει και να το συντηρήσει. Ο μεγαλύτερος παράγοντας δεν είναι η τεχνολογία — είναι οι άνθρωποι. Το καλύτερο stack για εσάς είναι αυτό στο οποίο η ομάδα σας (ή ο συνεργάτης που προσλαμβάνετε) μπορεί όντως να δουλέψει, με ευχέρεια, σήμερα. Ένα «τέλειο» stack που το καταλαβαίνει μόνο ένας σπάνιος ειδικός είναι χειρότερη επιλογή από ένα βαρετό που μπορεί να αναλάβει οποιοσδήποτε ικανός developer. Οι προσλήψεις και η συνέχεια νικούν τη θεωρητική κομψότητα κάθε φορά.

Πόσο γρήγορα μπορείτε να αλλάζετε πράγματα. Στην αρχή θα κάνετε διαρκώς λάθος για το προϊόν σας. Η πραγματική δουλειά του stack είναι να κάνει την αλλαγή γνώμης φθηνή. Ώριμα, καλά τεκμηριωμένα εργαλεία με μεγάλες κοινότητες σας αφήνουν να κινείστε γρήγορα, γιατί οι απαντήσεις στα προβλήματά σας υπάρχουν ήδη. Τα εργαλεία αιχμής σας κάνουν εσάς το άτομο που ανακαλύπτει τα bugs.

Αν μπορείτε να προσλάβετε γι' αυτό. Επιλέξτε κάτι δυσεύρετο και δένετε το μέλλον σας σε όποιον το έχτισε. Επιλέξτε κάτι κοινό και βαρετό και θα βρίσκετε πάντα τον επόμενο developer, την επόμενη εταιρεία, το επόμενο άτομο που θα αναλάβει. Το βαρετό είναι πλεονέκτημα όταν η επιχείρησή σας εξαρτάται από αυτό.

Τι μετράει πολύ λιγότερο απ' όσο λένε

Η ακατέργαστη απόδοση και το «scale». Δεν έχετε πρόβλημα κλιμάκωσης. Έχετε πρόβλημα κανείς-δεν-το-χρησιμοποιεί-ακόμη, που είναι το αντίθετο πρόβλημα. Αρχιτεκτονικές σχεδιασμένες για εκατομμύρια χρήστες θα σας καθυστερήσουν όταν έχετε έντεκα. Οι διάσημες εταιρείες που μιμείστε έχτισαν πρώτα την απλή εκδοχή και την ξανάχτισαν αργότερα, χρηματοδοτούμενες από την επιτυχία. Έτσι θα κάνετε κι εσείς.

Ποιο συγκεκριμένο framework «κερδίζει» φέτος. Τα frameworks ανεβαίνουν και πέφτουν σε έναν κύκλο μόδας που σχεδόν δεν έχει καμία σχέση με το αν θα χτίσουν καλά το SaaS τιμολόγησής σας. Οποιαδήποτε από τις mainstream, ευρέως χρησιμοποιούμενες επιλογές θα κάνει τη δουλειά. Η τάση είναι θόρυβος· διαλέξτε από τη βαρετή, δημοφιλή μέση και προχωρήστε.

Γιατί η «βαρετή» τεχνολογία συνήθως κερδίζει

Υπάρχει μια σιωπηλή σοφία ανάμεσα στους έμπειρους κατασκευαστές που οι νεοφερμένοι βρίσκουν απογοητευτική: η καλύτερη τεχνολογία για μια νέα επιχείρηση είναι συνήθως το βαρετό, δοκιμασμένο, ελαφρώς ντεμοντέ είδος. Όχι επειδή τα νέα εργαλεία είναι κακά, αλλά επειδή κάθε επιλογή που κάνετε ξοδεύει έναν περιορισμένο προϋπολογισμό καινοτομίας — τον αριθμό των άγνωστων, αστήρικτων, αναπάντεχων πραγμάτων που η μικρή σας ομάδα μπορεί να διαχειριστεί ταυτόχρονα.

Ξοδέψτε αυτόν τον προϋπολογισμό στο πράγμα που κάνει την επιχείρησή σας ξεχωριστή — στο ίδιο το προϊόν, στη διορατικότητα που έχετε μόνο εσείς. Μην τον ξοδεύετε σε μια βάση δεδομένων που κανείς δεν έχει ακουστά μόνο και μόνο για να νιώθετε μοντέρνοι. Ένα βαρετό, ώριμο stack σημαίνει ότι τα προβλήματα έχουν λυθεί ξανά, η τεκμηρίωση υπάρχει, οι προσλήψεις είναι εύκολες και το εργαλείο δεν θα εξαφανιστεί τον επόμενο χρόνο όταν ο μοναδικός του συντηρητής χάσει το ενδιαφέρον. Το βαρετό σας αφήνει να βάλετε όλον τον ενθουσιασμό σας εκεί που αποδίδει: στον πελάτη.

Εδώ είναι επίσης που η AI αλλάζει λίγο την εικόνα — και όχι με τον τρόπο που υπαινίσσεται ο ντόρος. Οι AI βοηθοί κωδικοποίησης είναι δραματικά καλύτεροι στις βαρετές, δημοφιλείς τεχνολογίες, γιατί εκπαιδεύτηκαν πάνω σε μια δεκαετία δημόσιων απαντήσεων γι' αυτές. Διαλέξτε ένα mainstream stack και η ομάδα σας (και τα εργαλεία σας) παίρνουν ταχύτερη βοήθεια δωρεάν. Διαλέξτε κάτι εξωτικό και είστε μόνοι σας ακριβώς τη στιγμή που το αντέχετε λιγότερο.

Μια μέθοδος απόφασης που μπορείτε πραγματικά να χρησιμοποιήσετε

Αρκετά με τις αρχές. Να ένας συγκεκριμένος τρόπος να καταλήξετε σε απόφαση, είτε επιλέγετε μόνοι σας, είτε δίνετε brief σε έναν freelancer, είτε αξιολογείτε αυτό που προτείνει μια εταιρεία. Τίποτα από αυτά δεν απαιτεί να γράψετε κώδικα — μόνο να κάνετε τα σωστά ερωτήματα και να ζυγίσετε τις απαντήσεις.

1. 1
   Ξεκινήστε από την ομάδα, όχι από την τεχνολογία

   Ρωτήστε: ποιος χτίζει και συντηρεί αυτό για τα επόμενα δύο χρόνια; Ό,τι κι αν ξέρουν ήδη καλά είναι η ισχυρή προεπιλογή σας. Η αλλαγή stack για να κυνηγήσετε μια τάση σπάνια νικάει την ευχέρεια.
2. 2
   Προεπιλέξτε mainstream και δοκιμασμένα

   Διαλέξτε από τη δημοφιλή, καλά τεκμηριωμένη μέση κάθε επιπέδου. Αν δεν μπορείτε να βρείτε γρήγορα tutorials, θέσεις εργασίας και μεγάλες κοινότητες για ένα εργαλείο, αντιμετωπίστε το ως προειδοποίηση, όχι ως χαρακτηριστικό.
3. 3
   Βελτιστοποιήστε για αλλαγή, όχι για κλίμακα

   Προτιμήστε την επιλογή που κάνει την επεξεργασία του προϊόντος σας φθηνή και γρήγορη. Θα κάνετε λάθος για το προϊόν επανειλημμένα — η δουλειά του stack είναι να κάνει το λάθος επιβιώσιμο.
4. 4
   Κρατήστε την αρχιτεκτονική όσο πιο απλή γίνεται

   Μία βάση δεδομένων. Ένα backend. Ένα frontend. Καμία microservice, καμία έξυπνη κατανεμημένη ιστορία, μέχρι ένα πραγματικό, μετρημένο πρόβλημα να σας αναγκάσει. Η απλότητα είναι ο στόχος, όχι ο συμβιβασμός.
5. 5
   Καταγράψτε γιατί το επιλέξατε

   Μία παράγραφος: ποιος το χτίζει, τι διαλέξατε και τι θα έπρεπε να αλλάξει για να το επανεξετάσετε. Αυτή η σημείωση σας γλιτώνει από το να ξανασυζητάτε την απόφαση κάθε φορά που κάποιος διαβάζει μια έντονη άποψη.

Αν δεν ακολουθήσετε τίποτα άλλο, ακολουθήστε τα βήματα ένα και τέσσερα. Χτίστε με τους ανθρώπους που έχετε, πάνω στην απλούστερη αρχιτεκτονική που δουλεύει. Αυτός ο συνδυασμός αποφεύγει αθόρυβα τις δύο μορφές αποτυχίας που βυθίζουν τα περισσότερα πρώτα προϊόντα SaaS: να μην υπάρχει κανείς να το συντηρήσει και ένα σύστημα πολύ πολύπλοκο για το μέγεθός του.

Ερωτήσεις προς όποιον προτείνει ένα stack

Οι περισσότεροι ιδρυτές δεν επιλέγουν το stack μόνοι — ένας developer, μια εταιρεία ή ένας φίλος CTO το προτείνει. Δεν χρειάζεται να επαληθεύσετε μόνοι σας την τεχνολογία. Χρειάζεται να κάνετε μια χούφτα ερωτήσεων και να ακούσετε το πώς απαντούν. Σίγουρες απαντήσεις σε απλή γλώσσα είναι καλό σημάδι. Η αμυντική ορολογία δεν είναι.

• «Γιατί αυτό, και όχι η βαρετή δημοφιλής επιλογή;» — μια καλή απάντηση αφορά τις δικές σας συγκεκριμένες ανάγκες, όχι το τι είναι μόδα.
• «Αν σας χτυπούσε λεωφορείο, πόσο εύκολα θα μπορούσε κάποιος άλλος να το αναλάβει;» — η απάντηση αποκαλύπτει πόσο σπάνια και ριψοκίνδυνη είναι η επιλογή.
• «Ποια είναι η απλούστερη εκδοχή αυτής της αρχιτεκτονικής που εξακολουθεί να δουλεύει;» — προσέξτε αν στρέφονται προς την απλότητα ή προς την πολυπλοκότητα.
• «Πόσο εύκολο θα είναι να προσλάβουμε τον επόμενο developer γι' αυτό;» — οι κοινές δεξιότητες σημαίνουν υγιή αγορά· οι εξωτικές σημαίνουν εξάρτηση.
• «Τι γίνεται όταν χρειαστεί να αλλάξουμε ένα βασικό χαρακτηριστικό σε τρεις μήνες;» — θέλετε να ακούσετε ότι η αλλαγή είναι φθηνή, όχι φόβητρο.

Συνηθισμένες παγίδες που μοιάζουν με καλές ιδέες

Μερικά μοτίβα εμφανίζονται τόσο συχνά που αξίζει να τα ονομάσουμε, γιατί το καθένα μοιάζει υπεύθυνο τη στιγμή εκείνη και σας κοστίζει ακριβά αργότερα.

Να χτίζετε για μια κλίμακα που δεν έχετε. Η παρόρμηση να «το κάνετε σωστά» οδηγεί τους ιδρυτές να σχεδιάζουν για εκατομμύρια χρήστες προτού έχουν δέκα. Κάθε κομμάτι αυτής της προετοιμασίας για το μέλλον είναι πολυπλοκότητα που πληρώνετε τώρα, σε χρόνο και χρήμα, για να λύσετε ένα πρόβλημα που ίσως δεν έρθει ποτέ. Χτίστε για τους επόμενους εκατό χρήστες. Ξανασχεδιάστε όταν η ανάπτυξη το κάνει αναγκαίο — και ας είναι ένα ευχάριστο πρόβλημα.

Να κυνηγάτε το νεότερο πράγμα. Ένα λαμπερό framework που κυκλοφόρησε τον προηγούμενο μήνα δεν έχει ιστορικό, έχει ισχνή τεκμηρίωση και μια μικροσκοπική κοινότητα. Θα ξοδεύετε τις νύχτες σας κάνοντας debugging στο εργαλείο αντί να χτίζετε το προϊόν σας. Αφήστε άλλους να είναι οι early adopters· εσείς έχετε μια επιχείρηση να παραδώσετε.

Να αναθέτετε σε όποιον είναι ο φθηνότερος, σε ό,τι αυτός προτιμά. Η χαμηλότερη προσφορά συχνά έρχεται με ένα δυσεύρετο stack που το ξέρει μόνο εκείνη η μία ομάδα. Τη μέρα που χωρίζετε δρόμους, το προϊόν σας γίνεται ένα νησί που κανείς άλλος δεν μπορεί να φτάσει. Φθηνό στην αρχή, καταστροφικό αργότερα. Επιμείνετε σε mainstream, εύκολα στελεχώσιμη τεχνολογία ακόμη κι όταν αναθέτετε — ειδικά όταν αναθέτετε.

Πότε είναι όντως ώρα να επανεξετάσετε το stack σας

Τίποτα από αυτά δεν σημαίνει «ποτέ μην αλλάζετε». Σημαίνει να αλλάζετε για πραγματικούς λόγους, μετρημένους, όχι φανταστικούς. Θα ξέρετε ότι είναι όντως ώρα να εξελίξετε το stack σας όταν εμφανιστούν συγκεκριμένα σήματα — όχι όταν ένα blog post σας αγχώνει.

Προσέξτε το μοτίβο: οι πραγματικοί λόγοι αφορούν μετρημένο πόνο στην πραγματική σας επιχείρηση. Οι ψεύτικοι λόγοι αφορούν μόδα, σύγκριση και ανησυχία. Όταν εμφανιστεί ένα πραγματικό σήμα, αλλάζετε ένα κομμάτι τη φορά — όχι ολόκληρο το stack σε ένα ηρωικό ξαναγράψιμο που παγώνει τα πάντα για έξι μήνες. Εξέλιξη, όχι επανάσταση.

Συχνές ερωτήσεις