Czy da się rozwijać SH bez marketingu, kluczowe czynniki przy wyborze technologii dla Twojego SH, dlaczego Rust, Kubernetes i Databricks rządzą
Software House Insider to wiedza, która pomaga rozwijać firmy usługowe wytwarzające oprogramowanie.
Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm typu Software House. SHI czyli Software House Insider to biuletyn publikowany co dwa tygodnie z wiedzą nt. różnych silników wzrostu, które są wykorzystywane przez firmy usługowe wytwarzające oprogramowanie.
W dzisiejszym numerze skupimy się na:
Czy da się rozwijać SH bez marketingu ? Przykład Callstack, Ferrous Systems
Pięć kluczowych czynników przy wyborze tech stacku dla Twojego SH na przykładzie React Native
Matryca porównawcza jako narzędzie decyzyjne, który tech stack wybrać dla Twojego SH na przykładzie React Native
Które technologie są dobrym wyborem dla SH jako silnik wzrostu w 2025 na przykładzie Kubernetes, Rust, Databricks, React Native
GPT’s, który pozwala szybko ocenić tech stack dla Twojego SH
Zebrana wiedza w tym biuletynie powinna być używana z rozwagą i na własną odpowiedzialność. Zapożyczam w nim nagminnie frazy z języka angielskiego, wybaczcie, robię to celowo ponieważ w codziennej pracy korzystamy z tych fraz nieustannie.
Czy da się rozwijać SH bez marketingu ?
Zatrudniłeś doświadczoną osobę, która prowadziła marketing w innym SH przez kilka lat. Rozumie Ciebie bardzo dobrze, myślisz, że to co sugeruje jest dobre dla Twojej firmy i idziesz w te sugestie, inicjatywy, lejki. Problem jednak jest taki, że po 2 latach inwestowania w marketing ciągle nie przynosi on rezultatów czyli chociażby nowych spotkań z ludźmi, z którymi faktycznie można będzie kiedyś zrobić jakiś biznes.
Zatem pomyślmy przez chwilę czy da się rozwijać SH bez marketingu?
Marketing jest to promocja firmy, jej usług, jej przewag w taki sposób aby ta wiedza dotarła do takiego klienta, który ma potrzebę i budżet aby z usług takiej firmy skorzystać.
Proste prawda? W SH najczęściej mamy do czynienia z usługami wytwarzania oprogramowania szytego na miarę, audytów, warsztatów przygotowujących do określenia zakresu projektu, czasem są to także projekty R&D lub PoC. Nie zapominajmy o szkoleniach i doradztwie na poziomie architektury i rozwiązań technologicznych. To w dużej mierze wszystko.
Patrząc ogólnie usługi te są dość podobne do siebie. Zatem pojawia się kluczowe pytanie:
jak stosując odpowiedni marketing przekonać klienta do akurat Twojego SH?
O ile usługi firm typu SH są podobne w swym schemacie to problemy i wyzwania klientów już takie nie są. Właściwie można powiedzieć, że to jak dany SH buduje świadomość w oczach swoich klientów zależy od tego jak dobrze tych klientów rozumie i od tego, czy wybrał ich określoną i jednolitą grupę.
TIP 1: zastanów się gdzie osoby z komitetu zakupowego Twojego idealnego klienta (ICP) szukają porady gdy mają problem, na który Ty masz rozwiązanie?
Tutaj kluczowy jest wyraz “porada” bo to jest bardzo istotne w odpowiedzi na pytanie dot. tego czy potrzebny jest w Twoim SH marketing.
Przykład 1. ICP to duża korporacja, a Twoja usługa to body-leasing
Jeśli wiesz, że Twoim ICP jest duża korporacja, a w komitecie zakupowym jest ktoś z Procurementu, Zakupów oraz z Dyrektor pionu Technicznego danej linii biznesowej, to zastanów się gdzie te osoby szukają porady, komu ufają w procesie szukania np. nowego IT Vendora?
Okaże się, że te osoby nie interesuje to jak mocny masz zespół techniczny, nie spotkasz ich też na konferencji dla startupów, nie wejdą też na Twoją stronę bo nie szukają wiedzy w Internecie. Te osoby szukają porady w swojej sieci kontaktów i osób, które obserwują.
W tym przypadku kluczowy jest LinkedIn, networking, odpowiednie niszowe wydarzenia i konferencje. Co ważne, takie osoby zamiast szukać wiedzy w Internecie na danych stronach, często korzystają z raportów, które są zrobione przez znane im firmy.
Czy zatem SH, który swoimi usługami adresuje tego typu ICP i komitet zakupowy powinien mieć marketing?
Niekoniecznie.
Z pewnością taki SH powinien mieć bardzo dobrych Business Konsultantów, którzy maja dobry warsztat w budowaniu swojej sieci zarówno online jak i offline, mają także dobry zmysł do pisania i dzielenia się wiedzą. Gdy posiada się takie osoby w swoim zespole to można śmiało powiedzieć, że marketing sprowadza się do bycia wewnętrzną redakcją, która traktuje swoich Business Konsultantów jak reporterów, którzy dostarczają jej dobry materiał na kolejny numer czy to artykułu na Linkedin, czy to prelekcji na konferencji czy to raportu.
Strona WWW dla takiego SH to bardzo dobrze stworzona wizytówka, która jest potwierdzeniem tego co osoby z komitetu zakupowego już zobaczyły na LinkedIn, wydarzeniu, raporcie. Strona dla takiego SH adresuje obszary lejka marketingowego MOFU i BOFU, nie skupia się na artykułach i wiedzy bo te są gdzie indziej publikowane.
Czy to wszystko można zrobić bez osób od marketingu?
Wg. mnie tego typu SH powinien korzystać z agencji lub freelancerów, którzy będą dbać o profesjonalną formę zebranej wiedzy, będą monitorować jakiego rodzaju wydarzenia warto odwiedzić, będą także organizować własne dla tego SH. Nie sądzę, że posiadanie własnego działu marketingu w tym przypadku ma sens z racji, że większość tej pracy jest na barkach Business Konsultantów. Bo od tych Business Konsultantów takie osoby z komitetu zakupowego zaczynaja rozmowy i tam szukają porady - w swojej sieci.
To co napisałem to bardzo duży trud i koszt dla SH. Konsultanci biznesowi, wydarzenia, raporty. Masa pracy. Czy da się inaczej?
Tutaj wracamy do pytania pierwszego: gdzie osoby z komitetu zakupowego Twojego idealnego klienta (ICP) szukają porady gdy mają problem, na który Ty masz rozwiązanie?
Może się okazać, że w komitecie zakupowym jest lider, który prowadzi ten zespół. W naszym przykładzie, dyrektor techniczny danego pionu jest taką osobą. Co ciekawe, jego historia bardzo często zaczęła się jako PM lub developer. Jest to osoba, która ciągle musi być na bieżąco w nowych technologiach. Jest to ktoś, kto potrzebuje tę wiedzę odsiać bo jest jej za dużo. Potrzebuje ją także wesprzeć opinią ludzi, którzy pracują w podobnej wielkości organizacjach. Nie chcą się przecież zblamować sugerując technologię, która z jakiegoś powodu nie jest używana przez firmy jego pokroju. Ta potrzeba wiedzy, pochodzącej z odpowiedniego otoczenia może okazać się dużo lepszym sposobem dotarcia do komitetu zakupowego.
Wówczas zamiast Business Konsultanta potrzebujesz bardziej Technical Konsultanta lub Solution Konsultanta, który prowadzi spotkania round-table na które zaprasza dyrektorów technicznych i przyciąga ich na porządną dawkę wiedzy.
Można powiedzieć, że to tylko dwa odmienne lejki marketingowe. Wg. Mnie to jednak dużo więcej. Jeśli budujemy zespół, który ma pomóc naszej firmie rosnąć, jeśli mamy określone DNA, które definiuje firmę, to nie możemy tak łatwo skakać między konsultantem biznsesowym a konsultantem technicznym. Po prostu nie będziemy autentyczni. Nasza komunikacja będzie raz mówić o problemach z stawkami pomiędzy Vendorami IT, a w innym miejscu będzie mówić o tym, że za nami kolejne spotkanie nt. AI R&D w telekomach na którym było 8 dyrektorów technicznych z najważniejszych firm w Warszawie.
Widzicie różnicę w przekazie, w jego wadze?
To olbrzymia przepaść dla klienta. Gdy szuka porady to potrzebuje mieć jasność gdzie firma, z którą rozmawia mu pomaga. Czy w dostarczaniu ludzi czy może w przejściu przez zmiany technologiczne w jego firmie w sposób bezpieczny i korzystając z wiedzy jaką zdobył w pracy z innymi telekomami?
Wracając zatem do pytania: czy SH potrzebuje działu marketingu, odpowiedź zależy nie od tego jakie lejki chcemy robić, tylko od tego do jakiego ICP, a dokładniej - do jakiego decision makera mówimy i z kim chcemy prowadzić relację.
W tym drugim przypadku gdy np. Idziemy prosto do dyrektora technicznego, jeszcze mniej potrzebny jest marketing, a jeszcze bardziej potrzebna jest dobry network i budowa wiedzy doradczej w zakresie technicznym. W tym drugim przypadku, marketing będzie sprawdzał się do bycia wsparciem w wydarzeniach i tworzeniu materiałów, ale nie będzie miał żadnej istotnej roli w firmie.
TIP 2: odpalanie lejków musi być spójne z silnikiem wzrostu firmy. Robienie lejków, które nie pasują do silnika wzrostu ma sens jeśli chcemy odkryć nowe linie biznesowe, ale to zupełnie inny proces, którzy trzeba bardzo ostrożnie prowadzić aby nie zniszczyć tego co już się stworzyło.
Bardzo często widziałem SH, które bez głębszego zastanowienia uruchamiały kolejne lejki marketingowe próbując co chwilę mówić do innego klienta i innej osoby z komitetu zakupowego. Zmieniając swoją ofertę wartości, nawet rodzaj usług pod dany lejek. To niestety recepta do upadku SH, jego degradacji do poziomu gdy nowe projekty przychodzą tylko z poleceń lub z sieci znajomych, a usługi jakie świadczy taki SH często są na poziomie body-leasingu lub projektu, który jest obarczony bardzo wysokim ryzykiem bo tworzonym pierwszy raz w danej niszy lub technologii.
Przykład 2 Callstack: ICP to firmy globalne średniego i dużego rozmiaru, a Twoja usługa to konsulting i custom-development w jednej technologii.
Marketing w SH jest bardzo istotny w wielu innych sytuacjach. Przykładowo, gdy SH zidentyfikował swój komitet zakupowy jako dział developerski, w którym liderem jest senior lub tech lead i dany SH ma na tyle duży rozmiar, że może inwestować w konferencje lub nawet tworzyć własne, jest to bardzo dobry krok aby zaznaczyć swoje liderstwo w oczach całego świata w danej technologii.
To w połączeniu z usługami szkoleniowymi, audytowymi, newsletterem technicznym, e-bookami technicznymi, buduje tak mocny odbiór marki i jej usług, że potem te osoby (czyli developerzy i liderzy technologiczni) stają się championami w organizacjach i same namawiają je aby skorzystały z Twoich usług.
W takich sytuacjach marketing jest niezbędny aby cały trud tworzenia tego typu materiałów, wydarzeń, kampanii był sprawnie realizowany i konwertował na MQLe.
Tak działa obecnie Callstack, który mając partnerstwo z Metą organizuje konferencje na które bilety rozchodzą się jak ciepłe bułeczki, a Krzysztof Pawlak, ex CSO z ich firmy dzieli się tym jak korzystając z ebooków , darmowych szkoleń konwertowali w Callstack te leady na klientów.
Przykład 3 Ferrous Systems GmbH, który ma ICP podobne do Callstack czyli firmy globalne średniego i dużego rozmiaru, a usługa to konsulting i custom-development w jednej technologii.
Marketing w małych SH może mieć bardzo duży sens jeśli ten SH ma swój produkt technologiczny skierowany do osób technicznych. Tworzenie odpowiednich kampanii również płatnych może w takich sytuacjach generować dużą liczbę nowych leadów, tworzenie treści pod SEO, która będzie konkurowała z alternatywnymi rozwiązaniami, prowadziła i edukowała o przewagach danego produktu.
Czy da się jednak ominąć te drogą ścieżkę inwestycji w marketing?
Tak. Jeśli produkt jest open-sourcowy, lub w modelu open-core i zdobywa bardzo dużą trakcję na Githubie wówczas marketing sprowadza się do developer advocacy prowadzonego przez zespół developerów i do dobrej dokumentacji z tutorialami i filmami.
Znowu w takich sytuacjach marketing nie jest potrzebny, a bardziej dobry zespół developerski, który potrafi pisać artykuły techniczne, rozmawiać z ludźmi technicznymi i pisać o tym w sieci.
Przykładem tutaj jest firma Ferrous Systems, która z 22 osób na Linkedin ma 10 aktywnie działających na Githubie i w społeczności Rust. Poza mocnymi liderami technicznymi, którzy w społeczności Rust budują świadomość marki firmy Ferrous jako lidera, mają swój produkt, którym przyciągają klientów z określonym problemem:
Ferrocene is the open-source qualified Rust compiler toolchain for safety- and mission-critical systems. Qualified for automotive, industrial and medical development.
Organizują także warsztaty dla decision makerów w działach IT nt “4-hour workshop for tech decision makers who are evaluating pros and cons of Rust programming”, co jest spójne z ich silnikiem wzrostu opartym o specjalizację w tech stacku - Rust oraz w oparciu o produkt technologiczny w tym tech stacku Ferrocane. Mają Events Managera pracującego na part-time, oraz jedną osobę od zarządzania marketingiem, która jest także od eventów i PR.
Kiedy zatem nie warto inwestować w marketing w Twoim SH?
Kiedy bardzo dobrze rozumiesz swojego championa lub decision makera w komitecie zakupowym Twojego klienta i wiesz, że kanał dotarcia do niego nie wymaga działań marketingowych tylko bardziej business developerskich/sprzedażowych/doradczych w obszarze technologii
Kiedy nie znasz swojego klienta i nie wiesz jak do niego dotrzeć - wtedy lepiej jest podjąć próby nawiązania z nim kontaktu i zrozumienia jego potrzeb zanim zainwestujesz cokolwiek w marketing.
Kiedy wiesz, że są lepsze kanały dotarcia do decision makerów lub championów.
Kiedy marketing jest kluczowy w Twoim SH?
Kiedy już wiesz kim jest champion i decision maker i wiesz, że bez wielu punktów styku z Twoją marką nie zbuduje wystarczającego zaufania aby rozważać z Wami współpracę
Kiedy masz dobrze określony produkt skierowany do Twojego championa lub decision makera u Twojego idealnego klienta. Produkt, który można kupić praktycznie bez potrzeby angażowania całego komitetu zakupowego, ale otwiera relację na upsell.
Kiedy masz hipotezę co do określonego championa, decision makera i idealny profil klienta i chcesz w wydajny sposób eksperymentując z doświadczonym zespołem marketingowym sprawdzić czy jest to właściwy wybór.
Podsumowując, to czy dany SH powinien mieć swój marketing czy nie zależy od silnika wzrostu Twojego SH, który bezpośrednio adresuje potrzeby określonego segmentu klientów i osób z komitetu zakupowego. Są sytuacje gdy taki zestaw wymaga od nas zbudowania zespołu marketingowego, ale także jest wiele takich sytuacji gdy praca z osobami w dziale marketingu będzie w dużej mierze męczarnią, a klienci, którzy przychodzą do Was nawet dwa lata po odpaleniu marketingu nie przyszli do Was dzięki tej dużej inwestycji tylko dzięki zupełnie innym działaniom, które przez to, że marketing ciągle zawracał Wam głowę - musieliście robić rzadziej lub wcale.
Tech Stack Growth Engine - czy w 2025 nadal można stabilnie rosnąć skupiają się na tech stacku?
Tech Stack Growth Engine to silnik wzrostu dla Software Housów, które najlepiej odnajdują się w danym języku lub frameworku. Wiele Software Housów z tego wyrosło. J-labs - Java. Netguru - Ruby on Rails, STX Next - Python.
Gdy teraz patrzymy się na te firmy, część z nich już dawno nie pisze o technologii na pierwszej stronie. Możemy za to przeczytać o digital transformation, outsourcingu, AI.
Czy w 2025 roku warto opierać swój SH na silniku Tech Stackowym?
Wg. Mnie jak najbardziej.
Dobrym flagowym przykładem tego jest firma Callstack, która jeszcze do niedawana była tylko w niszy React Native. Obecnie nadal jest mocno tech-stackowa, ale poszerza swoje USP (Unique Selling Proposition) o React. Powstała w 2016 roku, aby w 2023 osiągnąć obroty w okolicach 100 mln zł. To wszystko na React Native. Co ciekawe, w podobnym czasie, a nawet szybciej, na niszę React Native wpadła firma z US, o nazwie Infinite Red, którego CTO, Jamon Holmgren, niedawno opisał swoją podróż na LinkedInie. Ich strategia zmieniała się na przestrzeni lat – początkowo pracowali dla startupów (2015-2019), potem skupili się na firmach średniej wielkości (2019-2022), a dziś celują w korporacje.
Jak podjąć dobrą decyzję co do Tech Stacku dla Twojego SH?
Jamon wyjaśnia w tym wpisie, że 10 lat temu jego firma eksperymentowała z wieloma technologiami: Elixir, Ruby, design, a nawet z losowymi technologiami, ale to React Native zyskał na tyle dużą popularność, że po czterech latach Infinite Red i tak realizowało głównie projekty w tej technologii. Przyszedł więc moment na decyzję: idą all-in w RN.
“We initially started by hedging our bets a bit -- did some Elixir, some design, some Ruby, some random other tech ... but React Native just had so much traction that by about 4 years in, we didn't have a lot of other work in the pipeline anyway. So we decided to just go all-in on React Native. That transition took about another year.
If RN ever fades, we've made the switch before, so we could do it again, and there should be plenty of legacy work to do in the meantime. But it sure doesn't seem like it's stopping anytime soon.”
To właśnie esencja strategii Tech Stack Growth Engine.
Jeśli stawiasz na jedną technologię, cały biznes się wokół niej krystalizuje: oferta staje się bardziej precyzyjna, a specjalizacja umożliwia monetyzację w audytach, szkoleniach, konsultingu oraz budowaniu całych systemów. W przypadku Infinite Red eksperymentowali z różnymi technologiami, ale ich silnik wzrostu się nie zmienił.
Co więcej, Jamon pisze z pewnym dystansem o samym React Native, że jeśli ta technologia kiedyś odejdzie w cień to mogą znowu dokonać zmiany na inny tech stack bo są bardzo dobrzy po prostu w byciu ekspertami w danej technologii i w ich żyłach płynie Tech Stack Growth Engine.
Jeśli zatem czujecie, że w Waszych żyłach płynie właśnie Tech Stack Growth Engine to poniżej czynniki, które trzeba wziąć pod uwagę wybierając tech stack dla swojego SH w 2025 roku.
Pięć kluczowych czynników przy wyborze tech stacku dla Twojego SH na przykładzie React Native
1. Trendy rynkowe
Zmiany w stackach technologicznych są w dużej mierze napędzane przez megatrendy:
Desktop → Mobile (2010s)
Monolith → Cloud (2015+)
E-commerce boom w pandemii (2020)
Rewolucja AI (2023+)
Dlaczego React Native wygrał na rynku? Przed nim były już inne opcje – PhoneGap, Xamarin, Ionic – ale każda miała istotne ograniczenia: niska wydajność lub wysoka bariera wejścia. RN trafił w idealny punkt, pozwalając na budowanie aplikacji natywnych przy użyciu JavaScriptu.
Reguła nr 1: Nowy tech stack musi rozwiązywać nowy, coraz mocniej rosnący problem dotykający wielu rynków jednocześnie.
2. Krajobraz konkurencyjny
W momencie startu React Native miał wielu rywali, ale każdy z nich miał poważne wady:
PhoneGap / Cordova (2009) → WebView = tragiczna wydajność.
Xamarin (2011) → natywny performance, ale uzależniony od C#/.NET.
Ionic (2013) → prostszy niż Cordova, ale nadal WebView.
Flutter (2018) → wydajność graficzna lepsza niż RN, ale spoza ekosystemu natywnego.
React Native długo był bezkonkurencyjny, ale Flutter realnie zamieszał na rynku. Do gry wchodzi też Kotlin Multiplatform, który może przejąć klientów, którzy chcą stricte natywnych aplikacji.
Reguła nr 2: Nowy tech stack musi mieć wyraźne przewagi nad konkurencją, żeby nie stać się tylko chwilowym hype’m.
3. Developer experience
Deweloperzy nie chcą uczyć się technologii, które niczego im nie ułatwiają. Dlaczego React Native się przebił? Bo JavaScript był już wszędzie.
React Native + TypeScript → szybkie wdrożenie, bo większość devów zna JS.
Flutter + Dart → spoko, ale wymaga przyswojenia nowego języka.
Kotlin Multiplatform → ciekawa opcja, ale wciąż niszowa.
Kluczowe jest to, żeby nowy tech stack dawał realną przewagę – czy to w szybkości, jakości kodu, czy łatwości w onboardingu zespołu.
Reguła nr 3: Deweloperzy wybiorą stack, który realnie ułatwia im pracę.
4. Wsparcie społeczności i korporacji
Ekosystem wokół technologii ma gigantyczny wpływ na jej przyszłość. Flutter jest "bardziej kochany" (70% deweloperów go lubi) niż React Native (57%), ale...
RN ma większą bazę użytkowników.
Większy ekosystem open-source (2700+ kontrybutorów vs. 1500 dla Fluttera).
Meta i Google rozwijają swoje stacki, ale RN jest głębiej osadzony w ekosystemie JS.
Duże firmy adoptujące stack to ogromny plus – ich developerzy często później podejmują decyzje w kolejnych firmach, do których przechodzą.
Reguła nr 4: Silny stack potrzebuje zarówno społeczności, jak i dużych korporacji, które będą w niego inwestować.
5. Learning curve i dostępność inżynierów
Czy nowy stack jest łatwy do nauki? I czy trudny do opanowania na eksperckim poziomie? Może to stoi w przeciwieństwie do Developer experience, ale chodzi o to, aby nowy tech stack był trudny do nauki, ale dając przy tym mocną obietnicę wygodniejszej pracy gdy już się go pozna.
Przykłady:
Kubernetes → wczesna adopcja dała przewagę w chmurze.
Scala → wysoka bariera wejścia, ale eksperci byli rozchwytywani.
Rust → trudny, ale bardzo pożądany w systemach wymagających bezpieczeństwa pamięci.
Software House’y mogą wygrać na rynku, wybierając technologię, która nie jest jeszcze popularna, ale ma przyszłość.
Reguła nr 5: Dobry tech stack ma dobry dev-experience ale jest trudny do opanowania – i właśnie dlatego firmy mogą na nim zbudować przewagę.
Matryca porównawcza jako narzędzie decyzyjne, który Tech Stack wybrać dla Twojego SH
Aby podjąć decyzje co do wyboru technologii będacej filarem i silnikiem wzrostu dla Twojego Software House Wasze analizy należy zamienić w matrycę porównawczą, która pozwala na lepsze zwizualizowanie Waszych opcji. Aby Wam ułatwić to zadanie, stworzyłem GPT’sa, tylko dla moich abonamentów. Ocenia on wybraną przez Was technologię pod kątem nastepujących wymiarów:
Learning curve steepness czyli Stromość krzywej uczenia się to wyjątkowy parametr, ponieważ im wyższa krzywa uczenia się, tym lepiej – tworzy ona skuteczną fosę dla Software Housów, umożliwiając budowanie wysoko cenionych kompetencji, które są trudne do znalezienia na rynku pracy.
Market demand
Developers experience
Engineers Scarcity
Niedobór inżynierów – jest to szczególny parametr, ponieważ im mniej dostępnych inżynierów, tym lepiej dla firmy zajmującej się tworzeniem oprogramowania. Gdy agencja zbuduje wewnętrznie takie kompetencje, stanie się niemal jedynym podmiotem na rynku posiadającym tę wiedzę. Stąd wartość 5 oznacza sytuację, gdy dostępnych inżynierów jest bardzo mało lub nie ma ich wcale, natomiast wartość 1 oznacza dużą dostępność doświadczonych inżynierów w danym stosie technologicznym.Corporate backing
Community backing
Sharp USP
czyli tak naprawdę reguła nr 2, która określa, że wybrany przez nas Tech Stack powinien mieć dobrze określone przewagi na tle swojej konkurencji.Top choice for mega-trends
Po dokonaniu oceny wybranych przez Was technologii, należy sprawdzić gdzie one plasują w krzywej adaptacji na rynku i jaki procent. rynku może ta technologia zdobyć.
Przykładowo omawiany React Native jest obecnie w fazie nasycenia swojego Total Servicable Market czyli obszaru rynku, w którym React Native, jego przewagi, zasięg społeczności, zasięg marki - sięga. Wg. Jamona obecnie bardzo wiele topowych aplikacji na app store jest zbudowana w oparciu o React Native. Dodatkowo, wg. moich analiz dostępność developerów React Native (wg. Sales Navigatora) to ok 15 tysięcy ludzi na świecie podczas gdy rynek potrzebuję obecnie około 779 takich osób (wg. Job Search na Linkedin). Czy to oznacza, że React Native to nie jest dobry tech stack dla firm, które chcą zbudować na nim swój Software House w 2025? wg. mnie może być za późno na React Native, ale pojawiają się alternatywy, które mogą przejąć za kilka lat rynek zarówno z React Native jak i z Fluttera.
Które zatem Tech Stack są dobrym wyborem dla SH jako silnik wzrostu w 2025?
Zaskoczenie: Kubernetes 38,5/40 punktów
Kubernetes to technologia, którą próbowałem już dwukrotnie wdrożyć jako silnik wzrostu w dwóch różnych SH. Za pierwszym i drugim razem zabrakło tak naprawdę zrozumienia jakiego rodzaju grę prowadzimy. Budowanie SH na tej kompetencji np. 6 lat temu było w zasadzie "zakładem”. Kubernetes był wówczas traktowany jak coś co czasem ma sens, ale w większości przypadków jest to overkill. Obecnie kurz opadł i zwycięzca jest jeden.
“Charakteryzuje się stromą krzywą uczenia, co ogranicza konkurencję i zwiększa zapotrzebowanie na specjalistów. Rynek usług związanych z Kubernetesem dynamicznie się rozwija, napędzany przez silną adopcję korporacyjną oraz wsparcie gigantów technologicznych. Choć technologia ta jest złożona, narzędzia takie jak Helm oraz zarządzane usługi upraszczają pracę programistów. Inżynierowie ze znajomością Kubernetesa są rzadkością, co sprawia, że ich umiejętności są wyjątkowo cenne. Silna społeczność open-source zapewnia ciągłą ewolucję platformy, a jej integracja z chmurą, DevOps oraz trendami AI gwarantuje długoterminową użyteczność..”
ChatGPT, Pod tym linkiem analiza z naszym GPT’sem.
Aby nie wpaść w zachwyt, dokonajmy sprawdzenia poprzez Sales Navigatora aby zobaczyć jaka jest dostępność developerów z takim tech stack na rynku pracy stosując filtr na polu funkcji i wpisując daną technologię jako tytuł stanowiska. W przypadku Kubernetes otrzymałem ok 1500 osób. Na całym świecie!
Oczywiście ten sposób potwierdzenia dostępnych na rynku kompetencji w danym tech stack’u ma swoje ograniczenia bo dotyczy tylko tych technologii, które są na tyle istotne, że zostaną wpisane przez osoby jako ich nazwa stanowiska.
Jakie natomiast jest zapotrzebowanie na te kompetencje Kubernetes?
Korzystając z klasycznego Linkedin (tutaj przykładowy search) ustawiłem w wyszukiwaniu Kubernetes i otrzymałem 1906 wyników.
Ten sposób potwierdzenia zapotrzebowania na rynku na dane kompetencje ma swoje wady ponieważ zakłada, wystąpienie tego słowa kluczowego w ogłoszeniu. Ja robię szybki skan wyników i sprawdzam, czy w tytule stanowiska jest ta technologia i czy ogłoszenia są z różnych firm.
W przypadku Kubernetes’a oznacza to, że jest to solidny wybór dla Software Housów w 2025 aby na tym budować swoją przewagę konkurencyjną i silnik wzrostu ponieważ wynik matrycy porównawczej to 38,5/40 oraz zapotrzebowanie na te kompetencje przerasta liczbę dostępnych ludzi na rynku.
“Umarł” C++ niech żyje Rust 34/40 punktów
Oczywiście C++ nigdzie się nie wybiera i będzie z nami jeszcze bardzo długo, natomiast jego ograniczenia przez wiele lat dusiły rozwój narzędzi systemowych. Rust to technologia, o której słyszałem od mojego znajomego dobrych kilka lat temu. Wtedy wydawała się czymś małym. Obecnie Rust zjada olbrzymi kawałek bardzo istotnego tortu, który prez dziesiątki lat był okupowany przez C++ i robi to w kluczowym obszarze narzędzi infrastruktury. Developerzy już nie muszą schodzić do C++ aby pisać wydajne aplikacje systemowe.
“Rust szczególnie sprawdza się w wydajnych, bezpiecznych i niskopoziomowych aplikacjach systemowych, co czyni go idealnym rozwiązaniem w dziedzinach takich jak bezpieczeństwo, blockchain oraz infrastruktura chmurowa. Silne wsparcie społeczności oraz rosnące zainteresowanie ze strony firm dodatkowo wzmacniają potencjał Rust-a.”
autor: ChatGPT. Pod tym linkiem analiza z naszym GPT’sem.
Sprawdźmy zatem jaka jest obecnie dostępność tych kompetencji na rynku oraz jakie jest na nie zapotrzebowanie korzystając z metody przedstawionej wcześniej dla Kubernetesa.
Korzystając z Sales Navigatora aby zobaczyć jaka jest dostępność developerów Rust otrzymałem ok 1000 osób. Korzystając z LinkedIn Job search otrzymałem 655 ofert pracy. To bardzo dobry wynik, może nie tak imponujący jak w przypadku Kubernetes, ale widać wyraźnie olbrzymi niedobór tych kompetencji na rynku.
Databricks, Apache Spark, Flink, Snowflake, Big Query, czyli gra o tron
Databricks to firma, która nie jest tożsama z Apache Spark pomimo, że mają ze sobą bardzo wiele wspólnego, dlatego te technologie są odrębnie ocenianie. Są to z pewnością istotne technologie z racji mega-trendu dotyczącego AI i wszystkich z nim związanych nisz dotyczących danych, cloud.
Analiza porównawcza tych technologii z wykorzystaniem naszego GPT’sa jest tutaj.
W skrócie:
Apache Flink 34,5/40 najlepszy do AI w czasie rzeczywistym i streamingu
Apache Spark 34/40 najlepsza open-source platforma big data
Google BigQuery 33,5/40 najlepszy do analityki SQL wspieranej przez AI
Databricks 29/40 dobry, ale nie ma jasnego wyróżnika
Snowflake 27,5/40 najlepszy do tradycyjnego przechowywania danych
Zapotrzebowanie vs dostępność talentu:
Apache Spark 475 ofert pracy vs 1000 inżynierów
Apache Flink 75 ofert pracy vs ok 100 inżynierów z tą technologią w tytule stanowiska
BigQuery 42 oferty pracy vs ok 58 inżynierów z tą technologią w tytule stanowiska
Databricks 890 vs ok 352 inżynierów z tą technologią w tytule stanowiska
Snowflake 691 vs ok 1500 inżynierów
Pomimo, że Snowflake i Databricks mają niższe wyniki w naszej matrycy to patrząc na rynek widać wyraźnie, że te dwie technologie mają największe zapotrzebowanie.
Czy Databricks to dobry tech stack dla SH w 2025?
Wg. mnie na start dla małego SH, który chce zbudować swoje kompetencje w jednym wyraźnym tech stacku, specjalizacja w Databricks to dobra ścieżka. Natomiast dobrze wówczas rozważyć partnerstwo z komplementarnym SH w Kuberentes i/lub w Rust, który może mieć projekty gdzie Wasze siły połączą się w idealne rozwiązanie dla Waszych klientów.
Patrząc teraz na te wszystkie technologie określmy ich miejsce w adopcji rynku i w tym jak bardzo ich rynek obsługiwany (Servicable Market) jest częścią ich całego dostępnego rynku (Total Available Market).
Jak widzicie Kubernetes ma najlepszy score i jego obecne miejsce w adopcji na rynku oraz cześć jego całego dostępnego rynku świadczą o tym, że jesteśmy w fazie bardzo mocnej stabilizacji. Można śmiało powiedzieć, że jest to naprawdę dobry pewny zakład dla SH na 2025. Do listy dodaliśmy także Flutter oraz React Native, których adopcja na rynku jest wcześniejsza, natomiast szybkie sprawdzenie zapotrzebowania vs dostępności na rynku wskazują, że React Native ma bardzo dużą grupę dostępnych developerów (15 000+), Flutter jeszcze większą (27000+), a liczba ofert pracy to 800 dla React Native i 722 dla Fluttera. Oznacza to, że o ile są to technologie, które mają jeszcze przed sobą dużą część rynku to sam silnik Tech Stack’owy tutaj nie wystarczy. Po prostu jest zbyt dużo dostępnych developerów na rynku. Inaczej sprawa ma się wobec Rust ora Databricks. Tutaj mamy rynek w środkowej lub nawet wczesnej fazie, bardzo dużo ofert pracy, a liczba developerów - niewielką. To świadczy o tym, że naprawdę ciężko jest zbudować tego typu kompetencje samodzielnie, co oznacza, że jeśli Twój Software House skupi się na tych technologiach to ma bardzo duże szanse, że tylko z racji tego wyboru będzie miał dobry potencjał na wzrost.
Po słowie.
Poniżej tematy, które chciałbym poruszyć w najbliższych numerach:
Jak szukać nowych silników wzrostu bez konieczności wywracania Twojego SH
Proces rekrutacji BDMa (kontynuacja tematu z SH#2 gdzie opisałem kompetencje)
Eksperymentacja przy użyciu “Testing Business Ideas” Strategyzera jako narzędzie do szybkiej iteracji konceptów na silniki wzrostu dla Software Housów
Czego nie robić i co robić gdy Twój SH walczy o przetrwanie?
Silnik Wzrostu oparty o Partnerstwa Technologiczne - kiedy jest to sensowny wybór, a kiedy strata czasu
Silnik Wzrostu oparty o Specjalizację Technologiczno-branżową na przykładzie Medtech
Które technologie są potencjalnie nowym pretendentem do tronu, a jeszcze nie ma na nie nawet ofert pracy?
Silnik wzrostu oparty o produkt open-source w podejściu open-core
Kiedy Twój nowo odkryty silnik wzrostu może zacząć transformować Twój SH
Jeśli któryś z tych tematów jest dla Was ważny - napiszcie komentarz do tego posta lub zaproponujcie własny temat.