When a product experiences such rapid adoption, it is often too late for a agency to place a strategic bet. The product has already established its adoption path; otherwise, it wouldn’t be in the tornado phase.

A genuine Tornado Bet focuses on the unknown future. We are betting and hoping that a 5% chance converts into 100% success. Our goal is to become agency that leads the adoption of a new product within the main market.

# 1. Source: Tornado bet source has to be mounted in the old paradigm with $100B+ money flowing through it

You don’t become a “gorilla” (market leader) by entering an existing tornado and claiming expertise. It’s too late for that. You become a gorilla when you bet on a future tornado that eventually occurs.

“Eventually occurs” is the defining phrase. You don’t know if it will happen, but you can monitor the market for signals. AI in software development is a prime example.

Traditional software development is a well-understood process and a very wealthy one with over $1,700B+ yearly spending (IT Services Spending: ~$1.73 Trillion by 2025 Gartner report).

Teams collect requirements, design specifications, and pass them to engineers who write the code. Humans review the result, provide feedback, and create additional requirements. This is the old paradigm fueled by billions of dollars every year.

The new paradigm with AI is still taking shape. We see products that enable non-technical users to build functional applications and AI assistants (Lovable) that serve as primary interfaces (Openclaw).

The market is clearly shifting toward new methods for building software and is 100% certain that the old paradigm can be optimized by an order of magnitude.

This is demonstrated by Anthropic, which reports that 90% of its code is written by AI, and by the countless engineers who daily share their astonishment at AI’s role in their workflows. However, they also admit that AI-assisted development still struggles with large codebases.

Does the tornado hit the brakes?

No. The AI tornado is a disruptive force affecting labor markets, SaaS valuations, and business models. Investment in AI infrastructure is expected to exceed $500B by 2026. Major technology firms are already transforming their development cycles. Y-Combinator is recruiting AI-native software agencies. There is a high probability of a total shift in the software development paradigm. The only question is:

Where will you position your agency to catch the AI tornado?

# 2. Channel: Base your Tornado Bet on concrete signals of new paradigm awareness, coming from the main market OPEX spent

A Tornado Bet must be rooted in signals that indicate where the market is heading.

In the case of AI in software development, we see an investment in AI infrastructure at scale the world has never seen. Microsoft, Google, Amazon, X, Meta are aiming to spend over $500B alone in 2026 on AI infrastructure. They are also signaling that their own growth will be based on AI-assisted workforce rather than increasing headcount.

This money invested in AI is not directly flowing to software development process but it is a signal sent by the gorillas (market leaders) that the purpose of these investments is to empower the workforce with AI to disrupt their current way of working.

Such signals form a channel towards new paradigm which core is in AI-disrupted work-processes.

In search of a more funneled area of the channel we need to find a signal where current, mature market is already spending their OPEX on the new paradigm channel.

To me, the most revealing signal is spending on tokens.

Why is token expenditure by software teams the primary signal?

This budget is being pulled from “main-street” operational expenditures, the area where the market is currently experiencing FOMO. Spending on tokens for software development is increasing exponentially, while the AI technology itself becomes significantly more capable. The AI tornado is tearing OPEX apart to predicted $15B spent in 2026 only on tokens!

Tokens are spent by developers who are disrupting their software development process with AI. They are applying to refactoring, prototyping, but also to new modules and whole systems. Here however we see a lot of friction, because current AI solutions are not capable of delivering complete, scalable, well-architected, DRY, SOLID code. Here, our developers, who were our innovators become our skeptics.

# 3. Wedge: Resolve a survival threat to unlock the tornado

The product at the heart of your Tornado Bet must resolve a survival threat that is preventing the current shift from reaching full power.

What is currently the primary obstacle for AI-assisted software development? what is the main job of the software developers which AI can’t help yet?

Production readiness.

Engineers are not yet ready to rely on AI-generated code for production systems. The most effective way to gain their trust is to provide the working code as open source.

This is potential wedge of your Tornado Bet. An open source technology focused on enabling software development teams in building production-grade systems 100% by AI.

# 4. Transformator: Tornado Bet has to be rooted in new paradigm that gains main street acceptance and has high chance to transform old way of working into new one

A Tornado Bet must assume a new paradigm that will eventually replace the old one. You must choose a model that the main market will eventually accept. Our innovative developers who have agentic IDE in their hands with unlimited tokens are thinking hard, every day, how to use this tool wisely…

Think in reverse: what kind of paradigm will main-street companies accept? These organizations are often wary of risk, security, performance, and legal complications.

Do you believe they will allow AI agents to rewrite their entire software stack without human oversight with Openclaw?

That scenario might eventually occur, but it will not replace the current paradigm immediately. It is too risky; technical leaders and skeptics will argue that autonomous code is impossible to review.

A more realistic path is that the community of senior technical leaders will trust products that align with their mental models and respect programming principles and architectural patterns. This is the promise of AI-assisted frameworks.

This is the core hypothesis behind Open Mercato:

that main-street technical leaders will trust such AI-assisted framework rather than an agent that codes without clear constraints. In the new paradigm, engineers will orchestrate software agents to build software using AI-assisted frameworks.

Will this hypothesis hold? Adoption is the deciding factor. If Open Mercato crosses the chasm and becomes a valuable alternative to custom or off-the-shelf software for a specific niche, pragmatists in the main market will choose it over purely agentic approaches.

Main-street organizations already rely on open source. By providing an AI-assisted framework certified by the open-source community, we enable technical leaders to “eat the cookie and have the cookie.”

They maintain control over the architecture while leveraging AI to its full extent.

What can your software agency do with this knowledge today?

First, you should focus on the use case of AI-assisted development for production systems. This is the “holy grail” that will unlock the full power of the AI tornado and position your company to ride the new waves. Every IP you create that helps software developers in their transformation of their current work approach to AI-assisted and ready for production - is a good bet.

What does that look like in practice?

1. You don’t necessarily have to contribute to Open Mercato. You can follow the example of Callstack, which released React Native skills files to the community to support developers in their transition to AI-assisted workflows. Now, any React Native developer can enhance their skills using Callstack’s expertise by integrating those files.

2. You don’t have to sell PoCs in Lovable; you should focus on production-grade systems. If your primary background is in e-commerce, determine how technical leaders in your segment are adopting AI. Review their blogs, posts, and articles. This is a powerful way to build relationships with major firms that are learning this new paradigm alongside you and may have less time to focus on doing it correctly.

3. Avoid shifting into a product company; that is often a mistake for a software agency. Your core strength is being a service-oriented company. You simply need to rethink how you deliver those services. If you continue to sell hours, you miss the AI advantage which can command premium rates you wouldn’t otherwise be able to charge. This is the “Service Paradox” that Tomek Karwatka recently explored. He argues that the traditional agency model is often a trap, but it can be transformed into a calm, durable, and high-value business if you stop competing on hours and start delivering as a strategic partner. You can read his full take on The Service Paradox here.

Many agencies will try to pivot their strategy and fail because they will treat this as a technical upgrade, not a strategic shift. They will adopt Cursor, but stay in the “deliver hours, not results” mindset. They will fail to become a true AI-native Agency.

Don’t pivot blindly and review your strategy to position yourself in a right place. Feel free to contact me for a free consulting call.

The Great Rewrite is a term coined by a few people in the past few years to describe the fundamental shift in the way we approach software development. It is a response to the rapid pace of change in the field, driven by the increasing complexity of software systems and the need to deliver value to customers at an ever-increasing rate.

For software development companies, the Great Rewrite is a shift from building software to orchestrating AI in building software. This is a huge paradigm breakthrough that signals the approach of what Geoffrey Moore calls a Tornado. We are not there yet, but the winds are picking up.

AI is eating almost every niche of our lives, from the way we learn, write, and share knowledge to more complex tasks like medical diagnosis, drug discovery, self-driving cars, etc.

This is all very obvious to everyone. However, what is not so obvious is where the niche applications of AI are going mainstream. This is where the old paradigm experiences friction with the new paradigm so intensively that they find a perfect spot to hit the ground and start a devastating tornado.

This is where the Tornado begins to form. When the technology of industry gorillas (market leaders) starts shifting permanently to AI, the rest of the market must decide: seek shelter or build a windmill. For the owners of software development companies, this choice is existential. It is a choice between being a dying Software House or a thriving Agentic Studio.

ROI is the key metric for AI adoption.

Firstly, let’s look at where AI failed to deliver its value. When we read the MIT report from mid-2025, we can see that 95% of corporate Generative AI (GenAI) pilot projects fail to deliver measurable financial returns, often stalling after six months with no impact on profit and loss. It was caused not by AI’s weakness but by poor integration and a lack of context retention in tools. The study revealed a “GenAI Divide” term, where companies struggle to move beyond basic pilots, despite a thriving “shadow economy” of employees using personal AI tools effectively.

Some analysts have challenged aspects of the study’s methodology, arguing that its definition of “failure” is narrow (ROI measured in short timeframes) and doesn’t capture efficiency improvements or other non-P&L (profit and loss) benefits.

There is, however, one very revenue-led use case where AI is delivering direct, tangible, and monthly visible value. It’s in software development.

Billion-dollar use case is ready: ROI from transforming software development life cycle to agentic engineering

In 2024 and 2025, we saw many attempts to apply AI to software development, and we see a huge battle between sceptics and visionaries. Sceptics are trying to apply AI to software development in a way that is not disruptive to the existing workflow, often being very critical about its ability to write complete, secure, scalable code.

Visionaries are trying to apply AI to software development in a way that is disruptive to the existing workflow.

The senior technical leadership teams are making a choice. Which side they choose will determine the future of software development companies. The choice is between scepticism and vision. The business stakeholders are in the same boat but feel the tension is high.

The sceptics are against the great rewrite.

The companies with sceptical senior leadership teams are often arguing against using AI to write code, claiming it’s not ready for production. They use hard-to-resist and very revenue-based fears like sudden crashes of code spoiled by AI or security threats. They claim the delivered code is hard to read and bloated with AI slop in its purest form. They have plenty of evidence in the market to prove their point.

Business stakeholders invested millions of dollars in their software and in their teams. They are not ready to let go their entire technical team although they feel more and more, that the above story is not true. They look for other technical experts to help them make a decision in a safe way. They will try to eat the cookie and have it too.

The visionaries are for great rewrite.

The companies with visionary senior leadership teams are in a totally different position. They are jumping every day from one innovation to another, trying to grasp the best way to apply AI to software development.

A great example is the exchange of thoughts between three product and technical leaders, one of them is Peter Yang from Roblox, who wrote an extensive article about the future of AI in software and product development.

He points out how Product Management is going to be transformed by AI, in short he sees that product managers will work directly with AI agents like software engineers do, on the same artifacts.

He also posted on Linkedin a Tweet from Andrey Karapathy, ex AI Director at Tesla:

A crucial part of his post:

Andrey confirms that agenting engineering is the future, but there is no manual which points us directly to third group of technical leaders.

The pragmatists are in the chasm.

On purpose, I left a huge gap between sceptics and visionaries. In Moore’s terms, the early market is defined by pragmatists who are selecting the bullet-proof whole product solution. They are not ready to let go of their entire technical team just because they are hesitant about AI. They are willing to try to find a way to apply AI to software development to an extent where they can justify the investment.

They know AI is here to stay and deliver PoC and even ready systems in days, but they can’t see the new path. They look to their network to find confirmation of the first signals of the whole product solution (the manual) , and they can’t find any. Why?

The whole product for agentic software development is under construction.

Every day we see technical leaders writing about agentic software development. They pitch their new cool approach, new framework, new tool. They are on a single-man mission (transformation project) to find a way to apply AI to their development teams and to create their own agentic software development process.

Here is a recent example from Peter Steinberger, who wrote on the 28th of December 2025, where he outlines from the top to the bottom how he works on multiple projects at the same time with AI.

Also, the technology gorillas (market leaders) in agentic engineering like Google, Anthropic, and OpenAI are working on the AI-native software development process by educating leaders on the best way to approach it.

Antropic has created a repository where they tackle this challenge from the prompt engineering side, which is a step forward in the AI-native software development process, especially for engineers.

Google offers the Agent Development Kit (ADK), a modular framework for building scalable agent architectures on Vertex AI.

OpenAI provides the OpenAI Agents SDK, an experimental framework exploring ergonomic, lightweight multi-agent orchestration.

It’s clear that the leaders are trying to duct-tape a whole product for agentic software development, but there is no standard that is accepted by the market. Yet...

100xProductivity boost: The key metric used by technical leaders to justify the investment in agentic software development.

The pragmatist has to find a metric that can justify his bet on agentic engineering. The most important metric that technical leaders use to justify the investment in agentic software development is productivity boost. Fabian Wesner has recently visualized the productivity boost in agentic software development in a very clear and concise way.

The challenge is that the productivity boost is not linear and persistent. Depending on the scaffolding you hold your agents to, the productivity boost is different. If you simply “vibe-code” in a vanilla way with tools like Cursor, Windsurf, Antigravity or Codex, your initial speed will eventually hit a wall of complexity and technical debt. You are just typing faster, but you aren’t engineering better.

Agentic Engineering is about Software Development Life Cycle, not just coding

The real game-changer for agentic engineering is when you start to think about the Software Development Life Cycle (SDLC) as a whole and how agentic engineering rewrites it.

We are in the new era of Agentic SDLC where agentic IDEs and agents become main collaborators with all members directly involved in SDLC. This means that the feedback loop between all members is much shorter and agents are assuring proper requirements gathering, architecture design, code review, and testing.

Agentic SDLC is currently the single most important use case that every technical leader is thinking about. The evidence is clear. Andrej Karpathy in the tweet I’ve already mentioned above highlighted the emergence of a new programmable abstraction layer. Complex ecosystem of agents, contexts, and tools that demands a new mental model.

Similarly, Peter Steinberger describes his solo agentic engineering SDLC as ”shipping at inference speed ” where the bottleneck shifts from typing code to “hard thinking” and AI feedback loops, fundamentally compressing the traditional development cycle.

The interesting fact is that most of the SDLC parts will be soon standardised by the market leaders. AWS has already introduced the AI-Driven Development Lifecycle (AI-DLC), replacing traditional sprints with rapid “bolts” and introducing concepts like “Mob Elaboration” where teams and AI co-design specifications. Frameworks like Microsoft’s AutoGen and methodologies from consulting firms are creating the new standard: a continuous, AI-orchestrated loop rather than a linear human relay in the old-fasioned SDLC.

However, there is no standard for agentic SDLC that is accepted by the market. Yet ...

BMAD - a candidate for the “manual” for the agentic engineering

This is where Brian BMad enters the stage with his BMAd Method (Build More, Architect Dreams). He realized that to sustain the “Tornado” velocity, we need more than just a smart autocomplet. We need a structured, agentic architecture. His method treats AI not as a tool, but as a workforce, orchestrating specialized agents (Product Managers, Architects, QA Engineers) through rigorous workflows.

This is the “Whole Product” approach for the AI era: a framework that transforms raw intelligence into reliable, scalable engineering. It bridges the gap for the pragmatists.

Check out the project that is defining this new standard, it got 27k starts on Github starting on April 2025.

The BMAD method from the Software Development Life Cycle perspective is a Cognitive Process OS. It redefines the SDLC not as a linear handoff, but as a continuous loop of 4 distinct phases (Analysis, Planning, Solutioning, Implementation) where specialized agents (from Test Architects to Product Managers) must mutually agree on specifications and architectural decisions before any code is committed. It forces the “human-in-the-loop” alignment at the “Why” and “What” stages of SDLC, ensuring that the “How” (execution) is protected from context drift.

It seems like a very interesting bet on how to approach our manual for SDLC, however…

There are five problems with BMAD Method.

1. It lacks successful big implementations by tech gorillas (market leaders). This is a crucial sign for pragmatists who are in the chasm. They use this signal to convince their engineering teams and their stakeholders that “other, well-known companies are already using it”.

2. It is not meant to be a natural extension to agentic IDEs. The start of our journey should be from the agentic IDEs, and then we can build on top of it. It should address non-technical stakeholders too, to actually become a whole product for the AI era and to be a layer on top of agentic IDEs.

3. It relies on an opinionated approach to architecture assuming it knows the right architecture for the right system. This is also an issue with vanilla agentic IDEs.

4. Underneath, it still generates whole code for the project using pre-AI written frameworks and libraries.

5. Legacy code - agentic engineering is much better in green-field areas and in integrations with AI-generated code on mutually understood artifacts.

Let me explain the last three points because they are the place where our agentic engineering tornado has to be untangled to get a full wind power.

The agentic software architecture is not standardised, and it will never be standardised.

The software is written to fulfill the business case of the company. Never other way around. This is why fintech companies with millions of transactions per second use f.e. Akka with their Actor Model to run concurrent scalable applications

You don’t need this architecture to build an ERP system. This will be an overkill. With agentic engineering, AI might quickly jump from too simple architecture to too complex architecture. The architecture of the software inside companies is not so well disclosed on the Internet, the knowledge is fractional and again - very opinionated. This means the LLMs have no high quality of data to learn from on how to design the architecture of the software.

The massive rewrite caused by agentic engineering is not a solution to daily software development

Agentic engineering lets agents go back and forth through your code and mess with it. This is not a solution to daily software development with multiple teams. That’s why we see tons of solo developers who are using agentic engineering to build their products, but not so many of them working at such high speed as a team.

The teams need to feel control over their codebase even when AI is at the steering wheel. Otherwise, when the code goes to production and there is an urgent issue to fix, the pragmatist technical leader who convinced the entire board to go to the agentic engineering era at full speed will be fired the next day after such a big incident occurs and the team fails to understand the codebase.

The legacy code written by humans can’t be easily migrated to AI-native code.

The code written by humans is like painting, with specific scratches performed by multiple different brushes held by different painters over a long period of time using different paints. It is hard to migrate to AI-native code because it is not a standardized codebase. When AI enters such a codebase, it tries to smoothen it like AI does to our images. The smoothing of images is sometimes acceptable and desired, but when the code that is run on production is smoothened by AI, it can be a disaster.

The agentic supportive frameworks - a bridge in the agentic engineering chasm that leads directly to a massive tornado of productivity.

The above issues mean that the pragmatic technical leader has to get a whole product that assures him that the architecture written by AI is aligned with his business, the codebase is maintainable and that the agentic workflow is able to plugin to existing codebase with success.

Here is where Agentic Supportive Frameworks come into play. What is it?

Agentic Supportive Frameworks (ASFs) are standardized, highly opinionated architectural foundations designed specifically to be respected and understood by AI agents. Unlike traditional frameworks built solely for human maintainability, ASFs provide a strict “contract” often in the form of explicit documentation (like AGENTS.md) and a modular structure that allows agents to generate code with high confidence, predictable structure, and zero hallucinations.

I used the earlier drawing made by Fabian Wesner and enriched his productivity chart with a new axis - complexity and draw a green blocks that visualize how agentic engineering concepts, from very basic to the most advanced with ASF are changing the productivity persistence while code base gets bigger. With ASF we build on the shoulders of agentic supportive modules, specs, guardrails, tools and MCP’s which promises the highest productivity boost possible with the current agentic engineering technology.

A prime example of this new category is Open Mercato. It is one of the first open-source frameworks to treat AI agents as first-class developers. It provides them with a clear map of the territory: a headless, modular architecture where every business function is encapsulated, auto-discovered, and strictly typed.

By adopting an ASF, the pragmatist leader solves the “blank canvas” problem. They don’t have to trust the agent to invent the architecture. They only trust the agent to FILL it. This allows the “Tornado” of agentic engineering to finally touch the ground, turning potential chaos into a scalable, maintainable business asset. And most importantly - a sellable Asset.

Here is how ASF and on Open Mercato as example, specifically addresses the five fears of the pragmatist:

1. Tech Gorilla Validation for Pragmatists

Open Mercato is smart about its signaling. It doesn’t ask you to bet your company on a new, unproven language. Under the hood, it runs on Next.js, MikroORM, and TypeScript - standard technologies validated by millions of developers and enterprises. It uses Awilix to provide a standard dependency injection pattern similar to what enterprise developers expect from languages like Java or C#. The innovation isn’t just the stack, it’s the Context Engineering. By standardizing the stack, Open Mercato gives your AI agents a predictable map of the territory. This provides the safety pragmatists need:

2. A Context Layer for Agentic IDEs

It works with, not against, your tools. Open Mercato effectively acts as a server-side context engine for client-side tools like **Cursor, Windsurf etc.. By providing a dedicated AGENTS.md and strict type definitions, it gives your Agentic IDE the “map” it needs to function effectively. It doesn’t try to be an IDE itself. It provides the environment for your IDE to operate in, reducing the cognitive load on the agent.

3. Standardized, Yet Flexible Architecture

Critics argue that opinionated architecture is risky. Open Mercato flips this:

Moreover, Open Mercato focuses on a specific category: CRM and ERP systems. In Geoffrey Moore’s terms, this simplifies the “whole product” search. The technical leader doesn’t need a generic “do-it-all” framework. They need the right tool for their specific business domain. By choosing an ASF designed for their category (e.g., Commerce/Operations), they inherit an architecture that already “speaks the language” of their business challenges, drastically reducing the complexity the agent has to manage.

This leads to a crucial risk reduction benefit: Safety Sandboxing. Because the ASF guarantees strict contracts between modules, you can “sandbox” your Agentic IDE to work only within a specific module. The AI assumes the surrounding modules work as advertised (the contract), preventing it from wandering into the “forbidden zones” of core infrastructure or unrelated business domains during a refactor. It keeps the “tornado” contained.

4. Reliability of Established Libraries

This is a feature, not a bug. Generative AI is great at logic, but terrible at reinventing wheels. Open Mercato leverages proven libraries (MikroORM for data, Awilix for DI) because they are deterministic. We want our AI to write the business logic, not the plumbing. Using established libraries ensures that the core reliability of the application remains high.

5. Migration Path for Legacy Code

Because Open Mercato is modular by design, it enables a safe “Strangler Fig” migration strategy. You don’t have to rewrite your monolith overnight. The framework allows you to easily “flag” specific modules as legacy-connected, telling the AI to respect existing database structures rather than trying to reinvent them. The strict contracts allow AI/Agentic teams to build new features rapidly in the new system while maintaining necessary, safe links to the old data.

Why ASF are the key to successful agentic software development?

Because they are a whole product for agentic software development for a given category of applications. If you need to build your own ERP/CRM with AI - you will use Open Mercato. If you need to build your own e-commerce platform with agentic engineering approach - you will choose... and here is good information for any software development company out there.

The ASF category is just starting. Open Mercato is a serious attempt to define how we should tackle the agentic engineering chasm to open the tornado for agentic software development in ERP and CRM. It’s not just a framework, it’s the foundation of your new IP.

The end of the “SaaS vs Custom” era

Tomek Karwatka, a person who in polish Software Development Agencies world has achieved a lot by building several successful agencies is betting on ASF and Open Mercato. Why?

Because the productivity boost isn’t the only KPI and use case where agentic engineering is hitting the tornado phase. He sees the early signals for tornado in the great rewrite for the SaaS vendor-locked enterpises. Instead of paying millions of dollars yearly on SaaS and other licenses they can use Open Mercato and write their own CRM/ERP in weeks.

He wrote about it in his latest tweet:

Agentic engineering kills the justification for rigid, boxed SaaS and the pain of paying for expensive licenses while maintaining legacy code. Clients today demand the speed of SaaS but the perfect fit of Custom Development. They don’t want to pay for time spent of developers anymore they want results, instantly.

ASF and Open Mercato as example is the engine for this new reality. It allows you to stop selling code lines and start selling pure business value by software development companies.

Why is this a game-changer for Software Development Companies?

1. Build Product, Not Infrastructure: Logic, multi-tenancy, billing, roles, audit, security, it’s all ready. Your team focuses only on what generates unique value.

2. Open-Source “SaaS” with safe framework: Your changes sit on top of the core, protecting you from “Upgrade Hell”. You get the stability of a maintained platform with the flexibility of custom code. No forks.

3. AI-Native Foundations: Data, workflows, and permissions are designed for AI agents from day one.

4. Enterprise-Grade Security: Tenant-scoped encryption out of the box. You can rewrite their exisitng software without fear of compliance issues.

Are You Ready for the Great Rewrite?

You understand the shift. You see the Tornado forming.

Many Software Development Companies will try to pivot and fail because they will treat this as a technical upgrade, not a strategic overhaul. They will adopt Cursor, but stay in the “deliver hours, not results” mindset. They will fail to become a true Agentic Studio.

Don’t pivot blindly.

I am opening 3 spots this month for a IP Radar.

We won’t just “audit” strategy. We will dig through your “Digital Waste” to find the one Asset that can become your IP, resistent and growing on the agentic engineering tornado.

You will get a brutal, honest verdict: Go or No-Go on your IP bets including validation steps to reduce the risk of false positives to zero.

If you are ready to stop selling hours and start building IP for your clients and yourself, let’s talk.

Cel tego sprintu:
W ciągu najbliższych 10 dni wybierzesz jeden pomysł na IP, zweryfikujesz go rynkowo i zdobędziesz pierwsze sygnały zainteresowania (Leady), pisząc jak najmniej kodu/treści.

Czy to możliwe bez gotowego produktu? Tak. Historia LangFlow (o której pisałem w tym artykule) pokazuje, że dobrze spozycjonowane MVP w “Tornadzie” sprzedaje się samo.

Ale zanim ruszymy po leady, musimy naprawić błąd, który zabija 90% software house’ów na starcie: brak prawa do własnego kodu.

Zaczynamy od przygotowania prawnego i sprzedażowego przedpola.

Pomysłów na stworzenie swojego IP jest naprawdę sporo, ale który wybrać? celowo narzuciłem nam w tym kursie limit 10 dni. Nie dlatego, że planuje spamować ludzi na Linkedin z Waszą pomocą aby zdobyć te upragnione leady. Nie. W tym kursie chcę z Wami wybrać takie IP Opportunity, które ma taką pozycję, że leady same do Was przyjdą w 10 dni. Czy to w ogóle jest możliwe? Zobacz sam na przykład LangFlow, o którym piszę powyżej. Tak, to jest jak najbardziej możliwe.

Natomiast aby w ogóle móc pracować nad swoim IP, trzeba mieć do tego odpowiednie przedpole.

Jak zacząć budować własne IP?

Jednym z pierwszych etapów na drodze bo bycia Gorylem Usługowy, którego firmy często nie potrafią przejść, jest moment, w którym przestają oddawać pełnię praw do wszystkiego, co wytworzą.

Postawię taki bet: Pracujesz na złych umowach.

Takich, w których za każdym razem przekazujesz klientowi pełne prawa autorskie do wykonanego dzieła…

Oczywiście, jest wiele sytuacji, w których klienci nie zgodzą się na nic innego, ale w sektorze oprogramowania są całe warstwy kodu – frameworki, biblioteki, narzędzia – które można tworzyć na własne potrzeby.

Jeśli w trakcie projektu widzisz, że wyłania się moduł, który może się przydać dla innych klientów w Twoim lejku sprzedaży, albo jest łudząco podobny do tego co zrobiłeś wcześniej dla innego klienta - to wiedz, że to pierwszy mocny sygnał, że znalazłeś tzw. IP Opportunity.

IP Opportunity to nic innego jak okazja na stworzenie swojego IP, które nie jest w konflikcie z interesem klienta, jest dla niego pomocą bo korzystając z Twojego IP przyśpiesza swoją pracę, dostaje więcej funkcji, ma stabilniejszy system.

Tych okazji w swojej firmie usługowej IT będziesz miał setki, jak nie tysiące. Czy dane IP Opportunity warto realizować opisze poniżej. Skupmy się na zrobieniu sobie do tego miejsca od strony formalnej.

Nie jestem prawnikiem, ale od ponad 12 lat pracuję nad umowami z klientami i prawnikami.

#1 Zapis o swoich narzędziach

Pierwsza rzecz to powinniście mieć zapis o tym, że poza korzystaniem z oprogramowania OSS, macie prawo na korzystanie z własnych narzędzi, które wytworzyliście na rzecz przyśpieszenia pracy nad projektami. To są wszelkiego rodzaju skrypty automatyzujące, pomagające w CI/CD, ale też własne biblioteki i komponenty, które zespoły tworzą aby ułatwić sobie pracę. Oczywiście, licencja na tego typu oprogramowanie powinna być jasna w umowie i pozwalająca klientowi na korzystanie z niej do realizacji swoich działań biznesowych łącznie z możliwością odsprzedania tej licencji np. w momencie sprzedaży firmy klienta.

Po co ten zapis? bo daje Wam możliwość użycia własnego IP przy założeniu, że rozwijacie je na swój koszt i nie jest to przejęcie know-how klienta.

Jest to elastyczne rozwiązanie, które klient akceptuje bo jest dla niego dość logiczne, że tak jak korzystamy z projektów OSS, to możemy korzystać także z gotowych szablonów projektów, modułów, aby obniżyć koszt wytworzenia systemu także dla klienta.

Natomiast istotne jest aby jasno oddzielić pracę nad swoimi bibliotekami od pracy nad kodem klienta oraz jeśli pracujecie w modelu godzinowym - nie pobierać opłaty za tą część systemu. Ważne jest także jasne komunikowanie z klientem to czego Wasze narzędzia dotyczą, najlepiej tworząc oddzielny SOW (Statement of Work) pod ten zakres prac wraz z określoną licencją.

Tutaj pojawia się pierwsze niebezpieczeństwo bo nie chcemy tworzyć za darmo kodu tylko dlatego, że wydaje nam się, że może nam się kiedyś przydać. Do tego bardzo pomocne będzie narzędzie, które obok Testu Tornada stworzyłem na potrzeby mojego warsztatu o nazwie IP Opportunity Radar. To narzędzie pozwala w oparciu o zebrane dane z różnych źródeł dokonać analizy i przedstawić matrycę porównawczą, które IP Opportunity ma największy potencjał na bycie zalążkiem tornada. W naszym kursie poruszę kilka filarów IP Opportunity Radar, a w tej części przedstawię najważniejszy z nich.

Wracając jednak do naszej sytuacji, gdy już widzicie taki kawałek kodu, który może warto zamienić w swoje IP możecie przystąpić do rozmów z klientem. Najlepiej robić to jeszcze zanim zaczniecie prace. Jest to możliwe, bo podczas analizy wymagań jest duża szansa, że Wasz zespół sam odkryje, że część systemu można by było wydzielić do uniwersalnego kodu. To pierwszy krok. Nauczyć zespół tak patrzeć na projekty jak na puzzle, których cześć pasuje tylko do siebie, a cześć będzie pasowała do innych układanek.

Gdy już odkryjecie IP Opportunity i załóżmy oceniliście już jego potencjał, możecie ustalić plan rozmowy z klientem.

jeśli klient nie potrzebuje praw do tej części kodu bo nie przeszkadza mu, że ktoś inny skorzysta z niego, to nic nie stoi na przeszkodzie aby mu dać ofertę, która jest dla niego super atrakcyjna: zrobimy to taniej bo będziemy mieć dzięki temu szansę wdrożyć nasze biblioteki na Twoim projekcie.

Kluczowe: klient ma rabat nie dlatego, że piszecie kod za jego pieniądze, tylko dlatego, że pozwalacie mu zintegrować kod napisany przez Was na Wasz koszt z jego systemem i go na nim testować. Jest Design Partnerem. Więcej o tym pisze Tomek Karwatka w książce The5 oraz w dodatku w Karwatka Brothers Framework.

#2 Rabat na dane IP dajesz RAZ

Skoro pierwszy klient dostał rabat za to, że testowaliście na nim swój kod i otrzymał działające rozwiązanie, to kolejny klient na ten sam projekt nie dostaje tej samej oferty.

Od początku sprzedajecie dwie rzeczy. Usługę wytworzenia systemu oraz licencję na kod wraz z możliwym dostosowaniem (również na licencji).

To oznacza, że jest duża szansa, że już drugi klient pozwoli Wam zarobić więcej niż ten pierwszy bo wartość jaką otrzymał jest taka sama jak pierwszy klient, a nie musiał Wam robić przysługi. Nie ma argumentu do negocjacji. Nawet więcej - dostaje lepszy kod niż jakbyście go napisali za pierwszym razem bo już był sprawdzony w boju. Cena więc powinna być taka jaką normalnie by miał zapłacić za wytworzenie tego systemu z przekazaniem pełnych praw, a może nawet wyższa bo korzystając z istniejącego modułu dostarczycie system szybciej i z lepszą jakością.

#3 Klient chętnie zapłaci Tobie za licencję

Zrozumienie tych różnic w dynamice negocjacji zmienia wszystko. Gdy klient przychodzi do Ciebie po “custom development”, od razu ustawia się w pozycji właściciela. Płaci za Twój czas, więc oczekuje, że wszystko, co powstanie, będzie jego własnością. Jeśli w tym momencie spróbujesz zachować prawa do części kodu (udzielając licencji), klient niemal zawsze zażąda rabatu. W jego oczach “nie dostaje wszystkiego”, więc powinien zapłacić mniej.

Zupełnie inaczej wygląda rozmowa, gdy klient przychodzi kupić od Ciebie produkt – nawet jeśli ten produkt jest jeszcze niekompletny. Wówczas od pierwszej minuty rozumie, że kupuje rozwiązanie problemu, a nie wyłączne prawa do kodu. Nie oczekuje, że stanie się właścicielem Twojego IP, tak jak nie oczekuje, że stanie się właścicielem kodu Salesforce’a czy SAP-a, gdy kupuje licencję.

Co więcej, jeśli pokażesz mu, że do “pełnego szczęścia” (Whole Product) brakuje kilku funkcji, które są na Twojej roadmapie, często zgodzi się za nie zapłacić w ramach wdrożenia. Finansuje w ten sposób Twoje R&D, ale nie żąda w zamian praw własności, bo kupuje “przyspieszenie rozwoju produktu”, z którego będzie korzystał. To zdrowy model budowania IP: klient płaci za rozwój Twojego produktu, bo rozwiązuje to jego problem tu i teraz.

Relacja z design partnerem i jego biznes jest dla Ciebie bardzo ważna, dlatego istotne jest zaadresowanie jego obaw.

1. Korzystanie z Twojego IP powinno być wartością dla klienta. Jeśli tak nie jest to możliwe, że ten obszar chce zachować dla siebie na swoją wyłączność - musisz to z nim ustalić i odkryć gdzie on potrzebuje IP, a gdzie wystarczy mu licencja.

2. Jego know-how jest dla niego kluczowe. To gdzie możesz rozważać tworzenie IP to narzędzia, moduły, które nie naruszają jego tajemnic i tylko w porozumieniu z nim.

3. Twój kod piszesz za swoje pieniądze.

4. Jasno określony zakres tego co jest objęte licencją na Twoje IP, a co na przekazaniu praw dot. reszty systemu pozwoli uchronić Ciebie przed problemami

5. Skorzystanie z Twojego IP powinno umożliwić klientowi dalszy samodzielny rozwój tej części systemu, która na nim polega. Vendor-lock to najgorsze co możesz dać swojemu design partnerowi.

A teraz jak już wiesz trochę więcej jak od strony formalnej i sprzedażowej prowadzić rozmowy z klientami…

Zatrzymaj się, zanim „dopiszesz” cały produkt

Gdy już masz ten kawałek kodu – framework, moduł, zalążek produktu – pojawia się pokusa, która zabija najwięcej inicjatyw w firmach usługowych IT.

Zamiast wyjść z tym do ludzi, zamykasz się w biurze.

Wydaje Ci się, że nie możesz nic zrobić, bo to tylko „wtyczka”, „mały moduł”, „niekompletny system”. Próbujesz na własny koszt rozwijać to dalej, bo boisz się momentu, w którym klient zapyta: „A czy to jest gotowe?”, a Ty będziesz musiał odpowiedzieć: „Nie”.

źródło: ChatGPT

Lęk ten jest tylko w Twojej głowie. Nie musisz kłamać. Nie musisz mówić rynkowi, że masz coś, czego nie masz. Nawet jeśli Twój kod ma bugi i jest gotowy w 30% to wiesz już z tych wszystkich wcześniejszych projektów, albo przynajmniej masz wizję, jak powinien wyglądać ten system w całości. To jest ten moment, w którym musisz się zatrzymać. Zamiast kodować w ciemno przez kolejne pół roku, wyjdź do rynku z tym, co masz.

IP Opportunity Radar - filtr Tornada

Jeśli spojrzysz na nasz przykład z LangFlow to widzisz, że artykuł na Reddit to bardzo prosty post. Zapewne stworzenie go wymagało 30 min pracy. Jeśli popatrzysz na repozytorium LangFlow, jak ono wówczas wyglądało (jest pod tym linkiem: https://github.com/langflow-ai/langflow/archive/refs/tags/v0.0.31.zip) to zobaczysz, że jest to bardzo surowy i prosty produkt. Typowe MVP.

Zatem jak się stało, że pragmatycy, którzy stronią od takich projektów nagle chcieli rzucić się na niego? Bo LangFlow nie był w oderwaniu od ekosystemu OSS. To było UI for LangChain! To pozycjonowanie było KLUCZOWE.

Pragmatycy w tornado LangChain szukali właśnie tego narzędzia i fakt, że było dopiero na początku swojej drogi wcale ich nie odstraszył. Jaka jest kluczowa lekcja?

Wrażenie całego produktu dla Twojego nowego IP w tornado buduje się najlepiej w oparciu o technologię, która już tam jest.

I tutaj jest pierwszy brutalny filtr w naszym kursie “Leady w 10 dni z Twojego IP”.

To do czego dążymy w naszym kursie “Leady w 10 dni z Twojego IP” to odrzucić wszystkie IP Opportunities, które nie przechodzą przez ten filtr.

Dam Tobie dwa przykłady.

React Native Geolocation

Pracując z klientem odkryliście, że warto stworzyć bibliotekę do obsługi modułu GPS, bo te wbudowane w React Native, są niewystarczające. Stworzyliście coś co robi to dokładniej, a na dodatek widzicie na rynku firmę Transistor Software https://github.com/transistorsoft, która sprzedaje tego typu moduł za kilkaset dolarów na rok. Myślicie, że rynek jest olbrzymi bo przecież jest bardzo wiele firm, które korzystają z GPSa w swoich aplikacjach. Czujecie ten ból oraz widzicie nagrodę tuż przed sobą. Problem w tym, że React Native już dawno przeszedł fazę tornado, jest teraz na głównej ulicy. Co więcej, sam aspekt GPS to nie jest coś co idzie zawsze w parze z samym React Native, jest to tylko pewien aspekt jednej niszy w React Native - geo-based apps. Co to oznacza?

Pęd pragmatyków dawno się skończył a Twój produkt atakuje przypadki użycia w małej niszy. Główny rynek systematycznie przechodzi na Flutter’a lub React Native, ale panika i i pęd już są dawno za nim. To nie wygeneruje Wam leady w 10 dni, może w 10 miesięcy, ale to w nie pozwoli Wam stać się globalną, wysokomarżową firmą. Zobaczcie tylko jak duża jest firma Transistor Software, która od 10 lat nad tym pracuje. Jest to jednoosobowa działalność Christophera Scotta, widać to chociażby o po tym kto kontrybuuje do flagowego projektu React Native Background Geolocation https://github.com/transistorsoft/react-native-background-geolocation

Drugi przykład to llm-router.

LLM-router to projekt open source, który obecnie ma tylko kilka gwiazdek. Strona projektu (https://llm-router.cloud/) tłumaczy czym jest, poza oczywiście narzędziem pozwalającym na zmianę kierunku ruchu danych pomiędzy np. chmurą (OpenAI/Gemini etc.) vs private-cloud z Twoim własnym modelem LLM. Jest to projekt, który może zginąć jeśli będzie oderwany od ekosystemu, który jest w w tornadzie - w tym przypadku LangChain. LangChain słynie z tego, że szybko staje się skomplikowany (”spaghetti code”). Dla developera LangChain, wdrożenie obsługi zapasowych modeli (fallback) w czystym kodzie jest uciążliwe. Ta biblioteka robi to 10x szybciej i czyściej. Jest to potencjalnie bardzo dobra pozycja ataku tornada AI…ale, trzeba wyciągnąć lekcje z LangFlow i dokonać rebrandingu, aby LL-router stał się naturalnym przedłużeniem LangChain.

Śmię twierdzić, że lekki pivot w komunikacji, trochę inny sposób publikacji i zmiana nazwy repozytorium może wywołać LangFlow effect, o którym czytaliśmy w tym artykule.

Dotarliśmy do końca pierwszej części inicjatywy “Leady w 10 dni z Twojego IP”. W kolejnej części poznamy kolejne elementy IP Opportunity Radar, które pozwolą szybko odsiewać pomysły na IP oraz pierwsze metody testowania swojego IP.

Cześć! Tu Maciej Matt Greń. Od 17 lat pomagam firmom IT uciec z pułapki sprzedawania godzin. W SHGrowth pokazuję, jak zamienić firmy usługowe IT w wysokomarżowy biznes oparty na IP. W darmowej części poznasz odpowiedź dlaczego warto dokonać tej transformacji, a w płatnej sekcji otrzymasz narzędzia do tego jak to wdrożyć. W dzisiejszym numerze:

• Ukryty kluczowy element tworzenia swojego IP - drive

• Jak firma z Brazylii w 2 lata zamieniła się z firmy usługowej w produktową aby zostać kupiona przez IBM - historia Logspace i LangFlow

• Leady w 10 dni z Twojego IP cz. 1

  • zmiana umów z klientami aby móc swobodnie wytwarzać IP

  • zmiana sposobu sprzedaży aby zrobić miejsce na IP-led service

  • IP Opportunity Radar - filtr tornada

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.

Ukryty kluczowy element tworzenia swojego IP - drive

Stworzenie swojego IP (open source, kurs, ebook, webinar, boilerplate) to dobry sposób na wręczenie klientom gotowego produktu, który przyśpiesza im rozwiązanie określonego problemu. Po co to robić? bo przejście o kilka kroków dalej dzięki Twojej pomocy to dobry start Twojej relacji z klientem. To, że Twoje rozwiązanie go tam zaprowadziło sprawia, że nie masz konkurencji, bo tylko Ty znasz swoje rozwiązanie najlepiej na świecie. Co więcej, miejsce do którego zaprowadziłeś klienta, to często granica jest własnych możliwości wdrożeniowych. W skrócie - musisz go dalej przenieść suchą stopą na koniec tej drogi i chętnie Ci za to zapłaci.

Takie IP, które daje realną wartość odbiorcy można pisać bardzo długo. Poprawiać, stabilizować, dodawać nowe funkcje, zanim się go dostarczy do rąk społeczności. Mijają miesiące, czasem nawet lata. Projekt pochłonął już olbrzymią cześć Twoich środków, a Ty nadal go nawet nie dałeś w ręce wybranych osób.

To dramat i sam dobrze go znam bo obecnie ciągle przesuwamy wypuszczenie naszego projektu OSS na światło dzienne. Bo codziennie jest coś do poprawy, dodajemy funkcje i testujemy na naszych pilotażowych klientach.

źródło: ChatGPT

To pali nie tylko czas, ale też energię, którą nazywam drive’em. Drive, dlatego bo jedziesz po określonym torze, czujesz, że ten tor jest dobry i systematycznie przyśpieszasz. Gdy jednak robisz coś przez miesiące w zaciszu swojego komputera, to drive jest tylko Twój. Twój drive natomiast jest delikatny bo ma na niego wpływ to czy w danym momencie życia masz spokojną twórczą głowę czy też jest to czas chaosu, zawirowań, trosk.

Dochodzisz do momentu gdy drive spada do zera, a projekt, piękny, cudowny projekt, stracił właśnie życie.

Na pewno nie. Nikt nie chce patrzeć na swoje dzieło, jak zostaje zamknięte w pudełku na strychu. Dlatego warto znaleźć dużo wcześniej moment, gdy mamy jeszcze duże pokłady drive’a (energii) i wyjść z tym do świata.

Uczucie cringe chyba najlepiej do tego momentu pasuje. Czujesz, że robisz coś pierwszy raz, że pokazujesz swój kod jakbyś zapraszał kogoś do brudnego pokoju. Trzeba natomiast to uczucie zaakceptować i z tym cringe’owym uśmiechem wypuścić projekt na świat.

Masz już swoje IP? już spaliłeś swój drive niepotrzebnie.

Sam fakt, że już posiadasz stworzone swoje IP oznacza, że spaliłeś bardzo dużo swojego drive, na stawianie budynku, nie widząc czy podłoże to skała czy piasek. Jak odkryć odpowiednie podłoże na Twój projekt? piszę o tym w kursie Leady w 10 dni z Twojego IP. To część płatna tego newslettera, która przez najbliższe miesiące będzie zbiorem precyzyjnych kroków, narzędzi, przykładów jak szybko walidować odkryte IP i złapać pierwsze leady.

Wracając do drive’a. To do czego Ciebie zachęcam to abyś przestał kodzić. Nie pisz już ani jednej linijki kodu. Zamiast tego zrób coś innego.

Naładuj swój drive. Jak to zrobić?

Największą siłą napędową artysty, a powiedzmy sobie wprost - tworząc projekt OSS masz w krwi 100% artysty, który patrzy jak przed nim piętrzy się jego dzieło, jest to gdy jego dzieło jest docenione.

W przypadku projektów OSS, aby coś zostało docenione to trzeba podzielić się swoim pomysłem ze światem. Pomysłem, nie projektem OSS. To duży dyskomfort bo wymaga od nas wyjścia do ludzi, obcych i pytania o opinię na temat danego problemu. W książce Business Model Canvas jest to tzw. Customer Discovery, proces w którym próbujemy odkryć sytuację naszego odbiorcy, jego bóle i potrzeby. Nie rozmawiamy o rozwiązaniu!

Dzięki Customer Discovery nasz drive napełnia się lub... może zostać totalnie opróżniony z paliwa gdy okazuje się, że po pierwszej rozmowie z odbiorcą otrzymujesz deszcz feedbacku i pytań, które nagle okazują się oczywiste.

Jak robić customer discovery opisuję w Leady w 10 dni z Twojego IP, natomiast polecam bardzo książkę Mom Test (momtestbook.com), polecił mi ją kiedyś Kamil Osiecki https://www.linkedin.com/in/osiecki-kamil/ , CEO Ideamotive (dziękuję!) gdy doradzałem Ideamotive w budowie nowego silnika wzrostu. Książka Mom Test tłumaczy jak prowadzić rozmowy typu Customer Discovery aby nie kierować rozmówcy na błędny tor, który ma potwierdzić nasze hipotezy.

Byłem zauroczony moim rozwiązaniem. Artyści tak mają. Lubimy tworzyć, tworzyć, tworzyć. Zmieniać, poprawiać. To nasze naturalne bezpieczne środowisko.

Można powiedzieć, że artyści mają naturalny drive z robienia czegoś dla siebie. Pewnie dlatego nie potrzebujemy opinii innych gdy jesteśmy w procesie tworzenia. Z drugiej strony, przełączenie naszego drive’a na opinię innych sprawi, że to co tworzymy będzie faktycznie komuś służyć.

Przestawienie swojego drive’a na słuchanie opinii vs samego siebie to brutalny proces. Z drugiej strony, jeszcze bardziej cierpimy gdy to co tworzymy, nikogo nie interesuje. Ostatecznie, każdy artysta potrzebuje być dostrzeżony, dlatego jedyną drogą jest najwcześniej jak się da zbierać informacje zwrotne od ludzi, którym chcemy pomóc.

To dobra droga aby drive, który ma określoną ilość paliwa otrzymywał je z zewnętrznego źródła.

Jak firma z Brazylii w 2 lata zamieniła się z firmy usługowej w produktową

Karwatka Brothers Framework to 9-etapowa strategia transformacji firmy usługowej w wysokomarżowy biznes oparty na IP, polegająca na sfinansowaniu własnego produktu z zysków generowanych na fali technologicznego “Tornada”. Pozycja Goryla Usługowego to status niekwestionowanego lidera w tej niszy, który dzięki unikalnej ekspertyzie przestaje konkurować stawką godzinową, a klienci sami zabiegają o współpracę z nim.

Czasem ten proces trwa wiele lat. Jeśli dobrze się wstrzelisz, tak jak to było z firmą Logspace, od startu firmy do sprzedaży do IBM minęły niecałe 3 lata... imponujące.

Logspace zaczął jak każda inna firma usługowa. Founder opublikował artykuł na Medium (https://medium.com/logspace/launching-logspace-company-services-principles-goals-e077fa8cad93) o tym, że zakłada firmę usługową, prosta strona jak ich wiele na rynku wskazywała na kolejny nudny start w czerwony ocean usług systemów szytych na miarę na głównym rynku uczenia maszynowego.

źródło: https://web.archive.org/web/20220405031625/https://logspace.ai/

Zachęcam do przeczytania wpisu Rodrigo Nadera (https://www.linkedin.com/in/rodrigo-nader-673163bb/), obecnego prezesa LangFlow (dawniej Logspace) jaką miał wizję na swoją firmę. Mówiąc brutalnie - nie imponuje.

“Logspace was developed to help businesses and organizations that have an interest in Machine Learning to find the right fit for their specific needs, offering custom solutions powered by robust technologies, with pipelines that start from experimentation all the way up to deployment.”

Może ta szczerość i prostota to była recepta na sukces? tego nie wiem. Wiem natomiast, że szybko zaczęli tworzyć swoje IP. Nazwali to LangFlow - GUI do Langchain. Stworzyli to narzędzie w marcu 2023 roku i od razu zaczęło rosnąć jak na drożdżach. Jak?

Reddit.

Reddit to świetne narzędzie do złapania trakcji na Github

To właśnie Reddit napędził pierwszą falę użytkowników. Wiosną 2023 Reddit był najgorętszym miejscem dla projektów AI - każdy nowy tool „for LangChain” natychmiast trafiał przed tysiące developerów. Posty o LangFlow pojawiły się równocześnie na r/MachineLearningNews, r/LangChain, r/LLMDevs i r/LanguageTechnology, z wysokim poziomem zaangażowania (upvotes, komentarze, dyskusje).

Z danych historycznych Reddit API oraz metryk porównywalnych projektów (Flowise, AgentGPT, AutoGPT), publikowanych w dokładnie tym samym okresie, wiemy, że posty AI z 50–200 upvotes generowały od kilku do nawet kilkunastu tysięcy przekliknięć do repozytoriów GitHuba.

Wpis o LangFlow na Reddit miało bardzo podobną skalę reakcji więc w pełni bezpiecznie można przyjąć, że w pierwszych dniach wygenerowało co najmniej kilka tysięcy wejść na repozytorium. W świecie OSS to wystarczy, aby wskoczyć na GitHub Trending i uruchomić efekt domina: Slack LangChain, Discordy AI, Twitter, newslettery, blogi.

Reddit był zapałką.

źródło: https://www.reddit.com/r/machinelearningnews/comments/11uqdju/meet_langflow_an_open_source_ui_for_langchain_ai/

To tylko tytuł i video! nic więcej. Odpowiedni wątek na Reddit, odpowiedni moment w rynku. Idealny przykład złapania tornada.

Potem nastąpił wybuch na Github. Repozytorium łapało gwiazdki jak dziecko nowe zabawi w sklepie. UI for LangChain to majstersztyk nazewnictwa. Nie było tutaj nic sprzedażowego. Po prostu UI do LangChain. 100% trafia w pragmatyków, którzy tego właśnie potrzebowali.

Równolegle Rodrigo zaczął pisać na Linkedin. Zanalizowałem 231 postów…

Ewolucja komunikacji: od developer tool do enterprise platform

Analiza 231 postów Rodrigo Nadery, CEO Logstack z ostatnich 2 lat pokazuje wyraźną transformację. Nie chodzi tylko o wzrost zaangażowania (z ~20 do 50-200 komentarzy na post), ale o fundamentalną zmianę pozycjonowania.

Faza 1: Początki (2023) - “UI for LangChain”

Pierwsze posty były proste i techniczne. “We are excited to announce LangFlow - An Open Source UI for LangChain”. Hashtagi: #ai #langchain #chatgpt #gpt3 #gpt4 #opensource.

Zaangażowanie: 20-30 komentarzy. Styl: developer talking to developers. Posty głównie własne o funkcjach produktu. To był moment, gdy Reddit napędzał ruch, a LinkedIn był dodatkowym kanałem. Rodrigo nie próbował być thought leaderem po prostu informował o narzędziu.

Faza 2: Budowanie społeczności (2023-2024) - “10k stars!”

Gdy Langflow osiągnął 10k GitHub stars, posty zaczęły się zmieniać. “Big news! Langflow has hit 10k stars on GitHub!” to milestone, który buduje wiarygodność.

Zaangażowanie rosło do 30-50 komentarzy. Pojawiły się reposty treści społeczności np. gdy ktoś pisał o LangFlow, Rodrigo to udostępniał. Wygląda jakby to był moment, gdy zrozumiał, że LinkedIn to nie tylko kanał informacyjny, ale platforma do budowania marki.

Faza 3: Przełom - akwizycja DataStax (10-11 miesięcy temu)

“HUGE news... Langflow is being acquired by DataStax!” - ten post miał 156 komentarzy i 7 repostów. To był moment, gdy wszystko się zmieniło. Pozycjonowanie przeskoczyło z “developer tool” na “enterprise AI platform”. Posty zaczęły mówić o “empowering enterprises”, nie tylko o “prototyping with LangChain”. Zaangażowanie skoczyło do 50-100 komentarzy na post. Rodrigo zaczął częściej repostować treści o trendach AI — nie tylko o Langflow, ale o całym ekosystemie.

Faza 4: Dojrzałość produktu (8-10 miesięcy temu) - “Langflow 1.0, 1.1, 1.2...”

Główne nowe wydania LangFlow: 1.0, 1.1, 1.2, 1.3, 1.4. Każdy release to osobny post z konkretnymi funkcjami. Zaangażowanie stabilne i wysokie: 47-142 komentarze na postach.

Ale to też moment, gdy Rodrigo odkrył, że reposty edukacyjne działają lepiej niż własne posty. Repost o Stanford LLMs lecture: 126 komentarzy, 388 repostów. Memo CEO Opendoor o “Default to AI”: 653 komentarze, 126 repostów.

Mix contentu: 60% reposty (trendy AI, edukacja) + 40% własne (releases, funkcje). To już nie był Rodrigo jako developer tool creator - to był thought leader, który dobiera najlepsze treści z ekosystemu AI.

Faza 5: IBM Era (2-8 miesięcy temu) - Enterprise positioning

Kolejna akwizycja: “DataStax is now part of IBM”. Pozycjonowanie przeskoczyło na executive level. Posty o strategic partnerships: IBM + Anthropic, NVIDIA GTC, watsonx Orchestrate.

Zaangażowanie najwyższe w historii w takich tematach:

• GitHub Copilot Extensions: 786 komentarzy, 128 repostów

• Reinforcement Learning post: 866 repostów (tylko 28 komentarzy, ale viral na repostach)

• Stanford LLMs: 388 repostów

To był moment, gdy Rodrigo zrozumiał mechanikę LinkedIn: reposty o trendach AI generują więcej zaangażowania niż własne posty o produktach. 59% postów to reposty i strategiczne dobierane treści, które pozycjonują go jako eksperta, który wie, co się dzieje w AI.

Faza 6: Obecnie (ostatni miesiąc) - Competitive positioning

“AgentKit vs LangFlow” to już nie tylko informacja o produkcie, ale strategiczne pozycjonowanie w kategorii. Langflow 1.6 z Advanced Parser: 333 komentarze. IBM + Anthropic partnership: 117 repostów. Styl: strategic + competitive + technical. Mniej postów, ale wyższe zaangażowanie. Więcej oryginalnych postów o produktach oraz strategiczne reposty.

59% postów to reposty. To nie jest lenistwo, to strategiczne dobieranie treści, które pozycjonuje go jako kogoś, kto wie, co się dzieje w AI. Własne posty o produktach są ważne, ale to reposty budują wiarygodność jako thought leader.

Druga lekcja: zaangażowanie rośnie z pozycjonowaniem. Gdy był “developer tool creator”, miał 20-30 komentarzy. Gdy stał się “enterprise AI leader”, ma 50-200 komentarzy. To nie przypadek. To efekt zmiany pozycjonowania i grupy docelowej.

Trzecia lekcja: milestone’y działają. 10k GitHub stars, Langflow 1.0, akwizycje - każdy milestone to okazja do posta, który buduje wiarygodność i zaangażowanie.

Rodrigo przeszedł przez różne grupy decydentów na LinkedIn:

1. 2023: “UI for LangChain” trafia w developerów, którzy potrzebują narzędzia

2. 2024: “Enterprise AI platform” trafia w decision makers, którzy potrzebują bezpiecznego wyboru

3. 2025: “Thought leader” trafia w ludzi, którzy chcą wiedzieć, co będzie dalej

Każda grupa wymagała innej komunikacji. Rodrigo nie próbował być wszystkim dla wszystkich. Dostosowywał komunikację do fazy rozwoju, w której był Langflow.

Co to oznacza dla Twojego firmy usługowej IT?

Przykład Logspace jest dla mnie niesamowicie budujący. Po pierwsze, pokazuje jak firma usługowa IT, pokorna, prosta, może szukając bólu i rozwiązując go w odpowiedni sposób w odpowiednim momencie rynku zamienić się w firmę opartą o swoje IP.

Po drugie, to, że jest to firma z Brazylii pokazuje, że Karwatka Brothers Framework nie ma granic. Działa zarówno w Polsce, jak i w każdym innym miejscu na świecie. Kluczem jest dopasowanie DNA firmy, do odpowiednio dobranej technologii/trendu, która trafia w Tornado no i oczywiście - egzekucja. Jak widzicie po postach na Reddit, Linkedin - to nie jest mistrzostwo świata. To co dało im siłę nośną to było odpowiednie trafienie w tornado.

Jeśli budujesz IP i chcesz użyć LinkedIn do budowania pozycji eksperckiej, obserwuj ewolucję Rodrigo:

1. Zacznij od własnych postów o produkcie - budujesz wiarygodność jako twórca

2. Dodaj reposty treści społeczności - pokazujesz, że jesteś częścią ekosystemu

3. Dobieraj najlepsze treści z kategorii - budujesz pozycję thought leadera

4. Używaj milestone’ów - każdy sukces to okazja do posta

5. Pozycjonuj się strategicznie - nie tylko informuj, ale pokazuj, gdzie jesteś w kategorii produktu, który tworzysz

LinkedIn to nie tylko kanał sprzedażowy. To platforma do budowania pozycji eksperckiej, która później przekłada się na biznes. Rodrigo pokazuje, jak to zrobić systematycznie przez 2 lata.

Leady w 10 dni z Twojego IP - cz 1.

Jak zacząć budować własne IP?

Jednym z pierwszych etapów na drodze bo bycia Gorylem Usługowy, którego firmy często nie potrafią przejść, jest moment, w którym przestają oddawać pełnię praw do wszystkiego, co wytworzą.

Postawię taki bet: Pracujesz na złych umowach.

Takich, w których za każdym razem przekazujesz klientowi pełne prawa autorskie do wykonanego dzieła…

Oczywiście, jest wiele sytuacji, w których klienci nie zgodzą się na nic innego, ale w sektorze oprogramowania są całe warstwy kodu – frameworki, biblioteki, narzędzia – które można tworzyć na własne potrzeby.

Jeśli w trakcie projektu widzisz, że wyłania się moduł, który może się przydać dla innych klientów w Twoim lejku sprzedaży, albo jest łudząco podobny do tego co zrobiłeś wcześniej dla innego klienta - to wiedz, że to pierwszy mocny sygnał, że znalazłeś tzw. IP Opportunity.

IP Opportunity to nic innego jak okazja na stworzenie swojego IP, które nie jest w konflikcie z interesem klienta, jest dla niego pomocą bo korzystając z Twojego IP przyśpiesza swoją pracę, dostaje więcej funkcji, ma stabilniejszy system.

Tych okazji w swojej firmie usługowej IT będziesz miał setki, jak nie tysiące. Czy dane IP Opportunity warto realizować opisze poniżej. Skupmy się na zrobieniu sobie do tego miejsca od strony formalnej.

Nie jestem prawnikiem, ale od ponad 12 lat pracuję nad umowami z klientami i prawnikami.

#1 Zapis o swoich narzędziach

Pierwsza rzecz to powinniście mieć zapis o tym, że poza korzystaniem z oprogramowania OSS, macie prawo na korzystanie z własnych narzędzi, które wytworzyliście na rzecz przyśpieszenia pracy nad projektami. To są wszelkiego rodzaju skrypty automatyzujące, pomagające w CI/CD, ale też własne biblioteki i komponenty, które zespoły tworzą aby ułatwić sobie pracę. Oczywiście, licencja na tego typu oprogramowanie powinna być jasna w umowie i pozwalająca klientowi na korzystanie z niej do realizacji swoich działań biznesowych łącznie z możliwością odsprzedania tej licencji np. w momencie sprzedaży firmy klienta.

Po co ten zapis? bo daje Wam możliwość użycia własnego IP przy założeniu, że rozwijacie je na swój koszt i nie jest to przejęcie know-how klienta.

Jest to elastyczne rozwiązanie, które klient akceptuje bo jest dla niego dość logiczne, że tak jak korzystamy z projektów OSS, to możemy korzystać także z gotowych szablonów projektów, modułów, aby obniżyć koszt wytworzenia systemu także dla klienta.

Natomiast istotne jest aby jasno oddzielić pracę nad swoimi bibliotekami od pracy nad kodem klienta oraz jeśli pracujecie w modelu godzinowym - nie pobierać opłaty za tą część systemu. Ważne jest także jasne komunikowanie z klientem to czego Wasze narzędzia dotyczą, najlepiej tworząc oddzielny SOW (Statement of Work) pod ten zakres prac wraz z określoną licencją.

Tutaj pojawia się pierwsze niebezpieczeństwo bo nie chcemy tworzyć za darmo kodu tylko dlatego, że wydaje nam się, że może nam się kiedyś przydać. Do tego bardzo pomocne będzie narzędzie, które obok Testu Tornada stworzyłem na potrzeby mojego warsztatu o nazwie IP Opportunity Radar. To narzędzie pozwala w oparciu o zebrane dane z różnych źródeł dokonać analizy i przedstawić matrycę porównawczą, które IP Opportunity ma największy potencjał na bycie zalążkiem tornada. W naszym kursie poruszę kilka filarów IP Opportunity Radar, a w tej części przedstawię najważniejszy z nich.

Wracając jednak do naszej sytuacji, gdy już widzicie taki kawałek kodu, który może warto zamienić w swoje IP możecie przystąpić do rozmów z klientem. Najlepiej robić to jeszcze zanim zaczniecie prace. Jest to możliwe, bo podczas analizy wymagań jest duża szansa, że Wasz zespół sam odkryje, że część systemu można by było wydzielić do uniwersalnego kodu. To pierwszy krok. Nauczyć zespół tak patrzeć na projekty jak na puzzle, których cześć pasuje tylko do siebie, a cześć będzie pasowała do innych układanek.

Gdy już odkryjecie IP Opportunity i załóżmy oceniliście już jego potencjał, możecie ustalić plan rozmowy z klientem.

jeśli klient nie potrzebuje praw do tej części kodu bo nie przeszkadza mu, że ktoś inny skorzysta z niego, to nic nie stoi na przeszkodzie aby mu dać ofertę, która jest dla niego super atrakcyjna: zrobimy to taniej bo będziemy mieć dzięki temu szansę wdrożyć nasze biblioteki na Twoim projekcie.

Kluczowe: klient ma rabat nie dlatego, że piszecie kod za jego pieniądze, tylko dlatego, że pozwalacie mu zintegrować kod napisany przez Was na Wasz koszt z jego systemem i go na nim testować. Jest Design Partnerem. Więcej o tym pisze Tomek Karwatka w książce The5 oraz w dodatku w Karwatka Brothers Framework.

#2 Rabat na dane IP dajesz RAZ

Skoro pierwszy klient dostał rabat za to, że testowaliście na nim swój kod i otrzymał działające rozwiązanie, to kolejny klient na ten sam projekt nie dostaje tej samej oferty.

Od początku sprzedajecie dwie rzeczy. Usługę wytworzenia systemu oraz licencję na kod wraz z możliwym dostosowaniem (również na licencji).

To oznacza, że jest duża szansa, że już drugi klient pozwoli Wam zarobić więcej niż ten pierwszy bo wartość jaką otrzymał jest taka sama jak pierwszy klient, a nie musiał Wam robić przysługi. Nie ma argumentu do negocjacji. Nawet więcej - dostaje lepszy kod niż jakbyście go napisali za pierwszym razem bo już był sprawdzony w boju. Cena więc powinna być taka jaką normalnie by miał zapłacić za wytworzenie tego systemu z przekazaniem pełnych praw, a może nawet wyższa bo korzystając z istniejącego modułu dostarczycie system szybciej i z lepszą jakością.

#3 Klient chętnie zapłaci Tobie za licencję

Zrozumienie tych różnic w dynamice negocjacji zmienia wszystko. Gdy klient przychodzi do Ciebie po “custom development”, od razu ustawia się w pozycji właściciela. Płaci za Twój czas, więc oczekuje, że wszystko, co powstanie, będzie jego własnością. Jeśli w tym momencie spróbujesz zachować prawa do części kodu (udzielając licencji), klient niemal zawsze zażąda rabatu. W jego oczach “nie dostaje wszystkiego”, więc powinien zapłacić mniej.

Zupełnie inaczej wygląda rozmowa, gdy klient przychodzi kupić od Ciebie produkt – nawet jeśli ten produkt jest jeszcze niekompletny. Wówczas od pierwszej minuty rozumie, że kupuje rozwiązanie problemu, a nie wyłączne prawa do kodu. Nie oczekuje, że stanie się właścicielem Twojego IP, tak jak nie oczekuje, że stanie się właścicielem kodu Salesforce’a czy SAP-a, gdy kupuje licencję.

Co więcej, jeśli pokażesz mu, że do “pełnego szczęścia” (Whole Product) brakuje kilku funkcji, które są na Twojej roadmapie, często zgodzi się za nie zapłacić w ramach wdrożenia. Finansuje w ten sposób Twoje R&D, ale nie żąda w zamian praw własności, bo kupuje “przyspieszenie rozwoju produktu”, z którego będzie korzystał. To zdrowy model budowania IP: klient płaci za rozwój Twojego produktu, bo rozwiązuje to jego problem tu i teraz.

Relacja z design partnerem i jego biznes jest dla Ciebie bardzo ważna, dlatego istotne jest zaadresowanie jego obaw.

1. Korzystanie z Twojego IP powinno być wartością dla klienta. Jeśli tak nie jest to możliwe, że ten obszar chce zachować dla siebie na swoją wyłączność - musisz to z nim ustalić i odkryć gdzie on potrzebuje IP, a gdzie wystarczy mu licencja.

2. Jego know-how jest dla niego kluczowe. To gdzie możesz rozważać tworzenie IP to narzędzia, moduły, które nie naruszają jego tajemnic i tylko w porozumieniu z nim.

3. Twój kod piszesz za swoje pieniądze.

4. Jasno określony zakres tego co jest objęte licencją na Twoje IP, a co na przekazaniu praw dot. reszty systemu pozwoli uchronić Ciebie przed problemami

5. Skorzystanie z Twojego IP powinno umożliwić klientowi dalszy samodzielny rozwój tej części systemu, która na nim polega. Vendor-lock to najgorsze co możesz dać swojemu design partnerowi.

A teraz jak już wiesz trochę więcej jak od strony formalnej i sprzedażowej prowadzić rozmowy z klientami…

Zatrzymaj się, zanim „dopiszesz” cały produkt

Gdy już masz ten kawałek kodu – framework, moduł, zalążek produktu – pojawia się pokusa, która zabija najwięcej inicjatyw w firmach usługowych IT.

Zamiast wyjść z tym do ludzi, zamykasz się w biurze.

Wydaje Ci się, że nie możesz nic zrobić, bo to tylko „wtyczka”, „mały moduł”, „niekompletny system”. Próbujesz na własny koszt rozwijać to dalej, bo boisz się momentu, w którym klient zapyta: „A czy to jest gotowe?”, a Ty będziesz musiał odpowiedzieć: „Nie”.

źródło: ChatGPT

Lęk ten jest tylko w Twojej głowie. Nie musisz kłamać. Nie musisz mówić rynkowi, że masz coś, czego nie masz. Nawet jeśli Twój kod ma bugi i jest gotowy w 30% to wiesz już z tych wszystkich wcześniejszych projektów, albo przynajmniej masz wizję, jak powinien wyglądać ten system w całości. To jest ten moment, w którym musisz się zatrzymać. Zamiast kodować w ciemno przez kolejne pół roku, wyjdź do rynku z tym, co masz.

IP Opportunity Radar - filtr Tornada

Jeśli spojrzysz na nasz przykład z LangFlow to widzisz, że artykuł na Reddit to bardzo prosty post. Zapewne stworzenie go wymagało 30 min pracy. Jeśli popatrzysz na repozytorium LangFlow, jak ono wówczas wyglądało (jest pod tym linkiem: https://github.com/langflow-ai/langflow/archive/refs/tags/v0.0.31.zip) to zobaczysz, że jest to bardzo surowy i prosty produkt. Typowe MVP.

Zatem jak się stało, że pragmatycy, którzy stronią od takich projektów nagle chcieli rzucić się na niego? Bo LangFlow nie był w oderwaniu od ekosystemu OSS. To było UI for LangChain! To pozycjonowanie było KLUCZOWE.

Pragmatycy w tornado LangChain szukali właśnie tego narzędzia i fakt, że było dopiero na początku swojej drogi wcale ich nie odstraszył. Jaka jest kluczowa lekcja?

Wrażenie całego produktu dla Twojego nowego IP w tornado buduje się najlepiej w oparciu o technologię, która już tam jest.

I tutaj jest pierwszy brutalny filtr w naszym kursie “Leady w 10 dni z Twojego IP”.

To do czego dążymy w naszym kursie “Leady w 10 dni z Twojego IP” to odrzucić wszystkie IP Opportunities, które nie przechodzą przez ten filtr.

Dam Tobie dwa przykłady.

React Native Geolocation

Pracując z klientem odkryliście, że warto stworzyć bibliotekę do obsługi modułu GPS, bo te wbudowane w React Native, są niewystarczające. Stworzyliście coś co robi to dokładniej, a na dodatek widzicie na rynku firmę Transistor Software https://github.com/transistorsoft, która sprzedaje tego typu moduł za kilkaset dolarów na rok. Myślicie, że rynek jest olbrzymi bo przecież jest bardzo wiele firm, które korzystają z GPSa w swoich aplikacjach. Czujecie ten ból oraz widzicie nagrodę tuż przed sobą. Problem w tym, że React Native już dawno przeszedł fazę tornado, jest teraz na głównej ulicy. Co więcej, sam aspekt GPS to nie jest coś co idzie zawsze w parze z samym React Native, jest to tylko pewien aspekt jednej niszy w React Native - geo-based apps. Co to oznacza?

Pęd pragmatyków dawno się skończył a Twój produkt atakuje przypadki użycia w małej niszy. Główny rynek systematycznie przechodzi na Flutter’a lub React Native, ale panika i i pęd już są dawno za nim. To nie wygeneruje Wam leady w 10 dni, może w 10 miesięcy, ale to w nie pozwoli Wam stać się globalną, wysokomarżową firmą. Zobaczcie tylko jak duża jest firma Transistor Software, która od 10 lat nad tym pracuje. Jest to jednoosobowa działalność Christophera Scotta, widać to chociażby o po tym kto kontrybuuje do flagowego projektu React Native Background Geolocation https://github.com/transistorsoft/react-native-background-geolocation

Drugi przykład to llm-router.

LLM-router to projekt open source, który obecnie ma tylko kilka gwiazdek. Strona projektu (https://llm-router.cloud/) tłumaczy czym jest, poza oczywiście narzędziem pozwalającym na zmianę kierunku ruchu danych pomiędzy np. chmurą (OpenAI/Gemini etc.) vs private-cloud z Twoim własnym modelem LLM. Jest to projekt, który może zginąć jeśli będzie oderwany od ekosystemu, który jest w w tornadzie - w tym przypadku LangChain. LangChain słynie z tego, że szybko staje się skomplikowany (”spaghetti code”). Dla developera LangChain, wdrożenie obsługi zapasowych modeli (fallback) w czystym kodzie jest uciążliwe. Ta biblioteka robi to 10x szybciej i czyściej. Jest to potencjalnie bardzo dobra pozycja ataku tornada AI…ale, trzeba wyciągnąć lekcje z LangFlow i dokonać rebrandingu, aby LL-router stał się naturalnym przedłużeniem LangChain.

Śmię twierdzić, że lekki pivot w komunikacji, trochę inny sposób publikacji i zmiana nazwy repozytorium może wywołać LangFlow effect, o którym czytaliśmy na początku tego artykułu.

Dotarliśmy do końca pierwszej części inicjatywy “Leady w 10 dni z Twojego IP”. W kolejnej części poznamy kolejne elementy IP Opportunity Radar, które pozwolą szybko odsiewać pomysły na IP oraz pierwsze metody testowania swojego IP.

Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm usługowych IT. Grow Your Software House to biuletyn z częścią darmową na Linkedin rozwinięty o płatne analizy tutaj na Substack wraz z wiedzą, narzędziami i filmami pokazującymi jak przestać błądzić i zacząć systematycznie rozwijać swój swoją firmę usługową IT. W dzisiejszym numerze:

• Jak mieć zdrowe marże na dojrzałym rynku usług IT ?

• Trzy brutalne prawdy, które pozwolą Ci zarabiać dobre marże na dojrzałym rynku

• Pięć strategii GTM dla firm usługowych będących na dojrzałym rynku, aby wykorzystać tornado AI

• przykłady The Momentum, Upside, Revolve Healthcare, Open Mercato, Venloop

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.

Jak mieć zdrowe marże na dojrzałym rynku usług IT ?

Twoja firma usługowa IT traci rozpęd? Często nie chodzi o ludzi, rynek ani o AI, tylko o to, że grasz w złą grę będąc na tzw. dojrzałym rynku. Większość firm tam przebywa, ale nie zdaje sobie z tego sprawy.

Przykładowo, jeśli DNA Twojej firmy oparte jest na Magento to nie oferujesz już innowacji, bo ta technologia już taka nie jest. To co naprawdę oferujesz rynkowi to: pomagasz „zakładnikom Magento” uciec albo ograniczyć od niego zależność.

Jeśli masz firmę, o którym mówisz „Python power house”, to w praktyce robisz głównie hydraulikę danych (pipelines/lakes) dla korporacji. To nic złego, natomiast Twoje usługi nie są unikatowe, jest wiele firm, które to także robią.

Na głównym rynku zwycięża ten, kto potrafi:

Łatwo powiedzieć “zarabiać zdrowe marże na głównym rynku”, ale jak to zrobić?

Trzy brutalne prawdy, które pozwolą Ci zarabiać dobre marże na dojrzałym rynku

Większość firm usługowych IT jest na głównym rynku, czyli miejscu, gdzie klienci korzystają z ustabilizowanych rozwiązań, które są uznawane za standard i korzystają właśnie z usług danej firmy, aby te rozwiązania wdrożyć, usprawnić, rozwinąć.

Brutalna prawda #1: na głównym rynku Twoje usługi zawsze znajdą tańszego konkurenta

Złe metody radzenia sobie z tą prawdą:

• szukanie klientów, którzy nie wiedzą o tym, że mogą taniej, tzw. łosi

• szukanie sposobów, aby zbudować głębszą więź z klientem oderwaną od faktycznej wartości dla jego firmy

• atakowanie konkurencji mówiąc “są z kraju XYZ, a tam są słabsi eksperci” zamiast używać argumentów, które bezpośrednio wpływają na biznes klienta

Dobre metody radzenia sobie z tą prawdą:

• słuchanie klientów, dlaczego wybrali Was, co cenią, co jest unikatową wartością dla ich biznesu

• zrozumienie różnic między Twoją usługą, a usługą konkurencji. Twoje usługi powierzchownie mogą wyglądać podobnie, ale gdy wejdziesz głębiej okazuje się, że to Wy macie know-how, jak uniknąć olbrzymich opóźnień, straconych miesięcy programowania, o których konkurencja nie potrafi mówić, bo liczy na zwycięstwo ceną

• systematyczne edukowanie rynku oraz ludzi Twojej firmy, swoistym playbookiem, który tłumaczy czemu to co robicie przyniesie “większą wartość za mniej”

Brutalna prawda #2: na głównym rynku zazwyczaj jest już “burmistrz” mający kredyt zaufania pragmatyków z dużych firm, którego Ty nigdy nie będziesz mieć

W swojej historii miałem przyjemność konkurować z bardzo dużymi firmami konsultingowymi będąc małym software housem. Wielokrotnie widziałem i też słyszałem o tym, jak wybierany był drogi “burmistrz”, który potem nie dowoził. Przykładem jest słynne wdrożenie SAP-a w Lidlu, które kosztowało 500 mln euro. Dlaczego tak jest? Dlaczego, pomimo że firmy szukają “większej wartości dla ich biznesu, za mniej”, dają się jawnie wpakować w bardzo drogi projekt?

Percepcja, że burmistrz czyli firma uznawana na dojrzałym rynku za lidera w danej niszy, zrealizuje skomplikowany, wieloletni projekt z sukcesem, a inni, nieznani polegną bo nie mają tego typu doświadczenia jest klasycznym schematem, który nie tylko dotyka duże korporacje. My wszyscy tym schematem działamy, gdy jest przed nami duży projekt, w którym nie mamy doświadczenia, np. budowa domu.

Wyobraźmy sobie, że teraz nie budujemy domu dla nas, ale dostaliśmy to jako zadanie od prezesa dużej firmy, dla której budżet nie jest problemem.

Kogo wybierzesz?

Małą firmę z polecenia znajomego, czy może renomowaną firmę, która realizowała projekty dla innych prezesów i może się tym pochwalić na swojej stronie? Oczywiste jest, że pójdziesz w stronę tej drogiej firmy, a główny motyw to tzw. chęć uniknięcia bycia winnym w przypadku porażki.

Gdy rekomendujesz wybór firmy, która jest burmistrzem kupujesz dla siebie kartę ucieczki z więzienia. Jeśli zawali burmistrz - nikt Ciebie nie pociągnie do odpowiedzialności. Jeśli zawali niszowa firma - niestety, Ty będziesz miał kłopoty, bo to Ty ją wybrałeś i nikt więcej nie wesprze Twojego wyboru.

Gdy już rozumiemy lepiej ten mechanizm, zobaczmy jak ta prawda może nam pomóc zarabiać dobre marże na dojrzałym rynku:

Złe metody radzenia sobie z tą prawdą:

• Próbujemy przekonać decydentów w danym projekcie, że jesteśmy lepsi używając racjonalnych argumentów prezentujących Waszą ekspertyzę. Jak widzicie, w tym procesie racjonalność ustępuje reputacji, gwarancjom, ciągłości biznesu.

• Mając możliwość współpracy z dużą firmą, która z jakiegoś powodu Wami się interesuje, wpadacie w kompleks bycia “przegranym na starcie” i dążycie do szybkiego potwierdzenia swojej negatywnej hipotezy, np. próbując domknąć sprzedaż, gdy tak naprawdę dopiero zaczynacie doradztwo.

• Naśladując usługi dużych firm, szybko okazuje się, że nie macie tych procesów, o których piszecie/mówicie, jesteście nieprawdziwi, klient to wyczuwa i ucieka.

Dobre metody radzenia sobie z tą prawdą:

• Praca z dużymi firmami, gdy jesteśmy malutcy, może okazać się sukcesem, jeśli zabierzemy do współpracy kolejną dużą firmę. Oczywiście oddajemy część swojego dochodu, może nawet tracimy szanse na sprzedaż kolejnych usług, bo duża firma doradcza nas tam będzie wygryzać, ale z drugiej strony, w obszarze, w którym jesteście najlepsi - będziecie mieć bardzo lukratywny projekt. Decydenci po stronie dużej firmy będą mieli “kartę ucieczki z więzienia”, bo pracują z inną dużą firmą (burmistrzem), a Wy powoli budujecie swoją ekspertyzę, jak z takimi dużymi firmami pracować.

• Uświadomienie sobie, że praca z dużymi firmami to gra trwająca lata pomaga w ustawieniu odpowiedniej perspektywy oraz zasobów. Zamiast próbować domknąć taką firmę w miesiąc, warto zrozumieć, gdzie są w procesie szukania rozwiązania swojego problemu, czy macie odpowiednie osoby w procesie decyzyjnym i czy dobrze je wysłuchaliście. Większe firmy pracują z Wami głównie dlatego, bo widzą w Was coś wyjątkowego. Czasami nawet Wy sami nie rozumiecie tego myśląc, że przecież “robimy coś prostego”. Może w Waszych oczach to jest proste, ale w oczach klienta, w tym obszarze, z racji Waszych wdrożeń, może materiałów, które pokazują Wasze doświadczenie, może nawet Waszym IP, które rozwiązuje ich problem - w ich oczach - jesteście w tym obszarze burmistrzem. Zrozumienie tego pozwala spokojnie i świadomie prowadzić rozmowy, unikasz udawania tego kim nie jesteś, skupiasz się na tym gdzie jesteś najlepszy.

Brutalna prawda #3: Główny rynek dąży do wycięcia firm usługowych

Technologia w głównym rynku ciągle dojrzewa. Pojawiają się nowe moduły, wtyczki, integracje. Praca firm usługowych zamienia się w pracę doradczą na temat doboru tych technologii, a usługi zostają coraz mocniej sprowadzone do niszowych przypadków użycia. Przepaść pomiędzy firmami będącymi burmistrzami usługowymi, a pozostałymi firmami się pogłębia bo firmy są otwarte do płacenia wysokich stawek tylko za “kartę wyjścia z więzienia”. W innych przypadkach - szukają najtańszej opcji, a wybór jest duży.

Złe metody radzenia sobie z tą prawdą:

• Zbieranie projektów brown-field, utrzymaniowych pozwala na znalezienie dla siebie bezpiecznego przyczółka, gdzie wiedza zamknięta w głowach Twoich ludzi to zakładnik, którego klient nie chce stracić. Pomimo, że rynek dąży do wycięcia firm usługowych to Twoja firma może się ostać w tych obszarach, do czasu... aż Twój kluczowy personel nie odejdzie lub nie nastąpi diametralna decyzja o wycięciu starej technologii po stronie klienta.

• Obniżanie stawek w celu zachowania projektów to jedna z metod krótkotrwałego przetrwania. Niestety obcinając marże, systematycznie prowadzimy naszą firmę do stagnacji, gdzie ruchów jest coraz mniej.

Dobre metody radzenia sobie z tą prawdą:

Zrozumienie, że rynek dąży do usystematyzowania całego ekosystemu wokół danej technologii, to tak naprawdę błogosławieństwo. Ten, kto opanuje ten ekosystem, kto zrozumie, w jakich przypadkach użycia można przyspieszyć systematyzację, staje się burmistrzem w danej niszy na głównym rynku. To okazja, a nie zagrożenie. Okazja do dostarczenia “większej wartości za mniej, z lepszym zyskiem”. Lepszy zysk pojawia się wówczas, gdy firma standaryzuje swoją usługę w danej niszy i po prostu może ją sprzedać w innym modelu, nie opartym o spędzone godziny, tylko o dostarczoną wartość.

W książce Geoffrey’a Moore’a jest to tzw. strategia “pełny produkt +1”. Polega na tym, że świadomie poszukujemy ulepszeń, a czasem nawet rewolucyjnych wdrożeń w ekosystemie “pełnego produktu” czyli rozwiązania, które jest standardem na dojrzałym rynku. Poniżej piszę o pięciu różnych strategiach, które można w tym celu wdrożyć.

Pięć strategii GTM dla firm usługowych będących na dojrzałym rynku, aby wykorzystać tornado AI

Będąc na dojrzałym rynku i świadcząc tam usługi dla różnych klientów, firmy usługowe są świadkami jak przez określone obszary działalności ich klientów przetaczają się tzw. Tornada. Tornado w terminologii Geoffrey’a More’a to moment gdy pragmatycy widząc, że “wszyscy” przechodzą na dane rozwiązanie również zaczynają to rozwiązanie wdrażać.

Tornada przetaczają się przez określone obszary działania firmy. Obecnie tornado AI przetacza się przez te części systemów i narzędzi, które wykorzystujemy do produktywności, programowania, tworzenia treści.

Natomiast firmy na dojrzałym rynku są pragmatyczne. W takich firmach twardy biznes dzieje się w pozostałych 80% obszarów firmy. Tam nikt nie ładuje na siłę AI, tylko idzie w sprawdzone rozwiązania, których używa już konkurencja lub firmy uznawane za wzorce do naśladowania.

Z moich obserwacji są firmy usługowe, które widząc, że znajdują się na tzw. głównym rynku, gdzie ich przewagi konkurencyjne topnieją, świadomie wybrały drogę poszukiwania nowych silników wzrostu. Oto pięć różnych podejść, które w obliczu obecnego huraganu AI wybierają firmy usługowe IT:

The Momentum - jeszcze dwa lata temu opierało się na klasycznym generycznym software housie, skierowało się w stronę healthcare i nie poddawają się w dalszej walce o złapanie fal, które rozbijają ten sektor rynku.

Upside - od wielu lat firma działająca w e-commerce obecnie wypuściła Enthusiast, niszowy produkt dla agentic e-commerce.

Revolve Healthcare - od lat buduje swoją pozycję w regulowanym sektorze medycznym, chroniony przez mury certyfikacji.

SOFTIQ - ugruntowany w przetargach w govtech, który wykorzystał tornado AI do stworzenia własnego IP (Przetargi.io) i ekspansji na nowe rynki.

Venloop - odkrywca smart-vendingu dla e-commerce, który przygotowuje grunt dla innych, odkrywając nowe terytoria w hardware, logistyce i omnichannel.

To pięć strategii, pięć różnych podejść do tego, jak i gdzie grać w tornado AI.

The Momentum, z racji skostniałego sektora healthcare, atakuje ten obszar jako barbarzyńca, czyli według definicji Geoffreya Moore’a przystępuje do ataku partyzanckiego od najsłabszych miejsc — jednym z nich jest personalized healthcare. To przełom paradygmatu, gdzie obecne miasta będące na dojrzałym rynku, czyli olbrzymie firmy healthcare, nie korzystają z potencjału drzemiącego w danych, jakie zbieramy o codziennie sobie samym. To nowe przypadki użycia, które nie istnieją obecnie w miastach healthcare na głównym rynku, otwierają mury miasta, przez które barbarzyńcy mogą wejść i je splądrować.

Upside robi coś innego — od lat działa na głównym rynku, gdzie pomaga firmom w digital commerce przy użyciu nowego stacka technologicznego. Po wdrożeniach headless e-commerce rynek się ustabilizował i trwa docieranie się, w którym ciężkie platformy ścierają się z nowymi open-source’owymi rozwiązaniami, takimi jak Medusa.js.

W tym rynku jest tak naprawdę niewiele przełomów i przejścia z jednej platformy na drugą są dość powolną grą. Medusa.js pomaga w jednym segmencie rynku, czyli głównie B2B e-commerce, gdzie stara się być najlepszą alternatywą dla ciężkich rozwiązań na drogich licencjach. Jest natomiast potrzeba wprowadzania do istniejących rozwiązań e-commerce usprawnień i nowości.

Fala AI przetacza się także przez e-commerce i tam w różnych konkretnych przypadkach użycia faktycznie dostarcza wartość.

Upside startuje z głównego rynku e-commerce, z niszy nowszych rozwiązań headless e-commerce, takich jak Medusa.js, i wybiera konkretny zbiór przypadków użycia związanych z backoffice w e-commerce/operacjami zarządzania e-commerce. Systematycznie bierze każdy popularny przypadek użycia, np. wprowadzanie produktów do systemu, i dokonuje jego rewolucyjnego przełomu z użyciem AI. Robi to dzięki swojemu rozwiązaniu Enthusiast, pokazując gotowy produkt z realną wartością. Klasyczna strategia “pełny produkt +1” gdzie pełny produkt to istniejący system e-commerce oparty na Medusa.js wdrożony przez dojrzałe firmy.

Mamy do czynienia z różnymi planami GTM. The Momentum jest barbarzyńcą, Upside jest osadnikiem - używa technologii AI z Main Street, ale znajduje dla niej nowe zastosowanie w e-commerce, obok miasta z którego się wywodzi.

Ale są jeszcze trzy strategie, które warto rozważyć: obywatel, imperialista i odkrywca.

Obywatel: chroniony regulacjami

Obywatel to firma usługowa, który pomimo że widzi barbarzyńców z AI, śmieje im się w twarz. Wie, że jego miasto nie będzie pokonane, bo jego mury są zbudowane z kamiennych, stromych regulacji.

Przykładem takiego Obywatela jest Revolve Healthcare. Firma Przemka Grzywy to certyfikowany ISO 13485 software house, który od 2015 roku buduje produkty medyczne od definicji przeznaczenia, przez projektowanie, inżynierię oprogramowania, aż po certyfikację CE. Zespół 50+ ekspertów specjalizuje się w aplikacjach mobilnych, desktopowych, webowych i chmurowych, zapewniając zgodność ze standardami MDR, IVDR i FDA.

Kiedy rozmawiałem z Przemkiem o AI w healthcare na LinkedIn, jego odpowiedź jest jednoznaczna: “Na szczęście w medycynie to nie jest takie proste. Trudno jest wprowadzić na rynek oprogramowanie medyczne z komponentem AI. Nie mówię, że jest to niemożliwe, ale jest trudne.”

Dlaczego? Bo regulacje medyczne to naturalna fosa, która chroni Obywateli przed Barbarzyńcami. Wypuszczenie jakiegokolwiek softu, który ma spełniać wymagania medyczne, to minimum 2-3 lata procesu certyfikacyjnego. W 95% przypadków to, co nazywamy “AI w healthcare”, nie będzie oprogramowaniem medycznym w ścisłym sensie.

To jest siła Obywatela - jego pozycja jest chroniona przez regulacje, które tworzą barierę wejścia tak wysoką, że większość barbarzyńców nawet nie próbuje atakować.

Imperialista: ekspansja na nowe terytoria

Imperialista to Software House, który ma swoją niszę na głównym rynku i wykorzystuje ją do podbijania nowych segmentów na dojrzałym rynku.

Przykładem takiego Imperialisty jest SOFTIQ. Firma jest ugruntowanym burmistrzem w govtech - ma głęboką ekspertyzę w procesie wygrywania przetargów na systemy govtech zarówno w Polsce, jak i w innych krajach. Gdy pojawiło się tornado AI, SOFTIQ poszedł o krok dalej i stworzył swoje własne IP oparte o AI do usprawniania procesu przetargowego.

Przetargi.io to nie jest po prostu narzędzie AI - to uniwersalne IP, które pozwala SOFTIQ budować “drogi ekspresowe” do nowych segmentów na dojrzałym rynku. Kluczowe jest to, że te nowe rynki mają dojrzały przypadek użycia (pozyskiwanie środków z przetargów). Wszędzie tam, gdzie proces przetargowy ma wartość dla danego klienta biznesowego, SOFTIQ może ekspandować.

To jest siła Imperialisty - wykorzystuje tornado AI do budowania własnego imperium w obszarach dojrzałego rynku, gdzie wcześniej nie rezydował.

Odkrywca: szukanie nieodkrytych lądów

Odkrywca to piąta strategia GTM - patrzenie na mapę świata i próba odnalezienia nieodkrytego lądu.

W książce Moore’a są Explorer (nie motywowany zyskiem, zbiera informacje) i Forty-niner (znalazł złoto, rekrutuje zespół). Mój Odkrywca to coś innego - nie szuka złota (jak Forty-niner), nie tylko zbiera informacje (jak Explorer).

Odkrywca ogląda mapy i widzi “mgłę wojny” - te obszary rynku, gdzie nikt jeszcze nie był, ale gdzie może być olbrzymia nagroda. Odkrywca zbiera środki od różnych obywateli, przedstawia im wizję nowego lądu i budżet na wyprawę w nieznane. Szanse są małe, ale jeśli odkryje nowy teren, nagroda jest olbrzymia.

Odkrywca dopływa do nowego lądu, stawia pierwszy namiot - tworzy proof of concept, który udowadnia, że technologia działa. Zostawia tam pierwszych osadników - pierwsze wdrożenia, które pokazują wartość. Potem wraca do miasta i zdaje relację o sukcesie.

Ten sukces budzi apetyt. Kupcy chcą eksploatować odkryty teren - ludzie nastawieni na zysk i handel, którzy widzą możliwość zarobienia na nowym odkryciu. Imperialiści chcą wykorzystać nowe terytoria do ekspansji. Osadnicy widzą, jak mogą rozbudować miasto. Odkrywca nie eksploatuje odkrycia sam - przygotowuje ekosystem dla innych.

Stripe: Odkrywca, który zmienił płatności

Klasycznym przykładem Odkrywcy jest Stripe. W 2010 roku, gdy Patrick i John Collison zakładali firmę, płatności online były piekłem - każdy bank miał swoje API, każdy kraj swoje regulacje, integracja trwała miesiące. Stripe zobaczył “mgłę wojny” - możliwość stworzenia jednego, prostego API, które działa wszędzie.

Stawił pierwszy namiot - proste API, które deweloper może zintegrować w kilka godzin zamiast miesięcy. Zostawił osadników - pierwsze startupy, które pokazały, że to działa. Wrócił z sukcesem - dokumentacja, która stała się standardem, ekosystem, który przygotował grunt dla tysięcy firm.

Dzisiaj Stripe to nie tylko płatności - to cały ekosystem. Kupcy budują na Stripe aplikacje do zarządzania subskrypcjami, faktury, rozliczenia - ludzie nastawieni na zysk i handel, którzy widzą możliwość zarobienia na odkryciu Stripe. Imperialiści - duże platformy e-commerce - widzą w Stripe sposób na ekspansję na nowe rynki bez budowania własnej infrastruktury płatniczej. Stripe nie dominuje rynku płatności - przygotował grunt, na którym inni budują swoje imperia.

Venloop: mój eksperyment jako Odkrywca

Ja też gram rolę Odkrywcy. Stworzyłem Venloop - technologię smart-vendingu opartą na Medusa.js. Zobaczyłem “mgłę wojny” - możliwość połączenia e-commerce z fizycznymi automatami, gdzie nikt jeszcze nie był na poważnie. To nie jest rynek, który już istnieje - to rynek, który dopiero może się pojawić.

To nie jest odkrywanie miejsca, gdzie AI zrobi rewolucję. Smart-vending to hardware, logistyka, omnichannel. AI się tam przyda, oczywiście - może optymalizować zapasy, przewidywać popyt, personalizować ofertę. Ale nie zrobi rewolucji, bo na koniec dnia wartość leży gdzie indziej - produkt jest po prostu bliżej klienta. Nowego klienta, który może w inny sposób by tego produktu nie odkrył, bo by go nie szukał online. Automat w biurze, na korytarzu, w recepcji - to jest dostępność fizyczna, która otwiera nowe kanały sprzedaży. Co więcej, ponieważ automat jest zintegrowany ze sklepem on-line, klient od razu może przejść do zamawiania danego produktu, którego właśnie doświadczył, prosto do domu.

Zebrałem środki: Change(K)now program (Interreg) dał mi dostęp do ponad 30 partnerów, którzy chcą wdrożyć gospodarkę obiegu zamkniętego w stolicach Państw bałtyckich (Dania, Łotwa, Finlandia, Estonia, Litwa, Niemcy), partnerstwo z NGO z Szczecina, z Fundacją Kupuj Odpowiedzialnie. Mega moc. Stawiłem pierwszy namiot - awaryjnysloik.pl, reverse vending dla żywności, który udowadnia, że technologia działa operacyjnie. Zostawiłem osadników - pierwsze wdrożenia w biurach, które pokazują wartość.

Teraz wracam z sukcesem, który zmienia wszystko. Burmistrz branżowy w e-commerce - wdraża awaryjnysloik.pl, aby transformować swoją organizację w bardziej ekologiczną. To nie jest mały test - to pierwszy goryl branżowy, który korzysta z tej technologii. Napiszę o tym wkrótce.

To zmienia grę. Venloop (czyli technologia na której został zbudowany awaryjnysloik.pl) dzięki temu może ściągnąć uwagę innych imperialistów - duże firmy e-commerce, które widzą:

“Skoro ten burmistrz branżowy korzysta z tej technologii, to może my też powinniśmy rozważyć ten smart-vending?”

To nie jest już eksperyment - to jest proof of concept na skalę, która budzi apetyt.

Aby ułatwić imperialistom, osadnikom i kupcom pracę w nowym terenie wkrótce wydamy na świat open source smart-vending point of sale - Storefront jako przynęta dla deweloperów, closed-source Plugin do vendingów jako fosa kompetencyjna, Hardware Kit obniżający barierę wejścia - to wszystko przygotowuje ekosystem. Budowniczowie Venloop - partnerzy, którzy wraz ze mną w kolejnych ekspedycjach płyną budować nowe budynki dla nowych miast - budują custom solutions. Kupcy widzą możliwość zarobienia na odkryciu. Firmy e-commerce (Imperialiści) widzą nowe terytoria do ekspansji.

To pierwszy artykuł z serii, gdzie będę się dzielił kolejnymi etapami wdrożenia moich własnych narzędzi na sobie. Nie piszę o tym jako teoretyk - piszę jako praktyk, który testuje swoje narzędzia w realnym świecie, z realnymi klientami, z realnymi wyzwaniami.

Odkrywca to strategia pre-tornado. Nie płynie na fali - przygotowuje grunt, na którym fala może się pojawić. To strategia transformacyjna - może zmienić cały rynek, ale nie przez dominację, tylko przez odkrycie i przygotowanie ekosystemu.

Pięć strategii GTM w tornado AI

Te pięć strategii reprezentuje pięć fundamentalnie różnych strategii Go-To-Market w tornado AI gdy Twoja firma usługowa jest na dojrzałym rynku. Każda wymaga innego podejścia, innych sojuszników, innej mentalności.

Strategia Barbarzyńcy: Atak z zewnątrz

Barbarzyńca to strategia GTM oparta na agresji i przełomie. The Momentum nie próbuje grać według reguł healthcare, które poznał pracując z firmami będącymi na dojrzałym rynku - atakuje ten rynek z innej strony. Idzie tam, gdzie “miasto” jest najsłabsze - personalized healthcare, gdzie olbrzymie firmy medyczne nie wykorzystują potencjału danych, które zbieramy o sobie codziennie.

To strategia wysokiego ryzyka, ale też wysokiej nagrody. Barbarzyńca musi być gotowy na długą wojnę, bo “miasto” nie podda się łatwo. Musi mieć głębokie kieszenie i cierpliwość, bo regulacje medyczne to nie są mury, które można przebić jednym uderzeniem.

Podobną strategią GTM działa Piotr Karwatka ze swoim projektem Open Mercato. Piotr atakuje jak Barbarzyńca największe firmy ERP i CRM, tworząc swoisty modularny framework. Coś, co widziałem już nie raz, a jednak Piotr to tworzy. Jaka jest jego unikalna broń barbarzyńcy? Za tym projektem stoi hipoteza, którą bracia Karwatkowie mają od kilku dobrych miesięcy i mówią o niej jawnie na LinkedIn. 80% funkcji Twojego systemu nie jest używane, a płacisz za to krocie. Te 20%, których używasz, możesz napisać od nowa, jeśli faktycznie będziesz miał w rękach narzędzie tak potężne, że możesz z użyciem AI i odpowiedniego podejścia napisać swój system w kilka tygodni. To potężny topór barbarzyńcy, który wyłania się z otchłani (przepaści w terminologii Geoffreya Moore’a, która jest pomiędzy innowatorami a wczesnym rynkiem) i próbuje pokonać pierwszą gwardię w firmach średniego rozmiaru, które zmuszone są do używania kobył ERP/CRM, a wykorzystują z nich tylko malutki fragment.

Strategia Obywatela: Obrona murów

Obywatel to strategia GTM oparta na ochronie status quo. Revolve Healthcare nie musi się martwić o barbarzyńców, bo jego mury są zbudowane z regulacji medycznych. ISO 13485, MDR, IVDR, FDA - to są kamienne, strome mury, które większość barbarzyńców nawet nie próbuje atakować.

To strategia niskiego ryzyka, ale też ograniczonego wzrostu. Obywatel może prosperować w swoim “mieście”, ale ma ograniczone możliwości ekspansji poza jego mury. Może natomiast rozważyć strategię Osadnika bo jako Obywatel jest w centrum miasta i wie jak ono działa. Może używa AI do poprawy swoich wewnętrznych procesów aby świadczyć lepsze usługi.

Strategia Osadnika: Eksploracja nowych ziem

Osadnik bazuje na wypracowanej wiedzy - osadnik poprzez lata mieszkania w “mieście” poznał jak ono funkcjonuje. Ma głębokie zrozumienie procesów, klientów, rynków.

Ale osadnik ma też w sobie odwagę obserwować krytycznie to, gdzie miasto się znajduje. Ma chęć zdobywania nowych terenów. Jest świadom tego, co robią barbarzyńcy i jak miasto, w którym przebywa, może być zaatakowane.

Wybiera drogę wzmacniania miasta. Wykorzystuje to, że z niego wychodzi i namawia obywateli na eksplorację nowych ziem. Korzysta ze sprawdzonych odkryć, obserwuje potyczki barbarzyńców, widzi ich przegrane, ale też zwycięstwa w różnych obszarach.

Osadnik bierze to wszystko i z pragmatycznym wyrachowaniem mówi: “Ja nie jadę na ryzykowną misję. Ja rozpoznałem nowy teren. Ja wiem, co mogę zrobić lepiej. Użyję nowych narzędzi, ale tylko tych sprawdzonych. I pomogę miastu się rozwinąć.”

Upside to idealny przykład osadnika. Firma ma lata doświadczenia w e-commerce, zna ten rynek od podszewki. Widzi, jak AI zmienia inne branże, obserwuje sukcesy i porażki barbarzyńców. Zamiast atakować e-commerce, wzmacnia go - wykorzystuje AI do automatyzacji wprowadzania produktów, pokazując gotowy produkt z realną wartością.

Strategia Imperialisty: Ekspansja na nowe terytoria

Imperialista to strategia GTM oparta na ekspansji. SOFTIQ nie próbuje atakować swojego macierzystego rynku (govtech), ale też nie próbuje rozwijać tego miasta. Zamiast tego ekspanduje na nowe miasta korzystając z wiedzy i narzędzi już zdobytych. Wykorzystuje tornado AI do stworzenia własnego IP, które staje się “drogą ekspresową” do nowych rynków.

To strategia wysokiej wartości, oraz, jeśli dobrze wybierze nowe miasta do podboju - średniego ryzyka. Imperialista musi być gotowy na budowanie nowych kompetencji i relacji w nowych branżach, ale zakłada, że jego narzędzia i wiedza pozwolą mu szybko przekonać mieszkańców nowych miast do współpracy bo przypadek użycia (przetargi) - jest tym obywatelom bardzo dobrze znany.

SOFTIQ to idealny przykład imperialisty. Firma ma ugruntowaną pozycję w govtech, ale wykorzystuje tornado AI do budowania własnego imperium w nowych obszarach rynku - wszędzie tam, gdzie proces przetargowy ma wartość.

Strategia Odkrywcy: Szukanie nieodkrytych lądów

Odkrywca to strategia GTM oparta na eksploracji i przygotowaniu gruntu. Nie szukasz miejsc, gdzie AI zrobi rewolucję - szukasz miejsc, gdzie AI jeszcze przez jakiś czas nie wejdzie, bo to inne obszary. Hardware, logistyka, omnichannel, dostępność fizyczna produktu - tam wartość leży gdzie indziej.

To strategia wysokiego ryzyka, ale też transformacyjna. Odkrywca musi być gotowy na to, że inni będą eksploatować jego odkrycie - to nie jest wada, to jest cel. Odkrywca przygotowuje ekosystem dla innych - Kupcy, Budowniczowie, Imperialiści - ale sam nie dominuje. To strategia pre-tornado - przygotowuje grunt, na którym fala może się pojawić.

Venloop to idealny przykład odkrywcy. Smart-vending to hardware, logistyka, omnichannel - AI się tam przyda, ale nie zrobi rewolucji, bo na koniec dnia produkt jest po prostu bliżej klienta. Nowego klienta, który może w inny sposób by tego produktu nie odkrył.

Więc gdzie gra Twój Software House?

Którą strategią grasz:

• Barbarzyńcy jak The Momentum, który atakuje nowymi technologiami ustabilizowane rynki?

• Osadnika jak Upside, który wykorzystuje swoją wiedzę o “mieście”, aby pomóc mu się rozwinąć?

• Obywatela jak Revolve Healthcare, który ma pozycję chronioną regulacjami?

• Imperialisty jak SOFTIQ, który ekspanduje na nowe terytoria w oderwaniu od miasta, z którego się wywodzi, wykorzystując swoją unikalną i uniwersalną przewagę w przetargach?

• Odkrywcy jak Venloop, który przygotowuje grunt dla innych, odkrywając nowe terytoria i budując ekosystem?

Kiedy używać której strategii?

• Barbarzyńca = gdy widzisz luki w murach miasta czyli dojrzałego rynku, tak jak to widzi The Momentum z personalized healthcare

• Osadnik = gdy masz wiedzę o “mieście” (np. e-commerce) i rozbudowujesz je nowymi narzędziami (np. AI w backoffice)

• Obywatel = gdy masz pozycję chronioną regulacjami (np. medycyna, finanse) i bronisz swoich murów

• Imperialista = gdy masz IP (np. Przetargi.io) i ekspandujesz na nowe dojrzałe rynki (np. budownictwo) wykorzystując swoją unikalną przewagę

• Odkrywca = gdy szukasz miejsc, gdzie AI nie zrobi rewolucji, ale jest wartość w innych obszarach

Nie wiesz jeszcze?

Szybki ruch w 7 dni

Uwaga: To działa dla Barbarzyńcy, Osadnika i Imperialisty. Odkrywca potrzebuje więcej czasu na eksplorację - nie da się odkryć nowego lądu w tydzień. Obywatel już ma pozycję, ale może rozważyć strategię Osadnika, jeśli chce rozbudować miasto.

Zamiast zastanawiać się miesiącami, zrób to:

Dzień 1-2: Nazwij niszę Nie “robicie React Native” ani “jesteście w healthcare”. Nazwij konkretnie: “migracje z Magento dla firm B2B 50-200M EUR obrotu” albo “personalized healthcare dla firm z własnymi danymi pacjentów”.

Dzień 3-4: Zdefiniuj Whole Product Co dokładasz od siebie w tej niszy żeby dojść do 100% sukcesu? Może to własne narzędzie diagnostyczne, może to specyficzna wiedza nt. procesów w tej niszy. Trzy konkretne rzeczy, które sprawiają, że nie jesteście wymienni.

Dzień 5-7: Wskaż 3 pierwsze referencje Nie “jakieś firmy z healthcare”. Trzy konkretne nazwy firm, które chcesz zdobyć w tej niszy. Firmy, które jak je zdobędziesz, reszta rynku powie “o! oni mają X, Y i Z - są burmistrzami w tej niszy”.

Co dalej?

Te strategie to nie akademicka zabawa. To realne wybory, które podejmują firmy w tym momencie. Każda z nich prowadzi do innej gry, innych sojuszników, innych zagrożeń.

Barbarzyńca musi być gotowy na długą wojnę z murami miasta. Osadnik musi cierpliwie budować zaufanie mieszkańców. Obywatel musi strzec swoich murów, bo to jego jedyna ochrona. Imperialista musi odkryć broń uniwersalną, która działa na nowym dojrzałym terytorium. Odkrywca musi być gotowy na to, że inni będą eksploatować jego odkrycie - to nie jest wada, to jest cel.

Nie ma jednej dobrej odpowiedzi. Jest odpowiedź, która pasuje do Twojego DNA, Twoich zasobów, Twojej cierpliwości.

Pytanie brzmi: którą grę faktycznie grasz, a którą MYŚLISZ że grasz?

Bo największy problem, jaki widzę, to firmy usługowe IT, które grają jak barbarzyńcy, mając DNA obywatela. Albo próbują być osadnikami, nie mając pojęcia o “mieście”, z którego rzekomo wychodzą.

• Od “zrobiliśmy i nic” do strategicznego OSS: Problem, Timing i Decydent jako fundament sukcesu

• Nietypowy sposób jak sprawdzić czy dany projekt OSS ma potencjał dla agencji software - po forkach go poznacie

• Jak lęk przed byciem twarzą swojej firmy, ekspertem w danej niszy warunkuje jej strategię?

• Agentic Commerce Protocol - kiedy dwóch Goryli otwiera pusty tron

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.

Dlaczego setki gwiazdek na Github nie przynoszą biznesu

Rozmawiałem ostatnio z SH, który zainwestował sporo czasu w budowanie OSS, zdobyli nawet kilkaset gwiazdek na Github, pojechali na konferencje, ale żadnego biznesu to nie przyniosło. Takich historii jest wiele, za każdym razem słyszę ten sam motyw:

Problem jest w tym, że nie rozumiemy problemu jaki rozwiązujemy naszym narzędziem/projektem. Tak jak to jest z tym newsletterem, jaki problem ja nim rozwiązuję?

Mój cel to pomagać firmom usługowym typu Software House rosnąć, dając gotowe, sprawdzone lekcje z mojej pracy i przemyśleń. Lekcje w różnej formie, czasem narzędzi, artykułów, nawet książek.

Lekcja zatem z takiego działania czyli z tworzenia projektu Open Source jest taka, że nie tworzymy go w dowolnym obszarze tylko musimy naprawdę dobrze zrozumieć kontekst narzędzi i rozwiązań, które są alternatywami.

Przykładowo, jeśli tworzymy narzędzie do optymalizacji zarządzania promptami w systemach agentowych to alternatywą może być prosty panel CRUD, który deweloper generuje w Cursorze w 10 min z promptami w backendzie i pozwala na ich wersjonowanie. To oczywiście przykład i alternatyw tak naprawdę jest dużo więcej, ale wiecie o co mi chodzi.

Zatem problem, który rozwiązujemy i jego otoczenie alternatywnych rozwiązań definiuje to jak kluczowe będzie skorzystanie z Waszej pomocy, jak bardzo unikatowa to będzie wiedza.

Druga kluczowa sprawa to timing.

Nie jest to taka prosta sprawa bo timing jest na dwóch poziomach: Developer Journey oraz Technology Journey (lub inaczej cykl adopcji technologii). Co się kryje pod tymi tajemniczymi pojęciami?

Developer Journey to podróż dewelopera podczas której tworzy kolejne wersje systemu dla danej firmy. Podczas tej podróży występują ciekawe momenty, które są różne w zależności od rozmiaru firmy i jej rodzaju, ale możemy je sprowadzić do takich bardzo prostych:

1. Potrzeba biznesowa - coś z biznesu prowadzi nas do wniosku, że trzeba zbudować nową część systemu. Czasem ta potrzeba pojawia się od strony zespołu technicznego, ale i tak jest argumentowana biznesowo (zaoszczędzimy/przyspieszymy/poprawimy X dzięki temu.)

2. Badanie architektury/technologii - wtedy ktoś techniczny sprawdza czy dana potrzeba może być rozwiązana i jak.

3. Szacunki i budżet. Czasem ten etap jest mocno oddzielony od samej realizacji danego systemu, szczególnie w dużych organizacjach.

4. Budowanie zespołu i rozpoczęcie prac. Tutaj mamy już wiedzę jaki mamy budżet i jaką technologią dany projekt tworzymy i chcemy go rozpocząć realizować.

5. Budowanie systemu i jego dostarczenie na produkcję.

6. Iteracja z rynkiem.

7. Powrót do punktu 0 dla obecnego systemu i tworzenie nowych modułów/wersji.

Jak myślicie, czy firma w etapie 5 będzie tak samo otwarta na współpracę z Agencją Software jak firma w etapie 1, 2 lub 3? z moich obserwacji to przepaść. Jeśli trafiacie do firmy w momencie wyboru technologii to możecie być poproszeni o pomoc w całym procesie szacunków, a potem wytworzenia. Jeśli lądujecie w fazie 4, 5 często firmy już kogoś mają, albo wewnętrznie, albo agencję. Wejście jest arcy-trudne.

Druga sprawa w timingu to Technology Journey/Adoption Cycle. Co to oznacza? jeśli technologia OSS, którą budujesz lub chcesz rozwijać jest we wczesnej fazie rynku np. nie jest jeszcze standardem, a na rynku jest duży gracz, który obecnie ten standard wyznacza, to warto o tym wiedzieć. Co więcej, tych etapów adopcji technologii jest kilka (innowatorzy, wizjonerzy, przepaść, wczesny rynek, kręgielnia, tornado/główny rynek, późny rynek) i zrozumienie gdzie dana kluczowa technologia jest ma kolosalne znaczenie. Jeśli inwestujecie czas i energię w coś niszowego, wcześnie na rynku to jego adopcja będzie trwała długo, bardzo długo. Drugą stroną tej podróży jest technologia, która już dawno jest na tzw. głównym rynku, dajmy na to Erlang, ale niestety nie stała się wiodącym standardem dla wielu nisz, ale raczej jest ciągle wyjątkową technologią do określonego segmentu.

Nie chcę się tutaj za mocno rozpisywać, ale ten przykład jest po to aby pokazać, że:

Natura problemu - biznes czy tech?

Wracając jeszcze do problemu, który dany projekt rozwiązuje to kluczowe jest także to, czy ten problem jest bezpośrednio osób technicznych czy wychodzi od biznesu.

Jeśli wychodzi od biznesu (przykładowo: wkurza ich cennik Stripe i chcą zmienić dlatego zlecają to osobom technicznym aby podały alternatywy) to nawet jeśli stworzyłeś mega super fajne narzędzie adresujące ten problem to osoby techniczne, które dotrą do niego i powiedzą “wow! ta firma jest super” nie kupią tego od Ciebie tylko pójdą do szefa i powiedzą “no jest taki tool, ale kosztuje/nie wiemy jaka jest licencja”. Z dużą dozą szczęścia może się uda, ale często w tym właśnie momencie same osoby techniczne mówią “to może poszukam czegoś darmowego...”.

Budowanie projektów OSS, które są późno w developer journey może mieć jednak swój sens...

Przykładowo w 2015 Mike Grabowski stworzył projekt OSS na React Native, który potem został połączony z React Native core. To sprawiło, że Mike i firma za nim stojąca stała się rozpoznawalna na rynku. Sam projekt OSS stał się akredytacją, dowodem, że Mike i jego zespół są mistrzami w danej technologii. Natomiast to tylko przepustka, taki projekt to coś co pozwala na budowanie marki firmy, która pracuje z największymi graczami na rynku, która jest zapraszana na konferencje. Niestety, sam projekt OSS w takim przypadku będzie tylko i aż - górą lejka marketingowego i z racji wielu tysięcy gwiazdek na Github - darmowym banerem reklamowym do super określonej grupy docelowej.

Taktyka OSS polegająca na pisaniu bardzo popularnych projektów, które nie trafiają wcześnie w Developer Journey, ma sens jeśli poruszamy się w ekosystemie problemów, które dana technologia rozwiązuje dla osób technicznych. Wówczas budowanie w oczach tych liderów reputacji ma sens bo oni są decydentami ekonomicznymi i kolejny problem, dużo wyżej w developer journey, mogą Tobie zlecić, szczególnie jeśli dużo o tym będziesz mówił, pisał, i pomagał tym ludziom.

To kluczowa różnica - zrozumieć źródło problemu i dla kogo go rozwiązujesz. Jeśli jest to decydent technologiczny to wówczas budowa projektów OSS późno w Developers Journey nadal się zwróci bo ten decydent dzięki temu Tobie zaufa.

Dlatego warto stanąć trochę z boku tych swoich prób i zadać sobie pytanie:

Czy faktycznie wiem, w którym momencie, jaki problem i dla kogo rozwiązuję?

jeśli nie, to zapewne zdajesz się na szczęśliwy los... co czasem też się udaje, ale częściej, widzę to z autopsji, prowadzi do efektu, że nawet jak dana Agencja Software dosłownie “siedzi” na kurze znoszącej lub mogącej znosić dla nich złote jajka to nie wie o tym i rozmawia z rynkiem w nieodpowiedni sposób.

Nietypowy sposób jak sprawdzić czy dany projekt OSS ma potencjał dla agencji software - po forkach go poznacie

Ostatnio odkryłem kolejne pokłady wartościowych danych na Github. Forki…

Zapewne większość z Was wie co to jest, ale pośpieszę: deweloperzy robią forka danego projektu OSS, gdy muszą coś z w nim zmienić, coś czego nie da się zrobić nadbudowując kod wokół. W skrócie - dany projekt OSS jest dla nich wystarczająco kompletny aby na nim dalej iść, ale nie wystarczająco gotowy, zatem muszą go dopracować.

Czytając pierwszy wpis, dotyczący Developer Journey można powiedzieć, że gdy deweloper robi forka to już jest w etapie nr 4 czyli patrząc na moją własną wiedzę - za późno aby łatwo skorzystać z pomocy agencji software. Ale czy tak naprawdę jest?

Ten proces decyzyjny, często angażuje osoby z zarządu/kierownictwa ponieważ dopisanie funkcji do projektu, nad którym nie mamy kontroli to ryzyko biznesowe. To powoduje naturalną potrzebę poszukania alternatyw, ale jeśli ich nie ma i pozostaje “dopisać” to jest to idealny moment aby precyzyjnie zbudować swoją ofertę pod ten przypadek. Aby było zabawniej, treść pod tego typu potrzeby jest na wyciągnięcie ręki. Forki mają commity, które zazwyczaj są kopalnią wiedzy nt. tego czego dany projekt OSS nie ma, a powinien mieć.

Przykładowo firma Unyt z Niemiec zrobiła forka Deno, aby mieć pełną kontrolę nad wersją i móc wprowadzać własne poprawki lub usuwać niepotrzebne funkcje bez czekania na zmiany w oficjalnym repozytorium. Pozwala im to utrzymać stabilność i dostosować runtime Deno do integracji z ich własnym ekosystemem (Unyt Land / UIX) oraz wymogów bezpieczeństwa.

Deno to nowoczesne środowisko uruchomieniowe dla JavaScript i TypeScript napisane w Rust, stworzone przez twórcę Node.js – zbudowane na silniku V8, z wbudowanym menedżerem modułów, narzędziami (lint, test, fmt) i silnym modelem bezpieczeństwa opartym na uprawnieniach.

Utrzymanie takiego forka to duży koszt dla organizacji, szczególnie jeśli Twoim kluczowym stackiem technologicznym nie jest Rust. W takiej sytuacji, nawet jeśli firma już sama utrzymuje taki fork, może być żywo zainteresowana Waszą pomocą aby przekazać w Wasze ręce utrzymanie tego modułu. Brzmi jak mały projekt? może... ale jaka będzie marża? czy takich klientów nie jest wielu ? sam projekt Deno jest obecnie sforkowany ponad 5 tysięcy razy...

Co jest natomiast najpiękniejszego w tym podejściu, to fakt, że mamy problemy technologiczne danej firmy na wyciągnięcie ręki, commity w forkach są gotowe do automatycznej analizy przez AI i do przygotowania szytej na miarę oferty/mailingu... jeśli...Wasza firma faktycznie posiada tego typu kompetencje.

Jak lęk przed byciem twarzą swojej firmy, ekspertem w danej niszy warunkuje jej strategię?

Trochę dziwne pytanie prawda? z jednej strony firma to nie jednostka, a jednostka to nie firma. Z drugiej strony, czy to nie jest jedank prawda? szczególnie w małych organizacjach, pomimo, że mogą już być stworzone procesy, zatrudnione osoby na odpowiednie stanowiska to brak tej jednej kluczowej sprawy, która powoduje, że firma jest na równi pochyłej w dół.

We wczesnym rynku (Early Market oraz w Early Majority), technologia nie jest jeszcze sprawdzona. Technologia, którą Twój Software House wprowadza do firmy. Klienci nie kupują wówczas produktu. Kupują wiarę w OSOBĘ, która im ten produkt dostarczy. Dlaczego? Bo ryzyko jest ogromne, technologia może nie działać, wdrożenie może się nie udać, a kariera kupującego jest zagrożona. W tym momencie jedyną walutą jest ZAUFANIE. A zaufanie we wczesnym rynku = zaufanie do osoby, nie do marki firmowej.

The Personal Brand Tax

Co to znaczy? Ktoś z core teamu musi:

• Być twarzą na konferencjach

• Pisać technical thought leadership

• Budować osobisty autorytet w społeczności

• Być rozpoznawalnym jako OSOBA (nie firma)

Unikanie Personal Brand Tax w efekcie oznacza, że Twoja firma powinna się skupić na drugiej połowie Technology Journey (Adoption Cycle).

Pierwsze trzy fazy Technology Journey wymagają zbudowania zaufania, że ktoś dostarczy doświadczenie całego kompletnego rozwiązania. Produkt (technologia) nie jest jeszcze potwierdzona przez wielkie firmy z całego świata, nie ma wielu wdrożeń, dlatego zaufanie w osobę jest tak kluczowe.

Dlaczego o tym piszę dla Agencji Software?

bo od kiedy pamiętam, ten aspekt był źle rozumiany w firmach, w których pracowałem.

Natomiast, nie oznacza to, że firmy, które chcą uniknąć tego typu działań są skazane na przegraną. Znamy przecież wiele z nich, które nie mają jakiegoś wielkego sławnego guru, który promuje się na Linkedin. Przykładowo są firmy, które budują swój model biznesowy w głównym rynku, gdzie jest stabilna technologia np. Microsoft Dynamics i poprzez partnerstwa, relacje, wiedzę ekspercką, która dotyczy konkretnego systemu - stają się idealnym partnerem do działania. Wynika to z tego, że ciężar dowodu, że dana technologia jest warta inwestycji już został przeniesiony na rynek i teraz firmy usługowe, które na głównym rynku wypracowały swoją przewagę wiedzy, wdrożeń, partnerstw mogą z tego korzystać.

Strategiczne rozwidlenie: dwie równoległe rzeczywistości

To prowadzi nas do kluczowego momentu decyzyjnego. Obecność lub brak osoby gotowej zapłacić podatek osobistej marki nie jest drobnym detalem w kampanii marketingowej. To fundamentalny wybór, który dzieli firmy usługowe na dwa równoległe światy z zupełnie innymi zasadami gry.

I nie - nie ma drogi “lepszej” czy “gorszej.” Są po prostu dwie różne rzeczywistości.

Rzeczywistość A: Macie osobę gotową być twarzą

Co wam się otwiera? Właściwie wszystko.

Możecie gonić technologie na dowolnym etapie ich podróży - od wczesnego rynku gdzie jeszcze praktycznie nikt nie wie czy to zadziała, po główny rynek gdzie już jest standard ale możecie zdominować konkretną niszę. Wasz wybór zależy tylko od apetytu na ryzyko, kapitału który macie i cierpliwości.

Najbardziej lukratywne ścieżki (ale też najbardziej wymagające):

Tornado we wczesnym rynku - technologie które dopiero zyskują błogosławieństwo wielkich firm. Luka talentów jest ogromna bo popyt znacznie przekracza podaż. Tron goryla usługowego jest pusty albo słabo obsadzony.

Dzisiaj takie miejsca to przykładowo Rust dla infrastruktury krytycznej, Temporal dla budowania niezawodnych systemów rozproszonych, Polars dla przetwarzania danych.

Jak to wygląda w praktyce? Wasza osoba-twarz staje się częścią społeczności, buduje autorytet przez wkład do rdzenia projektu, występuje na konferencjach, pisze artykuły techniczne. Klienci kupują dostęp do tej osoby i jej zespołu. Nie kupują “firmy która robi X” tylko “dostęp do eksperta Y który pomoże nam przeżyć.”

Marże? Najwyższe możliwe. Premium za wiedzę której praktycznie nikt inny nie ma.

Ale ryzyko też najwyższe. Technologia może nie wejść na główny rynek, tornado może w ogóle nie nastąpić. A nawet jeśli nastąpi to czas do pierwszych klientów to spokojnie 12-24 miesiące budowania autorytetu. I co najważniejsze - ta osoba-twarz musi pozostać związana z firmą przez lata. Gdy Mike Grabowski sprzedał CallStack, musiał zostać w zarządzie. Dlaczego? Bo ON BYŁ produktem. Bez niego firma traci główny asset.

Zbywalność takiej firmy na początku wzrostu? Niska. To jest trade-off.

Kręgielnia - technologia już na głównym rynku ale możecie dominować kolejne nisze. Tutaj jest ciekawie bo początkowo personal brand jest kluczowy do zdobycia pierwszych 3-5 nisz. Ale stopniowo, gdy macie już 20-30 studiów przypadków, brand firmowy zaczyna przejmować ciężar dowodu. Osobisty autorytet otwiera drzwi, portfolio je zamyka.

I w tym modelu da się zrobić przejście. Po kilku latach osoba-twarz może zejść z pierwszego planu, a firma funkcjonować na brandzie firmowym.

Rzeczywistość B: Nikt nie chce być twarzą

Co wam zostaje?

Automatycznie musicie pominąć wczesne etapy rynku. Nie możecie gonić tornado, które dopiero się zaczyna. Musicie skupić się na technologiach, które już weszły na główny rynek albo są w jego drugiej połowie.

Brzmi jak porażka? Wcale nie.

To jest po prostu inne pole bitwy z innymi zasadami.

Główny rynek + specjalizacja branżowa - bierzecie sprawdzone, dojrzałe technologie i dodajecie głęboką wiedzę o konkretnej branży albo procesie.

Przykład? Wdrożenia systemów dla konkretnego przemysłu. Nie musicie być gwiazdami open source. Musicie rozumieć procesy klienta lepiej niż on sam. Brand firmowy budujecie przez portfolio przypadków, metodyki wdrożeniowe, certyfikaty. Klienci kupują sprawdzone procesy i referencje, nie wiarę w guru.

Marże? Średnie do wysokich, zależnie od poziomu specjalizacji branżowej.

Ryzyko? Niskie. Technologia sprawdzona, rynek istnieje, popyt przewidywalny.

Czas do pierwszych klientów? 3-6 miesięcy. Znacznie szybciej niż w tornadzie bo nie musicie budować autorytetu od zera - technologia już jest znana.

Zbywalność firmy? Wysoka. Brand firmowy, metodyki, portfolio - wszystko transferowalne. Nie jesteście zależni od jednej osoby.

Strategia Produkt Plus Jeden - bierzecie dojrzały projekt open-source i rozszerzacie go o brakujący element dla konkretnej niszy. Produkt/platforma staje się marką, nie osoba.

Przykład? Platforma handlu międzyfirmowego zbudowana na dojrzałym silniku. Marketing skupia się na produkcie i jego wartości biznesowej - ile oszczędza czasu, ile redukuje kosztów. Nie na tym kto to zrobił.

Marże? Wysokie. Produkt daje przewagę, możecie dyktować ceny przez wartość biznesową którą dostarczacie.

Czas do rynku? 6-12 miesięcy. Musicie najpierw zbudować ten produkt, potem go sprzedawać.

Zbywalność? Bardzo wysoka. Produkt jest głównym aktywem, nie osoba.

Model partnerski - stajecie się certyfikowanym partnerem dużego dostawcy technologii. Wykorzystujecie ich markę jako zastępcze zaufanie.

Tutaj jest elegancko bo błogosławieństwo od dużego dostawcy (Microsoft, Shopware, ktokolwiek) zastępuje wasz osobisty autorytet. Oni przynoszą początkowe zaufanie, wy budujesz na tym przez portfolio i metodyki firmowe.

Marże? Średnie, często dostawca ma swoje wyobrażenia o poziomie cen.

Ryzyko? Niskie. Dostawca przynosi leady, wy dostarczacie wykonanie.

Czas do klientów? 3-6 miesięcy, często szybciej bo leadsy płyną od vendora.

Które etapy rynku eliminuje brak osoby-twarzy?

Wczesny rynek i przepaść - całkowicie. Tu nie ma dyskusji. Bez zaufania osobistego nie przekonasz pierwszego pragmatycznego klienta że warto zaryzykować. To jest po prostu niemożliwe.

Kręgielnia (pierwsze 5-10 nisz) - bardzo trudne ale nie niemożliwe. Jeśli idziesz modelem partnerskim gdzie dostawca technologii przynosi initial trust, da się. Ale samodzielnie? Arcy trudne.

Kręgielnia (nisze 10-30) - już możliwe. Gdy macie mocne portfolio firmowe, osobisty brand przestaje być konieczny. Case studies mówią za was.

Tornado - możliwe ale z handicapem. Możecie wygrać pozycję drugą albo trzecią na rynku. Trudniej o pozycję numer jeden (goryl) bo tam osobiste zaufanie nadal dużo znaczy. Ale bycie drugim czy trzecim wcale nie jest złe... czasem nawet lepsze niż bycie pierwszym jeśli chodzi o marże względem wysiłku.

Główny rynek - tutaj wręcz może być lepiej bez osobistego brandu. Klienci kupują na podstawie procesów, portfolio, SLA, metodyk. Osobisty brand może być nawet postrzegany jako ryzyko (”a co jak ta osoba odejdzie?”).

To nie ograniczenie. To klaryfikacja.

Lęk przed byciem twarzą nie eliminuje szans na zbudowanie silnika wzrostu, ale całkowicie dyktuje KTÓRY silnik możecie wybrać. Rezygnujecie z szansy na spektakularny wzrost napędzany tornadem (CallStack przeszedł drogę od zera do sprzedaży za setki milionów w 8 lat).

Ale zyskujecie:

• Większą stabilność (sprawdzone technologie, nie eksperymenty)

• Lepszą powtarzalność (jasne wzorce, dostępne narzędzia, dojrzały ekosystem)

• Możliwość zbudowania firmy która może funkcjonować bez was (brand firmowy, nie osobisty)

• Szybsze pierwsze przychody (3-6 miesięcy vs 12-24)

Oba wybory są dobre.Ale tylko jeden jest WASZ.

Cztery pytania które rozstrzygają

Jeśli odpowiecie “nie” na którekolwiek z tych pytań, rzeczywistość A (wczesny rynek, tornado hunting) jest dla was zamknięta:

1. Czy macie w core teamie kogoś kto CHCE być rozpoznawalny jako ekspert w społeczności?

2. Czy ta osoba jest gotowa poświęcić 20-30% czasu na konferencje, artykuły, budowanie obecności publicznej?

3. Czy możecie zaakceptować że przez pierwsze 6-12 miesięcy ten wkład nie przyniesie bezpośrednich klientów?

4. Czy możecie zagwarantować, że ta osoba zostanie w firmie przez najbliższe 3-5 lat minimum?

Choć jedno “nie”? Idźcie rzeczywistością B.

Nie dlatego że jest gorsza. Dlatego że pasuje do tego kim jesteście. A dopasowanie strategii do DNA to różnica między latami walki w czerwonym oceanie gdzie każdy projekt to bitwa o stawkę, a spokojnym budowaniem przewagi w niszy gdzie klienci przychodzą bo wiedzą że jesteście najlepsi w tym co robicie.

Pytanie brzmi: w której rzeczywistości żyjecie?

Test Tornada w praktyce: Agentic Commerce Protocol - kiedy dwóch Goryli otwiera pusty tron

W poprzednich numerach pokazałem wam fundamenty: jak zdiagnozować DNA swojej firmy (#7), jak działa anatomia Tornada (#8), a dzisiaj - strategiczne wymiary wyboru OSS przez pryzmat Problemu, Timingu i Decydenta. Teraz połączmy to wszystko w jedną, praktyczną analizę projektu, który pojawił się zaledwie kilka dni temu i może zdefiniować następną dekadę e-commerce.

Kilka dni temu OpenAI i Stripe wypuściły wspólnie coś pozornie niewielkiego: Agentic Commerce Protocol. Open source. Apache 2.0 license. Już 640 gwiazdek i 68 forków.

Pozornie to tylko kolejny protokół. Ale gdy spojrzysz przez pryzmat wszystkiego co napisałem w tym numerze - Problem, Timing, Decydent, Personal Brand Tax - nagle widzisz coś innego. Widzisz coś co się zdarza raz na kilka lat: moment gdy dwóch gigantów otwiera nową kategorię i zostawia pusty tron dla kogoś innego.

Co właściwie się wydarzyło?

Wyobraź sobie scenariusz:

jesteś CTO średniej wielkości firmy e-commerce. Sprzedajecie ubrania sportowe. Dobrze wam idzie, ale ostatnio coraz częściej słyszysz o konkurencji, która “zintegrowała AI agents” z zakupami. Klienci mogą powiedzieć ChatGPT “kup mi buty do biegania, budżet 500 zł” i transakcja się dzieje. Bez przechodzenia na stronę, bez formularzy, bez friction.

Masz problem. Jasny, naglący problem biznesowy. Pytasz swojego Head of Engineering: “czy możemy to zrobić?”. On kiwa głową, ale mówi “musimy to zaprojektować od zera. Integracja z OpenAI, bezpieczne przekazywanie tokenów płatniczych, inventory management w czasie rzeczywistym, obsługa błędów... to może być pół roku pracy.”

Pół roku. Konkurencja już to ma. Nie możesz czekać.

I właśnie w tym momencie OpenAI i Stripe pokazują wam Agentic Commerce Protocol. Otwarty standard. Gotowe wzorce integracji. Referencyjne implementacje. Dokumentacja. To co miało być pół roku staje się trzema tygodniami.

To jest problem który ACP rozwiązuje. Nie jest to akademicki protokół stworzony w próżni. To jest odpowiedź na konkretny, palący ból tysięcy firm, które widzą jak rynek się zmienia i boją się zostać w tyle.

Dlaczego akurat teraz? Timing tej decyzji

Pamiętasz Developer Journey z pierwszego rozdziału? Te sześć etapów przez które przechodzi każda firma budując nowy system? Agentic Commerce Protocol trafia w najbardziej złoty moment jaki można sobie wyobrazić.

Firma jest w etapie zero lub jeden. Potrzeba biznesowa dopiero się pojawiła (”musimy mieć agentic commerce”) i lider technologiczny dopiero zaczyna badać jak to zrobić. Zespół deweloperski jeszcze nie dostał zadania “naucz się tego”. Budżet jeszcze nie został wydany. Architektura jeszcze nie została wybrana.

To jest moment maksymalnej otwartości na zewnętrzną pomoc. To jest moment gdy firma desperacko szuka kogoś kto już to zrobił, kto wie jak to zaprojektować, kto może ich przeprowadzić przez ten wybór.

Porównaj to z narzędziami deweloperskimi typu Cursor czy Claude Code, które analizowaliśmy wcześniej. Tam firma ma już zespół. Mówi im “nauczcie się tego narzędzia” i załatwione. Potrzebują może szkolenia, ale nie potrzebują agencji software która zbuduje im system.

Tutaj jest zupełnie inaczej. Tutaj potrzebują was. Na full projekt. Na arhitectural design. Na długoterminowe wsparcie. To nie jest szkolenie. To jest fundament ich następnej generacji systemu e-commerce.

Kto faktycznie podejmuje tę decyzję?

W pierwszym rozdziale pisałem o tym jak kluczowe jest zrozumienie nie tylko problemu i timingu, ale też kto jest decydentem ekonomicznym. Kto faktycznie powie “tak, robimy to” i podpisze budżet.

Inicjatorem jest zazwyczaj ktoś z biznesu. Head of E-commerce który wraca z konferencji i mówi “konkurencja właśnie pokazała że ich klienci mogą kupować przez ChatGPT, a my nawet nie zaczęliśmy o tym myśleć.” Albo CEO który czyta raport pokazujący że 40% ich “target audience” używa już AI assistants do researchu produktów.

Oni idą do CTO z pytaniem: “czy możemy to zrobić? ile to kosztuje? jak długo to potrwa?”. CTO musi nagle stać się ekspertem w czymś co jeszcze tydzień temu nie istniało jako kategoria. Patrzy na Agentic Commerce Protocol i widzi że OpenAI i Stripe już rozwiązali połowę problemów. Idzie z tym z powrotem do CEO i mówi “tak, możemy, ale potrzebujemy kogoś kto już to robił.”

Tutaj wchodzisz ty.

Ale żeby dostać ten kontrakt musisz przejść jeszcze przez jednego strażnika: Head of Security/Legal/Compliance. Oni mają prawo veta. Mogą zabić projekt jednym zdaniem: “to nie spełnia naszych wymogów compliance.” Ale tutaj masz przewagę. Bo Stripe jest maintainerem protokołu. A Stripe to firma której każdy payment team ufa. To jest twoja przepustka przez tę bramę.

Widzisz jak wszystkie elementy układają się w historię? Problem jest realny i naglący. Timing jest idealny - wczesny etap Developer Journey. Decydent jest jasny - biznes inicjuje, tech zatwierda, payment team nie blokuje. To jest recepta na wysokomarżowy, strategiczny projekt.

Czy to rewolucja czy tylko nowy sposób robienia starego?

Żeby zrozumieć dlaczego Agentic Commerce Protocol to przełom, a nie ewolucja, musimy cofnąć się o krok i zobaczyć jak do tej pory firmy próbowały rozwiązać problem integracji AI z e-commerce.

Metoda pierwsza: każdy budował to od zera. Custom integracja z API OpenAI, własny system do zarządzania sesją konwersacji, własny protokół do bezpiecznego przekazywania danych płatności między AI a backendem e-commerce. Efekt? Każda firma rozwiązywała te same problemy. Bezpieczeństwo. Prywatność. Inventory synchronization. Error handling. Setki zespołów pisały ten sam kod, każdy na swój sposób, każdy popełniając te same błędy.

To przypomina lata przed pojawieniem się standardów płatności online. Każdy sklep robił własną integrację z bankiem. Chaos. Wysoki koszt. Wysokie ryzyko.

Agentic Commerce Protocol zmienia to fundamentalnie. To nie jest “API do integracji z ChatGPT”. To jest otwarty standard który definiuje jak AI agents, firmy e-commerce i payment providers rozmawiają ze sobą. Niezależnie od tego czy używasz OpenAI, Anthropica, czy własnego modelu - protokół jest ten sam. Niezależnie od tego czy płatności obsługuje Stripe, Adyen czy ktoś inny - protokół jest ten sam.

Zmienia to ekonomię całego rynku. Nagle integracja która kosztowała pół roku i dziesiątki tysięcy dolarów staje się tygodniem pracy i kilkoma tysiącami. Ale co ważniejsze - zmienia to kto wygrywa. Bo zwycięzcą nie jest już ten kto pierwszy zbudował integrację. Zwycięzcą jest ten kto najlepiej rozumie biznes klienta i potrafi najszybciej dostarczyć kompletne rozwiązanie używając standardu.

To jest dokładnie ten sam moment co pojawienie się React Native w świecie mobile. Przed React Native trzeba było mieć dwa zespoły, dwie bazy kodu, podwójny czas developmentu. Pojawienie się React Native zmieniło zasady gry. Nagle liczyło się kto najlepiej rozumiał cross-platform architecture i potrafił dostarczyć aplikację na obie platformy szybciej niż konkurencja.

Pamiętasz Callstack z numeru 6? Oni nie byli pierwszymi którzy używali React Native. Ale stali się Gorylem Usługowym bo jako pierwsi zbudowali kompletną ofertę wokół tej technologii. Mieli metodyki, wzorce, case studies, technical thought leadership.

Teraz masz dokładnie taki sam moment z Agentic Commerce Protocol. Nie musisz być pierwszym który go użył. Musisz być pierwszym który zbuduje wokół niego kompletną, powtarzalną ofertę dla określonej niszy.

Jak głęboka jest prawdziwa fosa kompetencyjna?

Tutaj musisz być bardzo ostrożny. Bo na pierwszy rzut oka Agentic Commerce Protocol wygląda prosto. Dokumentacja jest przystępna. OpenAPI spec jest czytelny. Stripe i OpenAI mają referencyjne implementacje. Junior developer może w weekend zbudować demo które działa.

I to jest właśnie pułapka.

Bo demo to nie produkcja. A produkcja w e-commerce to zupełnie inny poziom złożoności. To tutaj zaczyna się prawdziwa fosa.

Pomyśl o rzeczywistych pytaniach które zadaje klient: “Co się stanie gdy AI agent złoży zamówienie ale inventory zmieni się w między czasie? Jak obsługujemy zwroty inicjowane przez AI? Jak robimy A/B testing konwersji gdy transakcja dzieje się poza naszą stroną? Jak integrujemy to z naszym CRM? Jak śledzimy customer journey który zaczyna się w ChatGPT a kończy w naszym magazynie? Jak zapewniamy compliance z GDPR gdy dane płyną przez trzech pośredników?”

To nie są akademickie pytania. To są pytania które decydują czy projekt się uda czy nie. I tu jest właśnie miejsce gdzie większość firm się zatrzymuje. Zrobili demo. Pokazali że “działa”. A potem zderzają się z rzeczywistością produkcji i okazuje się że nie mają pojęcia jak rozwiązać te problemy.

Ty jako Software House możesz być tym który te problemy już rozwiązał. Nie dla wszystkich branż - to byłby błąd. Ale dla jednej konkretnej niszy. Dla fashion e-commerce. Albo dla home decor. Albo dla B2B industrial supplies. Wybierz jedną niszę i stań się niekwestionowanym ekspertem który wie jak zaimplementować ACP w tej konkretnej branży, z jej specyficznymi wymogami, z jej specyficznymi workflow, z jej specyficznymi problemami.

To nie jest fosa technologiczna jak w przypadku Rust, gdzie sam język jest barierą. To jest fosa domenowa - kombinacja zrozumienia protokołu plus głęboka wiedza o konkretnej niszy biznesowej. I to jest właśnie typ fosy który pozwala na premium marże bez wymuszania na tobie bycia gwiazdą konferencji technologicznych.

Jak szerokie może być to tornado?

To jest kluczowe pytanie strategiczne. Bo możesz znaleźć idealną technologię, idealny timing, ale jeśli rynek jest za mały to nigdy nie zbudujesz Goryla Usługowego. Zostaniesz wysokomarżowym butikiem - co nie jest złe, ale to nie jest Goryl.

Z Agentic Commerce Protocol mamy ciekawą sytuację. Problem który rozwiązuje - integracja AI agents z transakcjami - jest uniwersalny dla praktycznie każdej firmy która sprzedaje cokolwiek online. Fashion, electronics, home decor, B2B supplies, digital products, subscriptions, tickets. Każda z tych branż prędzej czy później będzie musiała zintegrować agentic commerce.

To jest ogromny, horyzontalny rynek. Setki tysięcy firm e-commerce na świecie. Ale tutaj pojawia się kluczowe rozwidlenie strategiczne.

Możesz próbować być generalistą - “robimy agentic commerce dla każdego”. To prowadzi prosto do walki cenowej. Bo każdy inny Software House może powiedzieć to samo. Nie masz przewagi. Nie masz fosy. Konkurujesz na Upwork z zespołami które zrobią to taniej.

Albo możesz wybrać jedną niszę wertykalną i stać się jej niepodważalnym ekspertem.

Nagle nie konkurujesz z setkami agencji. Konkurujesz z może trzema, czterema które też wybrały tę niszę. A jeśli będziesz pierwszy który zdobędzie referencje od Gucciego, Prady, czy chociaż mniejszych premium brandów - stajesz się oczywistym wyborem dla każdego kolejnego.

Szerokość potencjalnego tornado jest więc gigantyczna - każda firma e-commerce. Ale twoja strategia musi być wąska - jedna konkretna nisza. To jest klasyczna Kręgielnia opisana przez Geoffrey’a Moore’a. Zdobywasz jeden kręgiel (premium fashion), potem kolejny logicznie powiązany (luxury accessories), potem kolejny (high-end home decor). Nisza po niszy, budując portfolio referencji i ekspertyzy.

Błąd który widzę w większości Software House’ów to próba zdobycia wszystkich kręgielni naraz. To prowadzi do rozmycia ekspertyzy, braku referencji w jakiejkolwiek niszy, i w efekcie - walki cenowej.

Gdy dwóch Goryli otwiera rynek

Teraz najważniejsze pytanie: czy rynek jest gotowy? Czy pragmatycy - te duże, ostrożne firmy które stanowią większość rynku - zaczną wdrażać agentic commerce?

Odpowiedź leży w tym kto za tym projektem stoi. I tutaj mamy coś niezwykłego.

OpenAI i Stripe. Razem. Jako współmaintainerzy otwartego standardu.

Pomyśl co to oznacza dla CTO który musi sprzedać ten projekt swojemu CEO. “Chcę zainwestować ćwierć miliona dolarów w nową, nieprzetestowaną technologię.” CEO pyta: “kto za tym stoi?”. CTO odpowiada: “OpenAI - lider w AI - i Stripe - lider w płatnościach. Razem stworzyli otwarty standard.”

To jest błogosławieństwo z absolutnego szczytu piramidy. Nie ma silniejszego sygnału dla pragmatycznego rynku. To nie jest startup z Doliny Krzemowej który za rok może nie istnieć. To są dwa Goryle, każdy w swojej domenie, które mówią: “to jest standard przyszłości, budujcie na nim.”

Pamiętasz z numeru 8 jak opisywałem rolę Goryli w uruchamianiu Tornada? Pragmatycy czekają na sygnał że technologia jest bezpieczna. Ten sygnał może przyjść tylko od kogoś kto ma ich bezwarunkowe zaufanie. W przypadku AI agents to OpenAI. W przypadku płatności to Stripe. Gdy ci dwaj mówią razem - wahanie znika.

I tu jest właśnie twoja szansa. Bo Goryle otworzyły rynek, ale nie będą go obsługiwać. OpenAI nie zbuduje implementacji dla każdej branży e-commerce. Stripe nie stworzy portfolio studiów przypadku dla fashion, electronics, B2B. Oni zbudowali infrastrukturę. Stworzyli standard. Ale zostawili przestrzeń - ogromną, lukratywną przestrzeń - dla Goryla Usługowego który będzie implementował ten standard dla konkretnych nisz.

Gdzie dokładnie jesteśmy teraz? Timing jest wszystkim

Wiesz już że problem jest realny, że dwóch Goryli go zatwierdza, że szerokość rynku jest ogromna. Ale to wszystko nic nie znaczy jeśli jesteś za wcześnie albo za późno.

Za wcześnie - to są lata samotnej pracy bez klientów, próby edukacji rynku który jeszcze nie jest gotowy słuchać. Za późno - to są lata walki z ugruntowaną konkurencją która już zajęła wszystkie dobre pozycje.

Z Agentic Commerce Protocol jesteśmy w idealnym momencie. Projekt jest w statusie “draft”. To znaczy że standard jeszcze się formuje, jeszcze nie jest wykuty w betonie. Możesz wpływać na jego kształt. Możesz być częścią dyskusji. Już jest 68 forków - to sygnał że ludzie eksperymentują, testują, próbują zrozumieć jak to zastosować w swoich kontekstach. Ale jeszcze nie ma masowej adopcji. Jeszcze nie ma setki agencji które mówią “jesteśmy ekspertami od ACP.”

To jest klasyczna faza którą Geoffrey Moore nazywa “early bowling alley” - jest kilka pierwszych kręgielni które zostały zdobyte (OpenAI i Stripe mają swoje implementacje), ale większość kręgielni wciąż stoi nietknięta. Rynek widzi że coś się dzieje. FOMO zaczyna się budować. Ale większość wciąż czeka - czeka na sygnał że to bezpieczne, czeka na referencje, czeka na kogoś kto powie “my to już wdrożyliśmy i działa.”

Ty możesz być tym kimś. Nie dla całego rynku - to niemożliwe. Ale dla jednej niszy. Dla premium fashion możesz być pierwszym który ma study case, który ma working implementation, który pokazuje ROI. I wtedy każdy kolejny brand w tej niszy przyjdzie do ciebie bo jesteś oczywistym, bezpiecznym wyborem.

Tornado jeszcze nie nastąpiło. Ale fronty atmosferyczne już się zbierają. Presja rośnie. Każdy CEO w e-commerce czyta te same artykuły o AI agents transformujących retail. Każdy CTO wie że musi coś z tym zrobić. Brakuje tylko tego jednego elementu - kompletnej, sprawdzonej oferty usług wokół standardu.

To może być twoja oferta. Ale okno jest ograniczone czasowo. Za sześć miesięcy będzie pięć innych agencji które próbują to samo. Za rok będzie dwadzieścia. Za dwa lata jeden z nich będzie Gorylem a reszta będzie walczyć o resztki. Pytanie brzmi: czy będziesz tym Gorylem?

Czy tron usługowy jest zajęty?

Spojrzałem na ekosystem wokół Agentic Commerce Protocol szukając tego samego co zawsze - czy jest już ktoś kto ma niepodważalną pozycję? Kto jest Gorylem Usługowym dla ACP?

Odpowiedź jest prosta i brutalna: nie ma nikogo.

Jest kilka agencji które już mają pierwsze projekty z AI agents w commerce. Ale żadna z nich nie skupiła się wyłącznie na ACP. Żadna nie ma portfolio studiów przypadku pokazujących “tak wdrażamy ACP w różnych niszach.” Żadna nie ma publicznych contributions do standardu które budowałyby ich autorytet. Żadna nie mówi głośno “jesteśmy THE ekspertami od Agentic Commerce Protocol.”

Tron jest pusty. Kompletnie, totalnie pusty.

Ale nie zostanie pusty długo. Protokół jest za atrakcyjny, backing jest za mocny, timing jest za dobry. Ktoś ten tron zajmie. Pytanie tylko kto i kiedy.

I tu jest właśnie przewaga działania teraz, szybko, zdecydowanie. Nie musisz być najlepszym technicznie. Nie musisz mieć największego zespołu. Musisz być pierwszym który powie głośno “to jest nasza specjalizacja” i który zbuduje portfolio referencji szybciej niż konkurencja zdąży zareagować.

Personal Brand Tax - ile musisz zapłacić?

Wróćmy do kluczowego pytania z trzeciego rozdziału: czy Agentic Commerce Protocol wymaga od ciebie bycia twarzą? Czy musisz stać się tym ekspertem który jest na każdej konferencji, który pisze technical blog, który kontrybuuje do core projektu?

Odpowiedź jest subtelna i bardzo ważna: to zależy którą ścieżkę wybierzesz.

Pamiętasz dwa archetypy z numeru 7? Architekt Principal i Ekspert Domenowy? Ten wybór tutaj ma fundamentalne znaczenie.

Jeśli chcesz iść ścieżką Architekta Principal - być ekspertem od samej technologii, od samego protokołu - wówczas Personal Brand Tax jest WYSOKI. Musisz być rozpoznawalny w community. Musisz kontrybuować do projektu. Musisz być tym do którego przychodzą z technicznymi pytaniami o edge cases w protokole. To wymaga czasu, obecności, konsystencji. To wymaga osoby która CHCE być tą twarzą.

Ale jest druga ścieżka. Ścieżka Eksperta Domenowego. I tu jest piękno tego przypadku.

Możesz być ekspertem nie od protokołu, ale od niszy biznesowej. “Najlepsi w agentic commerce dla premium fashion brands.” Twój Personal Brand Tax jest wtedy ŚREDNI, nie WYSOKI. Nie musisz kontrybuować do ACP. Nie musisz być na konferencjach technicznych. Musisz być ekspertem w swojej niszy biznesowej - fashion e-commerce. Musisz rozumieć ich problemy, ich workflow, ich customer journey, ich specifics.

ACP jest wtedy narzędziem które używasz, ale nie jesteś od niego ekspertem. Jesteś ekspertem od rozwiązywania problemów premium fashion brands, a ACP to po prostu najlepsze narzędzie do tego celu w 2025 roku.

Ta różnica jest kluczowa. Bo większość Software House’ów nie ma osoby która chce i może zapłacić wysoki Personal Brand Tax. Nie ma kogoś kto chce być gwiazdą technologii. Ale większość ma kogoś kto może stać się ekspertem w określonej niszy biznesowej. To wymaga innego typu wiedzy, innego typu pracy, ale jest osiągalne dla znacznie szerszego grona firm.

I tu jest właśnie magia Agentic Commerce Protocol. To nie jest czysto technologiczny przełom jak Rust czy Temporal. To jest przełom który łączy technologię z biznesem. Możesz wygrać koncentrując się na którejkolwiek ze stron - albo na technologii (wysoki Personal Brand Tax), albo na biznesie (średni Personal Brand Tax).

Ale musisz wybrać. Nie możesz być “trochę ekspertem od ACP i trochę ekspertem od fashion.” Musisz wybrać jedną ścieżkę i na niej zbudować swoją pozycję.

Które pytania musisz sobie zadać?

Jeśli wybierasz ścieżkę technologiczną (Architekt Principal):

• Czy masz kogoś kto CHCE być rozpoznawalny jako ekspert od ACP?

• Czy ta osoba może poświęcić 20-30% czasu na community, content, contributions?

• Czy możesz przetrwać 6-12 miesięcy budując autorytet zanim przyjdą pierwsi klienci?

Jeśli wybierasz ścieżkę biznesową (Ekspert Domenowy):

• Czy możesz wybrać JEDNĄ niszę i skupić się tylko na niej przez najbliższe 12-24 miesiące?

• Czy macie kogoś kto rozumie (albo może się nauczyć) tę niszę biznesową bardzo głęboko?

• Czy możecie zbudować case study w tej niszy nawet jeśli pierwszy projekt będzie “po kosztach”?

Żadna ścieżka nie jest lepsza. Ale żadna nie jest też łatwa. Wybierz tę która pasuje do tego kim jesteście jako firma.

Analiza Forków - za wcześnie na prawdziwe sygnały

Protokół został opublikowany 28 września 2025 - to zaledwie 10 dni temu. Za wcześnie żeby forki pokazywały prawdziwe sygnały adopcji. Obecne 68 forków to głównie:

• Zespół Stripe - pracuje nad przykładami implementacji

• Zespół OpenAI - buduje reference implementations

• Wczesni adoptatorzy - eksperymentują z protokołem

To nie są jeszcze sygnały “produkcyjnej adopcji” które pokazałem w numerze 8. To są sygnały “wczesnego eksperymentowania” - co jest normalne i oczekiwane dla technologii która ma 10 dni.

Ale jest coś znacznie ważniejszego niż forki.

Spójrz na 8 issues w repozytorium. Dużo z nich dotyka konkretnych problemów biznesowych:

• “Support for Restaurant/Food Ordering Use Cases”

• “Add Subscription & Recurring Payment Support”

• “Pickup fulfillment option”

• “Merchant UI Customization”

To nie są pytania techniczne typu “jak zaimplementować X w protokole.” To są pytania biznesowe typu “jak rozwiązać problem Y w mojej branży.”

I tu jest złota żyła dla Software House’ów. Te issues to idealne źródło wiedzy o tym czego rynek naprawdę potrzebuje. Każdy issue to sygnał że ktoś ma konkretny problem biznesowy i szuka rozwiązania. To są twoi przyszli klienci, którzy już teraz mówią ci czego potrzebują.

I tu jest kluczowa różnica. W tradycyjnych projektach OSS (jak React, Vue, Angular) issues to głównie:

• Bug reports

• Feature requests techniczne

• Performance improvements

• API design discussions

W ACP issues to głównie:

• “Jak wdrożyć to w mojej branży?”

• “Czy protokół obsługuje mój use case?”

• “Jakie są best practices dla mojego typu biznesu?”

To potwierdza dokładnie to co napisałem wcześniej - ACP to nie jest przełom technologiczny, to jest przełom biznesowy.

Ludzie nie pytają “czy to działa?” - pytają “czy to rozwiąże mój problem biznesowy?” To jest fundamentalna różnica która pokazuje że rynek jest gotowy na rozwiązanie, nie na technologię.

Za 6 miesięcy będziemy mogli przeanalizować prawdziwe forki - te które pokażą kto rzeczywiście wdraża ACP w produkcji, jakie problemy napotykają, jakie features dodają. Wtedy będziemy mieli prawdziwe sygnały adopcji.

Ale już teraz mamy sygnał że rynek ma problem który ACP rozwiązuje. I to jest znacznie ważniejsze niż forki.

Podsumowanie: czy to jest twoja szansa?

Przeczytałeś właśnie pełną analizę Agentic Commerce Protocol przez pryzmat wszystkich wymiarów które pokazałem w tym numerze i w poprzednich.

Problem? Realny, naglący, dotyka tysięcy firm które widzą jak ich konkurencja wdraża AI agents.

Timing? Idealny. Developer Journey etap 1-2, protokół w draft status, rynek czeka na sygnał że to bezpieczne.

Decydent? Jasny. Biznes inicjuje, tech weryfikuje, payment team nie blokuje bo Stripe daje confidence.

Błogosławieństwo Goryli? Platynowe. OpenAI + Stripe to najsilniejszy możliwy sygnał dla rynku.

Tron usługowy? Pusty. Kompletnie, totalnie pusty.

Personal Brand Tax? ŚREDNI dla ścieżki biznesowej, WYSOKI dla ścieżki technologicznej. Możesz wybrać.

To jest wzorcowy przykład technologii która spełnia wszystkie wymiary strategicznego wyboru OSS dla Software House. Ale - i to jest kluczowe - okno czasowe jest ograniczone.

Za pół roku będzie znacznie trudniej. Za rok może być za późno żeby zostać Gorylem. Wtedy zostanie ci walka o drugą pozycję, o bycie jednym z wielu dostawców.

Pytanie które musisz sobie teraz zadać nie brzmi “czy to jest dobra technologia” - odpowiedź jest oczywista: tak.

Pytanie brzmi: “czy jesteśmy gotowi działać TERAZ, szybko, zdecydowanie?”

Gotowi wybrać jedną niszę i skupić się tylko na niej?

Gotowi zbudować pierwszy case study nawet jeśli będzie to po kosztach?

Gotowi powiedzieć głośno “to jest nasza specjalizacja” zanim zrobi to ktoś inny?

Jeśli odpowiedź jest “tak” - masz przed sobą historyczną szansę. Może nie w skali Callstack i React Native. Ale definitywnie szansę na zbudowanie wysokomarżowego, skalowalnego biznesu wokół technologii która będzie rosła przez następną dekadę.

Jeśli odpowiedź jest “nie” albo “nie jesteśmy pewni” - nie ma w tym nic złego. Czasem najlepsza strategia to poczekać aż rynek się ustabilizuje, aż pierwszy Goryl się pojawi, aż będzie jasne że to działa. Wówczas możesz wejść na niżej wiszący owoc, na drugą czy trzecią pozycję, na niszę którą Goryl zignorował.

Obie drogi są dobre. Ale musisz wybrać świadomie, nie przypadkiem.

W następnym numerze: Lista technologii które są w podobnej fazie co ACP - wczesna adopcja, pusty tron, błogosławieństwo Goryli - ale z różnymi poziomami Personal Brand Tax. Plus: framework do systematycznego scoringu każdej technologii w 15 minut.

Do zobaczenia za dwa tygodnie.

Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm typu Software House. Grow Your Software House to biuletyn z częścią darmową na Linkedin rozwinięty o płatne analizy tutaj na Substack wraz z wiedzą, narzędziami i filmami pokazującymi jak przestać błądzić i zacząć systematycznie rozwijać swój Software House. W dzisiejszym numerze:

• Jak analizować rosnące projekty na Github aby ocenić ich potencjał dla Twojego SH

• narzędzie do analizy repozytoriów na Github (Big Query) aby znaleźć te najbardziej obiecujące dla Twojego SH

• Anatomia Tornada: zrozumienie tornada, zanim wejdzie się w nie z swoim SH

• Test Tornada: Rust vs. Go - która technologia jest dobra 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.

Jak analizować rosnące projekty na Github aby ocenić ich potencjał dla Twojego SH/firmy usługowej IT?

Github to olbrzymie źródło wiedzy. Widzimy tam rosnące projekty, możemy zobaczyć, które rosną w liczbie gwiazdek na GH korzystając na przykład z tego adresu: https://github.com/trending. To bardzo pomocne w ręcznym szybkim skanowaniu tego co jest bardzo hot obecnie w przestrzeni OSS, ale totalnie niepraktyczne do analiz strategicznych dla firm typu software house/agencji software.

Dlaczego?

Ponieważ nie mamy większej perspektywy czasowej na przykład trzech miesięcy na wzrost danego projektu OSS oraz brakuje kilku krytycznych aspektów, które powodują, że dany projekt OSS może być obiecującym kandydatem dla Software House do budowy swojego silniku wzrostu.

TIP: Dlaczego warto budować swój software house/agencję wytwarzającą oprogramowanie i jego przewagę na rynku w oparciu o Open Source? pisałem o tym w #6 numerze naszego biuletynu (https://www.shgrowth.com/i/171716643/jakie-sa-kluczowe-cechy-projektu-oss-aby-stał-sie-sercem-silnika-wzrostu-w-sh). Jest tam przykład firm Callstack oraz Rigby, które prężnie rosną z bardzo wysokimi marżami.

Na szczęście z pomocą przychodzi nam AI, które potrafi generować bardzo wygodne skrypty w Big Query, do przerabiania bazy danych Github wzdłuż i wszerz. Stworzyłem dzięki temu skrypt Big Query, który można dostać pod tym linkiem -dostęp dla abonamentów SHG na Substack.

Dla osób bez dostępu do płatnej części, tutaj jest rezultat działania tego skryptu: https://docs.google.com/spreadsheets/d/1q1xVtsLAdPVQ9K5uKEd6_AlR_O7L639DmFWcql0zQIg/edit?usp=sharing ).

Mając listę 1000 projektów z całej bazy Github, które otrzymały największą liczbę gwiazdek i największą liczbę zgłoszonych unikalnych issues, możemy dokonać naszej analizy.

Czemu akurat te dwa kluczowe parametry?

liczba gwiazdek i liczba unikatowych issues to kluczowe metryki dla software houseów/firm usługowych IT. To, że dany projekt otrzyma dużą liczbę gwiazdek w ciągu dłuższego okresu np. trzech miesięcy w połączeniu z dużą liczbą zgłoszonych unikatowych issues to bardzo mocny sygnał, że projekt OSS nie tylko jest ciekawy, ale jest wdrażany przez bardzo dużą grupę developerów. Co jeszcze istotniejsze, to, że te issues są zgłaszane publicznie oznacza, że projekt ma określoną naturę: jest tworzony w trybie build in public, przez społeczność dla społeczności.

Nie każdy projekt na Github jest tak tworzony. Jest wiele projektów, które zyskują olbrzymią liczbę gwiazdek, ale issues są zgłaszane przez zamknięte fora, gdzie developerzy mają dostęp do wsparcia firmy, która daną technologię rozwija. To jest niestety obszar śmierci dla software housów ponieważ firma technologiczna w tym przypadku jest też firmą usługową i jej ekspertyza jest totalną przewagą nad każdą inną firmą - nie ma tutaj co po was.

Dlatego te dwa parametry: liczba gwiazdek i liczba unikatowych issues muszą iść ze sobą w parze.

Jak szybko odrzucić dany obiecujący projekt OSS z naszej listy kandydatów na silnik wzrostu?

Na powyższym obrazie widzimy na samej górze projekt vscode, claude-code. To są narzędzia developerskie do rozwoju systemów ze wsparciem agentów AI. Ta technologia jest obecnie w fazie bardzo intensywnego tornada, można powiedzieć, że cyklonu, w którym developerzy korzystają z nowych wersji tych narzędzi w zupełnie nowy sposób. Starają się wejść w fazę rozwoju oprogramowania z użyciem AI bo czują presję kierownictwa. Czy ta technologia jest dobrym punktem otwarcia przewag dla Software House? nie.

Popatrzmy na to z wizją celu. Jeśli jako dany software house/firma usługowa IT chcesz zbudować swoje liderstwo w danej technologii na świecie, to czy masz szansę zrobić to w oparciu o bycie np. core-contributor do vscode czy claude-code? z pewnością może to być bardzo wzmacniające Waszą pozycję w świecie jeśli nie tylko używacie, ale też tworzycie narzędzia do rozwoju oprogramowania z AI, ale to niestety nie jest właściwy moment.

Znaleźć właściwy moment wejścia danej technologii do firmy

Każda firma gdy rozważa wprowadzenie danej technologii do firmy robi to w określonych momentach. Jeśli dana technologia jest przełomowa dla niej, wymaga zmiany sposobu pracy systemów, pracy inżynierów to wybór tej technologii spoczywa na liderach/zarządzie. Dokonują analiz i wyboru określonego rozwiązania. Pojawia się tutaj moment wyjścia z firmy i szukania najlepszych standardów na rynku. W przypadku vscode/claude-code narzędzia te są częścią całego development stack’a technologicznego danej firmy, który musi być odświeżony. Ten stack technologiczny od razu zostaje wtłoczony w ręce developerów, którzy mają od tego momentu jedno zadanie - dostarczać lepszy kod, szybciej dzięki AI. Tutaj nie ma miejsca na zaproszenie zewnętrznej firmy usługowej - Ciebie! no może do szkoleń, ale Twoim największym przeciwnikiem jest obecny zespół developerów w firmie, którzy mają się nauczyć używania tego narzędzia od Ciebie i na tym zakończyć współpracę z Tobą. Możesz być ich przewodnikiem, ale nadal - jesteś firmą doradczą, której zadaniem jest towarzyszyć w przejściu, a nie przeprowadzić przejście.

W skrócie analizując dany projekt OSS musisz zobaczyć w jakim etapie wytwarzania oprogramowania dana technologia jest wybierana. Jeśli w tym etapie w firmie jest już zespół developerów, którzy muszą się jej nauczyć - to będzie Tobie trudniej tam wejść.

Co innego jeśli dana technologia jest tak trudna do opanowania, że lider technologiczny celowo unika jej wprowadzenia do swoich obecnych zespołów, a nadal chce ją wdrożyć.

Jeśli miałbyś pod tym kątem ocenić te technologie, które są w naszym pliku, to które z nich są:

• rozważane przez liderów technologicznych jako kluczowy filar dla nowego projektu lub jako kluczowy filar dla projektu migracji z starej na nową technologię? (fosa problemu vs rozwiązania)

• które z tych technologii są bardzo trudne do opanowania w krótkim czasie przez inżynierów, nawet tych doświadczonych w różnych językach? (fosa kompetencyjna)

Korzystając z AI można wkleić ten artykuł powyższy do tego miejsca, wysłać do niego csv i poprosić o analizę. Otrzymamy wówczas:

To czy dana technologia jest w odpowiednim momencie cyklu wytwarzania oprogramowania oraz czy stanowi odpowiednią fosę kompetencyjną to dobry start. Jest jednak szereg innych metryk, które warto wziąć pod uwagę:

• w jakiej fazie rynku i adopcji jest dana technologia

• jak jest dopasowana do Twojego DNA

• czy są goryle usługowe, goryle technologiczne, biznesowe, które przeszkadzają i pomagają

• czy technologia jest w fazie tornada czy na main-street, a może w przepaści i dopiero toruje swoją drogę w dane nisze)

• czy jest luka kompetencji

• czy model biznesowy goryli koliduje z Twoim

No jest tego sporo…

Najważniejsze jest jednak odsiać 80%, a powyższy artykuł w tym bardzo pomaga. Poniżej tłumaczę jak zanalizować czy dana technologia jest w odpowiedniej fazie przełomu na rynku, aby być dla Twojej firmy falą, na której zbudujesz stabilny rozwój.

Anatomia Tornada: Zrozumieć Burzę, Zanim w Nią Wejdziesz

W poprzednim numerze SHGrowth spojrzeliśmy w lustro, aby zrozumieć nasze strategiczne DNA. Teraz, uzbrojeni w tę wiedzę, musimy skierować wzrok na horyzont i zrozumieć naturę siły, którą chcemy ujarzmić.

Tornado nie jest po prostu marketingowym hasłem na "szybki wzrost". To specyficzny, gwałtowny i często brutalny fenomen rynkowy, który redefiniuje całe branże. Próba wejścia w nie bez dogłębnego zrozumienia jego mechaniki jest jak wypłynięcie na ocean podczas huraganu bez mapy i kompasu.

W tym rozdziale przeprowadzimy dogłębną analizę anatomii Tornada. Zrozumiemy jego dwa fundamentalne typy, poznamy cykl życia i, co najważniejsze, zidentyfikujemy kluczowych graczy i dynamikę, która decyduje o zwycięstwie lub porażce.

2.1. Dwa Silniki Tornada: Przełom Technologiczny vs. Biznesowy

Każde Tornado jest napędzane przez przełom paradygmatyczny – fundamentalną zmianę, która czyni stary sposób działania przestarzałym. Ale natura tego przełomu determinuje całą dynamikę rynku i strategię, którą musisz przyjąć.

Tornado napędzane Przełomem Technologicznym:

• Czym jest: Pojawia się fundamentalnie nowy i lepszy sposób na rozwiązanie horyzontalnego problemu inżynieryjnego. Wartość jest wewnętrzna dla technologii – jej wydajność, bezpieczeństwo, skalowalność.

• Jakie nisze atakuje: W strategii Kręgielni (czyli metodycznego zdobywania rynku nisza po niszy), twoje przyczółki nie są zorientowane branżowo, ale technologicznie.

  • Przykłady nisz technologicznych: systemy rozproszone, przetwarzanie danych w czasie rzeczywistym, natywne aplikacje mobilne, bezpieczeństwo pamięci.

• Naturalny Pretendent: Ta ścieżka jest idealna dla firmy o DNA Architekta Poziomu "Principal".

Tornado napędzane Przełomem Biznesowym:

• Czym jest: Nowa technologia staje się kluczowym narzędziem, które umożliwia realizację nowego, przełomowego modelu biznesowego w konkretnej branży. Wartość jest zewnętrzna – leży w wyniku biznesowym, który technologia umożliwia.

• Jakie nisze atakuje: Kręgielnia jest tu zorientowana wertykalnie (branżowo). Twoje przyczółki to kolejne firmy w ramach jednego, specyficznego sektora.

  • Przykłady nisz biznesowych: platformy e-commerce B2B dla producentów maszyn, systemy do zarządzania łańcuchem dostaw w farmacji, platformy do rezerwacji dla branży hotelarskiej.

• Naturalny Pretendent: Ta ścieżka jest idealna dla firmy o DNA Eksperta Domenowego.

2.2. Cykl Życia Tornada: Od Iskry do Hegemonii

Kiedy Tornado się zaczyna? Tornado nie zaczyna się w momencie, gdy powstaje technologia. Rozpoczyna się, gdy na rynku zderzają się dwie potężne siły, tworząc iskrę, która zapala całą prerię.

1. Siła #1: Nagromadzone Napięcie Rynkowe. Przez długi czas pragmatycy w danej niszy odczuwają rosnący ból. Stare narzędzia i procesy stają się coraz większą barierą dla wzrostu, efektywności lub bezpieczeństwa. Napięcie rośnie, ale strach przed ryzykiem związanym z nową, niedojrzałą technologią jest wciąż silniejszy.

2. Siła #2: Sygnał Bezpieczeństwa od Goryla. To jest właśnie ten brakujący katalizator. Rynek pragmatyków czeka na potężny, jednoznaczny sygnał, że nowa technologia jest już bezpieczna. Ten sygnał pochodzi od Goryli:

   • W Przełomie Technologicznym, jest to błogosławieństwo od Goryla Technologicznego (np. Microsoft ogłaszający wsparcie dla Rust w Windowsie). To sygnał, że platforma jest stabilna.

   • W Przełomie Biznesowym, jest to dowód wdrożeniowy od Goryla Biznesowego (np. Heineken ogłaszający sukces z Medusa.js). To sygnał, że rozwiązanie przynosi realne ROI.

Dopiero po tym sygnale, pierwszy, odważny pragmatyk w niszy decyduje się na wdrożenie, a Goryl Usługowy (taki jak Ty) pomaga mu zbudować "Cały Produkt". Sukces tego pierwszego wdrożenia staje się ostateczną, publiczną referencją, która uruchamia reakcję łańcuchową strachu przed pozostaniem w tyle (FOMO) w całej sieci pragmatyków. To jest moment, w którym Tornado oficjalnie się rozpoczyna.

• Ilu jest pretendentów przed Tornadem? W fazie Kręgielni, tuż przed wybuchem Tornada, może istnieć wielu (5-10) obiecujących pretendentów do tronu Goryla Usługowego. To czas intensywnej konkurencji o zbudowanie najlepszego "Całego Produktu" i zdobycie tych kluczowych, pierwszych referencji, które odpalą burzę.

• Kiedy Tornado się kończy? Tornado kończy się, gdy rynek jest nasycony, a bitwa o de facto standard jest rozstrzygnięta. Sygnałem końca jest zmiana języka rynku: pytanie "Którą technologię/partnera powinniśmy wybrać?" zostaje zastąpione przez "Jak możemy uzyskać lepszą cenę na standard X?". To jest płynne przejście na Główną Ulicę (Main Street) – fazę dojrzałości rynkowej.

• Ilu zostaje po Tornadzie? Hierarchia Rynkowa. Rynek po Tornadzie jest brutalnie hierarchiczny:

  • Jeden Goryl: Zdobywa dominujący udział w rynku (50-60%+). Nie musi być najlepszy, ale jest postrzegany jako najbezpieczniejszy wybór. Dyktuje ceny premium.

  • Jeden lub dwóch Szympansów: Zdobywają znaczący, ale drugorzędny udział (15-25%). Są silną alternatywą, ale muszą konkurować ceną. Ich marże są konkurencyjne, nie premium.

  • Cała reszta to Małpy: Walczą o resztki rynku. Konkurują wyłącznie ceną, a ich marże są minimalne. Twoim celem jest uniknięcie tego losu za wszelką cenę.

2.3. Wewnętrzny Komitet Zakupowy: Zrozumieć Graczy i ich Role

Strategiczna sprzedaż w Tornado nigdy nie jest rozmową z jedną osobą. To kampania prowadzona wewnątrz wewnętrznego komitetu zakupowego klienta. Musisz zrozumieć trzy kluczowe role, które twoja oferta musi zadowolić. Pamiętaj, że te role mogą być odgrywane przez różne osoby, a czasem jedna osoba (np. CTO) może odgrywać kilka ról jednocześnie.

• Rola #1: Biznesowy Lider Zmiany (The Business Change Leader)

  • Kim jest: Head of E-commerce, Dyrektor ds. Innowacji, CEO.

  • Jego cel: Wzrost, zdobycie przewagi konkurencyjnej, realizacja strategii biznesowej.

  • Jego pytanie: "Czy to rozwiązanie pomoże nam wygrać rynek?".

• Rola #2: Lider Optymalizacji (The Optimization Leader)

  • Kim jest: Head of Engineering, Lider Zespołu Deweloperskiego.

  • Jego cel: Efektywność, produktywność zespołu, jakość i szybkość dostarczania oprogramowania.

  • Jego pytanie: "Czy to rozwiązanie uczyni mój zespół szybszym i bardziej efektywnym?".

• Rola #3: Strażnik Platformy (The Platform Guardian)

  • Kim jest: Head of SRE, Dyrektor ds. Infrastruktury, Architekt Enterprise, CISO.

  • Jego cel: Stabilność, skalowalność, bezpieczeństwo i kontrola kosztów operacyjnych (TCO).

  • Jego pytanie: "Czy to rozwiązanie jest bezpieczne, skalowalne i czy nie wysadzi nam budżetu w powietrze za rok?".

2.4. Dynamika Władzy: Kto Decyduje, a Kto Wetuje?

Rola, jaką te archetypy odgrywają w procesie decyzyjnym, zależy całkowicie od natury przełomu.

• W Przełomie Technologicznym:

  • Główny Bohater (Czempion i Inicjator): Lider Optymalizacji lub Strażnik Platformy. To on ma problem i to on jest twoim głównym celem.

  • Kluczowy Sojusznik: Musisz go uzbroić w argumenty biznesowe, aby mógł przekonać Biznesowego Lidera Zmiany (który jest tu Nabywcą Ekonomicznym) do zatwierdzenia budżetu.

  • Twoja strategia: Sprzedajesz do lidera technicznego, ale myślisz o tym, jak on sprzeda to swojemu szefowi.

• W Przełomie Biznesowym:

  • Główny Bohater (Czempion i Nabywca Ekonomiczny): Biznesowy Lider Zmiany. To on jest właścicielem problemu i budżetu.

  • Kluczowy Strażnik Bramy: Lider Optymalizacji i Strażnik Platformy mają prawo weta. Ich zadaniem jest techniczna walidacja twojego rozwiązania. Ich "nie" może zabić projekt, nawet jeśli lider biznesowy jest przekonany.

  • Twoja strategia: Jest dwutorowa. Prowadzisz sprzedaż strategiczną do lidera biznesowego, jednocześnie prowadząc sprzedaż techniczną do liderów technologicznych, aby zneutralizować ich obiekcje i zamienić ich w sojuszników.

2.5. Wniosek Fazy Analizy: Zrozumienie Mapy to Nie To Samo, co Wygranie Wojny

W tym rozdziale stworzyliśmy mapę pola bitwy. Zrozumieliśmy, że Tornado może być napędzane przez dwa różne silniki – Przełom Technologiczny lub Biznesowy – i że każdy z nich tworzy zupełnie inną dynamikę rynkową i wymaga innej strategii "Kręgielni". Zobaczyliśmy, jak brutalnie hierarchiczny jest rynek po przejściu burzy, z miejscem dla tylko jednego Goryla i kilku Szympansów.

Co najważniejsze, zidentyfikowaliśmy kluczowych graczy w wewnętrznej grze o tron u klienta: Biznesowego Lidera Zmiany, Lidera Optymalizacji i Strażnika Platformy. Zrozumieliśmy, że w zależności od natury przełomu, ich role – od inicjatora po strażnika z prawem weta – ulegają fundamentalnej zmianie.

Jaki jest zatem ostateczny wniosek z tej analizy?

Samo zrozumienie anatomii Tornada nie wystarczy.

Możesz perfekcyjnie zdiagnozować, że nadchodzi burza, możesz idealnie zmapować wewnętrzny komitet zakupowy, ale jeśli twoja oferta, twoja komunikacja i twoja strategia nie będą precyzyjnie dopasowane do twojego DNA zdiagnozowanego w Fazie 0 (Lustro), przegrasz.

Firma o DNA "Architekta Poziomu Principal", która próbuje sprzedawać do "Biznesowego Lidera Zmiany" językiem wzrostu, będzie brzmiała fałszywie. Firma o DNA "Eksperta Domenowego", która nie potrafi uspokoić obaw "Strażnika Platformy", nigdy nie przejdzie przez jego bramę.

Dlatego mapa, którą właśnie stworzyliśmy, nie jest jeszcze planem zwycięstwa. Jest tłem, na którym, w kolejnych rozdziałach, zbudujemy strategię. Strategię, która połączy twoją autentyczną supermoc z głębokim zrozumieniem mechaniki rynku, aby stworzyć ofertę, której nie da się oprzeć.

Test Tornada: Rust vs. Go

Każdy z nas prowadzi firmę w tym samym, wyczerpującym wyścigu. To gra o bycie "lepszym dostawcą" w czerwonym oceanie setek podobnych firm usługowych IT. Konkurujemy portfolio, stawką godzinową i pozycją w rankingu Clutch. Ta gra rzadko prowadzi do zbudowania trwałej, dominującej pozycji na rynku. Prawdziwe zwycięstwo, status Goryla Usługowego, wymaga czegoś więcej: świadomego wyboru fali technologicznej, która jest na tyle potężna, by zredefiniować zasady gry i stworzyć na szczycie próżnię do wypełnienia.

Celem tego raportu nie jest kolejna akademicka analiza technologii. To strategiczny rekonesans. Używamy precyzyjnego i bezlitosnego frameworku "Testu Tornada", aby ocenić dwie fundamentalnie różne ścieżki, które stoją dziś przed każdą ambitną firmą technologiczną.

Dlaczego właśnie Rust i Go?

Ponieważ te dwie technologie nie są po prostu dwoma językami programowania. Reprezentują dwa archetypy strategicznych decyzji, dwa zupełnie inne pola bitwy, na których możemy walczyć o przyszłość naszej firmy:

1. Go (Golang) — Król Głównej Ulicy: To obecny, niekwestionowany władca ery chmurowej. Dojrzały, pragmatyczny, wspierany przez Google i stanowiący fundament ekosystemu Kubernetes. Wybór Go to wejście na ogromny, ugruntowany rynek, na którym popyt jest pewny, a "Cały Produkt" jest w pełni rozwinięty. To gra na "Głównej Ulicy" — bezpieczna, ale i zatłoczona. Pytanie strategiczne brzmi: czy na tak dojrzałym rynku jest jeszcze miejsce na zbudowanie dominacji, czy to już tylko walka o udział i marżę?
   

2. Rust — Rewolucyjny Pretendent do Tronu: To technologia o fundamentalnie innej obietnicy. Zamiast prostoty, oferuje bezkompromisowe bezpieczeństwo i wydajność. Jej "Fosa Kompetencyjna" jest legendarnie głęboka, co odstrasza większość, ale dla nielicznych tworzy historyczną szansę na zbudowanie fosy biznesowej. Wybór Rusta to zakład, że nadchodzi Tornado napędzane potrzebą niezawodności w krytycznych systemach. Pytanie strategiczne brzmi: czy ta fala jest wystarczająco silna i szeroka, a tron Goryla Usługowego wciąż pusty, aby uzasadnić ryzyko i inwestycję w trudną, ale potencjalnie rewolucyjną technologię?

Ten raport to strategiczny sparing. Zderzamy ze sobą dojrzałego króla z ambitnym pretendentem. Używając "Testu Tornada", nie pytamy "która technologia jest lepsza?". Pytamy: "Które pole bitwy daje nam, jako firmie usługowej, większą szansę na ucieczkę z czerwonego oceanu i zdobycie tronu Goryla?".

Każda faza Testu Tornada ma także etap “Challengera” czyli pytania kontrujące nasze tezy, pytania, które pewnie także Ty zadajesz sobie czytając poniższy raport.

• Technologia: Rust vs. Go (Golang)

• Data analizy: 8 września 2025

• Analityk/wersja: Gemini 2.5 pro zasilony ebookiem Test Tornada i szablonem raportu.

• Hipoteza przewodnia (1 zdanie): Rust tworzy warunki dla nowego, wysokomarżowego Goryla Usługowego (dominującego lidera rynku) w niszy systemów krytycznych, podczas gdy Go jest dojrzałym rynkiem "Głównej Ulicy", gdzie walka toczy się o udział, a nie o tron.

• Zakres rynku/nisz: Infrastruktura chmurowa, systemy wbudowane (embedded), FinTech, backendy o wysokiej wydajności.

• Źródła/rozmowy: Publiczne dane (raporty Stack Overflow, CNCF), keynote'y z konferencji (KubeCon, RustConf), analizy rynkowe, publiczne case studies (Microsoft, AWS, Google, Cloudflare).

Executive Summary

Rust

• Werdykt: ✅ GO

• Confidence (0–100%): 90%

• Dlaczego teraz (one-liner): Tornado (gwałtowna fala masowej adopcji) właśnie się formuje, Przepaść Talentowa jest ogromna, a tron Goryla Usługowego jest całkowicie pusty.

• Najmocniejszy sygnał / największe ryzyko: Błogosławieństwo od wszystkich Goryli Technologicznych i pusty tron / Konieczność zbudowania elitarnego, drogiego zespołu od zera.

• Decyzja warunkowa (gate): Jeśli do Q2 2026 nie zdobędziemy 1-2 projektów typu Lighthouse (strategicznych, publicznych wdrożeń referencyjnych) w niszy migracji C++, dokonujemy reewaluacji przyczółka.

Go

• Werdykt: ❌ NO-GO (dla strategii "Tornado")

• Confidence (0–100%): 95%

• Dlaczego teraz (one-liner): Tornado dawno minęło, rynek jest nasycony, a tron Goryla Usługowego jest rozdrobniony na wielu silnych graczy (Szympansów - silnych graczy nr 2).

• Najmocniejszy sygnał / największe ryzyko: Ogromna popularność i dojrzałość ekosystemu / Ekstremalna konkurencja i presja na marże (czerwony ocean).

• Decyzja warunkowa (gate): N/A. To jest rynek "Main Street", wymagający innej strategii (walka o udział, a nie o dominację).

F1 — Technologia (czy to inny gatunek, a nie tylko lepsza wersja?)

F1.1 Przełom paradygmatyczny (0–5)

• Rust: 5/5. Wprowadza fundamentalnie nowy model zarządzania pamięcią (ownership & borrow checker), eliminując całe klasy błędów i potrzebę garbage collectora. Jest to przełom paradygmatyczny – zmiana, która czyni stary sposób pracy przestarzałym – w programowaniu systemowym, łącząc bezpieczeństwo i wydajność w sposób wcześniej niemożliwy.

• Go: 4/5. Wprowadził przełom w prostocie i produktywności dla systemów sieciowych. Model współbieżności (goroutines, channels) był rewolucją w praktyce, upraszczając coś, co w Javie/C++ było ekstremalnie złożone. Nie jest to jednak tak fundamentalna zmiana w modelu obliczeń jak w przypadku Rusta.
  

• Wniosek: Obie technologie są rewolucyjne, ale przełom Rusta jest głębszy i dotyka bardziej fundamentalnych problemów informatyki, co tworzy większy potencjał na redefinicję rynku.

F1.2 Przewaga 10× (0–5)

• Rust: 5/5. Przewaga 10x leży w redukcji ryzyka. Microsoft publicznie podaje, że ~70% ich krytycznych luk to błędy pamięci – Rust eliminuje je w czasie kompilacji. Dla Strażnika Platformy (osoby odpowiedzialnej za stabilność i bezpieczeństwo systemu), jest to przewaga 100x.

• Go: 4/5. Przewaga 10x leży w produktywności deweloperskiej (TTM). Zespół może dostarczać niezawodne usługi sieciowe znacznie szybciej niż w Javie/C++. Jest to ogromna wartość dla Lidera Optymalizacji (osoby odpowiedzialnej za efektywność zespołu deweloperskiego).

• Wniosek: Obie oferują ogromną przewagę, ale Rust rozwiązuje problem o wyższej wartości strategicznej (bezpieczeństwo vs. szybkość developmentu), co pozwala na dyktowanie wyższych cen za usługi Goryla Usługowego.

F1.3 Fosa kompetencyjna (0–5)

• Rust: 5/5. Fosa kompetencyjna – bariera wiedzy oddzielająca ekspertów od amatorów – jest w przypadku Rusta legendarna. Stroma krzywa uczenia się i złożoność koncepcyjna (borrow checker, lifetimes) tworzy trwałą, głęboką barierę, gwarantując rynek na elitarną, wysokomarżową ekspertyzę.

• Go: 2/5. Go został celowo zaprojektowany, by mieć płytką fosę. Prostota i mała liczba funkcji to jego główne zalety. To przyspiesza adopcję, ale prowadzi do szybkiej komodytyzacji usług, ponieważ rynek szybko nasyca się kompetentnymi deweloperami.

• Wniosek: Fosa Rusta jest idealnym fundamentem dla Goryla Usługowego, chroniąc jego marżę. Płytka fosa Go jest strategicznym zagrożeniem, prowadzącym do walki cenowej.

F1.4 Szerokość Tornada (0–5)

• Rust: 4/5. Zasięg jest ogromny: od systemów wbudowanych, przez systemy operacyjne, infrastrukturę chmurową, po backendy FinTech. Wszędzie tam, gdzie bezpieczeństwo i wydajność są krytyczne. Problem, który rozwiązuje, jest uniwersalny na poziomie infrastruktury.

• Go: 5/5. Zasięg jest jeszcze szerszy na poziomie aplikacji. Jest to de facto standard dla narzędzi CLI, mikrousług i dużej części ekosystemu CNCF. "Pożar" (potrzeba szybkich, skalowalnych API) jest powszechny w niemal każdej firmie.

• Wniosek: Go ma szerszy, bardziej horyzontalny zasięg, co doprowadziło do jego szybkiej adopcji. Rust celuje w wertykalne, ale głębsze i bardziej wartościowe nisze, co buduje trwalszą przewagę.

• Implikacja fazy: Rust → potencjał Tornada (okno 6–24 mies.). Go → bowling alley długotrwały / Main Street.

Challenger F1: Czy fosa Rusta nie jest zbyt głęboka, co spowolni adopcję? (Odpowiedź: Błogosławieństwo Goryli to niweluje, dając pragmatykom sygnał bezpieczeństwa). Czy prostota Go nie jest właśnie tym, czego potrzebuje 90% rynku, czyniąc Rusta trwale niszowym? (Odpowiedź: Rynek na usługi premium żyje w pozostałych 10%, gdzie "wystarczająco dobry" to za mało).

F2 — Rynek (czy scena jest gotowa?)

F2.1 Błogosławieństwo goryli (0–5)

• Rust: 5/5. Platynowe błogosławieństwo od wszystkich: Microsoft, AWS, Google, Meta. Jest oficjalnie integrowany z Linuksem, Windowsem i Androidem. Sygnał dla rynku jest jednoznaczny i potężny.

• Go: 5/5. Stworzony i promowany przez Google, jest fundamentem całego ekosystemu Kubernetes i CNCF. Błogosławieństwo jest absolutne i ugruntowane od lat.

• Wniosek: Obie technologie mają maksymalne poparcie Goryli, co eliminuje ryzyko adopcji dla pragmatycznych klientów.

F2.2 Faza „przed tornadem” (0–5)

• Rust: 4/5. Jesteśmy w fazie "zaawansowanej kręgielni", gdzie technologia metodycznie zdobywa kolejne nisze ("kręgle"), budując referencje i pęd przed masową adopcją. Widać to po rosnącej liczbie referencji od pragmatyków (np. Cloudflare, Figma) i ogromnym FOMO ("Fear Of Missing Out") wśród elity inżynierskiej.

• Go: 1/5. Tornado dla Go miało miejsce w latach 2014-2018. Dziś to jest dojrzała technologia na "Głównej Ulicy" – fazie dojrzałości rynkowej, gdzie technologia jest standardem. Dowodem jest jej wszechobecność w ofertach pracy, kursach uniwersyteckich i status domyślnego wyboru dla narzędzi chmurowych. Pociąg już dawno odjechał.

• Wniosek: Timing dla Rusta jest idealny, by wejść i zdefiniować rynek usług. W Go, rynek jest już zdefiniowany, a gra toczy się o optymalizację i udział w istniejącej strukturze.

F2.3 Przepaść talentowa (0–5)

• Rust: 5/5. Ostry, strukturalny deficyt. Znalezienie doświadczonego inżyniera Rusta jest jednym z największych wyzwań rekrutacyjnych w IT, co winduje stawki i tworzy naturalny popyt na usługi firm, które ten talent posiadają.

• Go: 2/5. Rynek jest zrównoważony. Dzięki prostocie języka, podaż kompetentnych inżynierów jest duża, co obniża stawki i barierę wejścia dla konkurencji.

• Wniosek: Gigantyczna przepaść talentowa w Ruście tworzy idealne warunki dla Goryla Usługowego do zbudowania wysokomarżowego biznesu.

F2.4 „Pusty tron” (0–5)

• Rust: 5/5. Tron jest całkowicie pusty. Rynek usług jest rozdrobniony na małe, szanowane butiki (np. Ferrous Systems, Tweede Golf), ale brakuje globalnego lidera o znaczącej skali. Istnieje ewidentny wakat na firmę, która zdefiniuje i zdominuje tę kategorię.

• Go: 1/5. Rynek jest zatłoczony. Istnieje wielu silnych graczy (Szympansów, Goryla brak!), a konkurencja jest zacięta. Firmy takie jak EPAM, Accenture, Billennium czy Canonical mają rozbudowane i dojrzałe praktyki Go. Próba wejścia na ten rynek jako nowy lider byłaby niezwykle kosztowna i skazana na walkę z ugruntowaną konkurencją.

• Wniosek: Szansa na zdobycie tronu w Ruście jest historyczna. W Go, gra toczy się o bycie jednym z wielu silnych graczy, a nie o dominację.

Challenger F2: Czy pusty tron Rusta nie jest sygnałem, że rynek jest wciąż zbyt mały, by go utrzymać? (Odpowiedź: Wskaźniki adopcji i inwestycje Goryli przeczą tej tezie, pokazując, że rynek gwałtownie rośnie).

F3 — Problem Biznesowy (czy gasimy prawdziwy pożar?)

• Rust: 5/5. Rozwiązuje krytyczny problem bezpieczeństwa i wydajności w fundamentalnych częściach systemów. To jest "painkiller" o najwyższej możliwej wartości, z presją czasu (zero-day exploits) i regulacji. ROI jest mierzony w milionach dolarów za uniknięty incydent bezpieczeństwa.

• Go: 4/5. Rozwiązuje bardzo ważny problem szybkości dostarczania i skalowalności usług. To również jest "painkiller", z mierzalnym ROI w postaci niższego TCO i szybszego TTM, ale stawka jest zazwyczaj niższa niż w przypadku Rusta.

• Werdykt: Rust → Krytyczny Painkiller. Go → Painkiller.

Challenger F3: Czy klient jest gotów zapłacić 2x więcej za Rusta, jeśli Go jest "wystarczająco dobry"? (Odpowiedź: Dla systemów krytycznych, takich jak infrastruktura płatnicza czy systemy operacyjne, "wystarczająco dobry" nie istnieje, a koszt błędu jest nieskończenie wyższy niż koszt developmentu).

F4 — „Whole Product” (co musi istnieć, aby pragmatycy kupowali?)

• Rust: 3/5. "Cały Produkt" – czyli kompletne rozwiązanie problemu klienta, włączając narzędzia, integracje i wsparcie – szybko dojrzewa, ale wciąż istnieją luki. To jest zarówno ryzyko, jak i szansa dla Goryla Usługowego, aby te luki wypełnić, budując własne IP i akceleratory.

• Go: 5/5. "Cały Produkt" jest kompletny i niezwykle dojrzały. Tooling, biblioteki, dokumentacja i wsparcie społeczności są światowej klasy.

• Wniosek: Dojrzałość Go obniża barierę wejścia i marże. Niedojrzałość ekosystemu Rusta tworzy naturalny, trwały popyt na usługi eksperckie o wysokiej wartości.

Scoring & Progi Decyzji

Interpretacja wyniku:

• Rust: 62.5 / 72.5 = 86% → ✅ GO

• Go: 46.4 / 72.5 = 64% → ❌ NO-GO (ponieważ wynik < 75% oraz kluczowe wskaźniki "Tornado" (F2.2, F2.4) są na poziomie 1). Wynik 64% plasuje go w kategorii WATCH, ale w kontekście strategii Tornada jest to jednoznaczny NO-GO.

Rust: Rust ma przełom 5/5, 10× 5/5 i szerokość 4/5; rynek jest w fazie Pre-Tornado, tron usług jest pusty. W 90 dni: zbudować PoC migracji C++ dla FinTechu, pozyskać lighthouse w tej niszy, zbudować akcelerator Rust-Assured Migration™.

Go: Go ma przełom 4/5, 10× 4/5 i szerokość 5/5; rynek jest na Głównej Ulicy, tron usług jest zajęty. Strategia wymagałaby walki o udział w dojrzałym rynku, a nie zdobywania nowej kategorii.

1. Get a Google Cloud account

   • Go to cloud.google.com and sign in with your Google account.

   • If you’ve never used Google Cloud before, enable billing (you can set a monthly budget to control spend).

   • The free tier gives you 1 TB of BigQuery queries per month — plenty for this script if you run it weekly.

2. Open BigQuery

   • Navigate to console.cloud.google.com/bigquery.

   • At the top, select or create a new project (e.g., software-house-trends).

3. Create a dataset for your results

   • In the left panel, click your project name → Create dataset.

   • Name it gh_trending.

   • Set Location to US (GitHub Archive is stored in the US).

   • Click Create dataset.

4. Open the SQL editor

   • Click Compose new query.

   • Copy and paste the provided SQL script into the editor.

5. Set a safe cost limit

   • In the query editor, click Query settings → Advanced options.

   • Set Maximum bytes billed to something like 10 GB.

   • This prevents accidental large scans.

6. Run the query

   • Click Run.

   • Wait a few seconds — the results table will appear below the editor.

7. Save or export the results

   • Click Save Results in the top right of the results table.

   • Choose CSV, JSON, or Google Sheets if you want to share or analyze it further.

8. (Optional) Save as a view for reuse

   • Above the query, click Save → Save View.

   • Store it in the gh_trending dataset so you can run it again without copying SQL each time.

9. (Optional) Schedule to run automatically

   • With the query open, click Schedule.

   • Choose how often to refresh (daily, weekly).

   • Set the destination table in gh_trending so it overwrites with fresh data each run.

   • This gives you an always-up-to-date trending list.

10. Review regularly

• Go to the dataset → click the saved view or table → view results.

• You can download or share with your team anytime.

-- Top repos by UNIQUE STARRERS in the last 3 months,
-- plus unique issue openers and total issues opened (same window).

DECLARE m0 STRING DEFAULT FORMAT_DATE('%Y%m', DATE_TRUNC(CURRENT_DATE(), MONTH));
DECLARE m1 STRING DEFAULT FORMAT_DATE('%Y%m', DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH), MONTH));
DECLARE m2 STRING DEFAULT FORMAT_DATE('%Y%m', DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 2 MONTH), MONTH));

-- Keep the base CTE column-pruned to help BigQuery read fewer bytes.
WITH base AS (
  SELECT
    repo.name                      AS repo_name,
    actor.login                    AS actor_login,
    type,
    JSON_VALUE(payload, '$.action') AS action,
    created_at
  FROM `githubarchive.month.*`
  WHERE _TABLE_SUFFIX IN UNNEST([m0, m1, m2])
    AND created_at >= TIMESTAMP(DATETIME_SUB(CURRENT_DATETIME(), INTERVAL 3 MONTH))
    AND created_at <  CURRENT_TIMESTAMP()
),
stars AS (
  SELECT
    repo_name,
    COUNT(DISTINCT actor_login) AS unique_starrers
  FROM base
  WHERE type = 'WatchEvent'
    AND action = 'started'
    AND actor_login IS NOT NULL
    AND NOT ENDS_WITH(actor_login, '[bot]')
  GROUP BY repo_name
),
issues AS (
  SELECT
    repo_name,
    COUNT(DISTINCT actor_login) AS unique_issue_contributors,
    COUNT(*)                    AS issues_opened
  FROM base
  WHERE type = 'IssuesEvent'
    AND action = 'opened'
    AND actor_login IS NOT NULL
    AND NOT ENDS_WITH(actor_login, '[bot]')
  GROUP BY repo_name
)
SELECT
  COALESCE(stars.repo_name, issues.repo_name) AS repo_name,
  IFNULL(unique_starrers, 0)            AS unique_starrers,
  IFNULL(unique_issue_contributors, 0)  AS unique_issue_contributors,
  IFNULL(issues_opened, 0)              AS issues_opened
FROM stars
FULL JOIN issues USING (repo_name)
ORDER BY unique_starrers DESC, unique_issue_contributors DESC
LIMIT 1000;

Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm typu Software House. Grow Your Software House to biuletyn z częścią darmową na Linkedin rozwinięty o płatne analizy tutaj na Substack wraz z wiedzą, narzędziami i filmami pokazującymi jak przestać błądzić i zacząć systematycznie rozwijać swój Software House. W dzisiejszym numerze:

• Jak wybrać przełomową technologię dla Twojego SH - Test Tornada

• Jak ocenić potencjał Twojego SH dla wybranej przełomowej technologii?

• Czy React Native jest dobrą technologią dla Twojej firmy usługowej IT?

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.

Jak wybrać przełomową technologię dla Twojego SH - Test Tornada

W ostatnim podcaście omawiam Test Tornada, poniżej mapa myśli z tego podcastu, a tutaj link do Miro z mapą i pozostałymi notatkami.

Jak ocenić potencjał Twojego SH dla wybranej przełomowej technologii?

Każda strategia zaczyna się od mapy. Od analizy terenu, identyfikacji sił rynkowych i wyznaczenia celu. To jest logiczne, profesjonalne i w 9 na 10 przypadków prowadzi do porażki…
Dlaczego? Ponieważ większość liderów zapomina o najważniejszej zasadzie każdej kampanii wojennej: zanim spojrzysz na mapę, musisz wiedzieć, jaką armią dysponujesz. Strategia, która jest idealna dla elitarnej jednostki komandosów, będzie samobójstwem dla ciężkiej dywizji pancernej.

Najczęstszym powodem, dla którego genialne strategie zawodzą, nie jest błąd w analizie rynku. Jest nim fundamentalny brak spójności między planem a strategicznym DNA firmy, która ma go wykonać.

Dlatego nasz "Test Tornada" nie zaczyna się od rynku. Zaczyna się od lustra.

Zanim przeanalizujesz technologię, zanim ocenisz rynek, musisz brutalnie i szczerze zdiagnozować, kim jesteś jako organizacja. Musisz zrozumieć swoją naturalną, trudną do skopiowania supermoc. Na rynku istnieją dwie główne, sprawdzone drogi do zdobycia tronu Goryla Usługowego. Nie ma drogi "lepszej" ani "gorszej". Ale próba podążania obiema naraz lub wybranie tej, która jest niezgodna z twoim DNA, jest gwarancją porażki.

Użyj tego "Lustra", aby zdiagnozować, którym z dwóch archetypów pretendentów jesteś. Odpowiedź zdefiniuje twoją naturalną strategię wejścia na rynek i stanie się soczewką, przez którą będziesz patrzeć na wszystkie kolejne fazy naszego testu.

Archetyp 1: Architekt Poziomu "Principal" (The Principal-Level Architect)

DNA i Mentalność:

Twoja firma myśli i działa jak światowej klasy Principal Engineer. W jej sercu leży głęboka, niemal artystyczna obsesja na punkcie jakości, skalowalności i elegancji technicznego rozwiązania. Twoi liderzy to ludzie, którzy czerpią energię z rozwiązywania najtrudniejszych problemów inżynieryjnych. Zapach nowej serwerowni jest dla nich bardziej ekscytujący niż raport P&L klienta. Debaty o wyższości jednego algorytmu nad drugim mogą trwać godzinami. To jest firma zorientowana na produkt i technologię (Product-Centric).

Supermoc:

Twoją supermocą jest autorytet i zaufanie w elitarnej społeczności technologicznej. Nie musisz mówić rynkowi, że jesteś dobry. Twoja praca mówi sama za siebie – jest publicznie widoczna w projektach open-source, w technicznych artykułach, które stają się wzorcem dla branży, i na scenach najważniejszych konferencji. Jesteś postrzegany nie jako dostawca, ale jako jeden z architektów, którzy kształtują przyszłość technologii. Twój autorytet wynika z dogłębnego zrozumienia wielu przypadków użycia (use cases) i z udowodnionej zdolności do tworzenia wzorcowych rozwiązań.

Naturalna Strategia Wejścia na Rynek:

Twoja droga na tron Goryla prowadzi przez Przełom Technologiczny. Szukasz technologii, która rozwiązuje palący problem inżynierów i działów IT. Twoim pierwszym krokiem jest aktywacja sieci osobistej wewnątrz elity technologicznej. To twoi znajomi – inni liderzy techniczni – staną się twoimi pierwszymi klientami, ponieważ ufają twojej ekspertyzie bezwarunkowo. Te pierwsze, wysokomarżowe projekty służą do zbudowania "skrzyni wojennej" (war chest) – zasobów finansowych i studiów przypadku, które pozwolą ci zaatakować szerszy rynek. Twoim naturalnym celem jest Lider Optymalizacji lub Strażnik Platformy.

Ryzyko do Zarządzania (Pięta Achillesowa):

Twoim największym zagrożeniem jest izolacja od realnych problemów biznesowych. W swojej pogoni za techniczną doskonałością ryzykujesz budowaniem najwspanialszych na świecie rozwiązań dla problemów, za które nikt nie jest gotów zapłacić. Musisz nieustannie zadawać sobie pytanie: "Czy ta elegancja techniczna przekłada się na mierzalną wartość dla biznesu klienta?".

Test Lustra dla Architekta:

• Czy twoi najlepsi ludzie wolą spędzić weekend na refaktoryzacji kodu, czy na rozmowie z klientem o jego procesach biznesowych?

• Czy twoja firma jest bardziej dumna z liczby kontrybucji do projektu open-source, czy z listu polecającego od CEO klienta?

• Czy wasze rozmowy sprzedażowe naturalnie dryfują w kierunku architektury systemu, czy modelu biznesowego klienta?

Archetyp 2: Ekspert Domenowy (The Domain Expert)

DNA i Mentalność:

Twoja firma ma obsesję na punkcie dogłębnego, niemal fanatycznego zrozumienia problemu biznesowego klienta. Technologia jest dla was tylko narzędziem – ważnym, ale zawsze drugorzędnym wobec celu, któremu ma służyć. Twoi liderzy czerpią energię ze studiowania map procesów biznesowych, analizowania regulacji branżowych i rozmawiania z użytkownikami końcowymi, aby zrozumieć ich frustracje. Wartość widzicie w rozwiązaniu problemu, a nie w elegancji narzędzia. To jest firma zorientowana na klienta (Customer-Centric).

Supermoc:

Twoją supermocą jest głęboka ekspertyza branżowa i empatia. Mówisz płynnie językiem swoich klientów – czy to bankowości, logistyki, czy e-commerce B2B. Rozumiesz ich akronimy, ich procesy i ich politykę wewnętrzną lepiej niż niejeden z ich własnych pracowników. Twój autorytet nie wynika z wiedzy technicznej, ale z tego, że jesteś postrzegany jako "jeden z nas", partner, który naprawdę rozumie, na czym polega ich biznes.

Naturalna Strategia Wejścia na Rynek:

Twoja droga na tron Goryla prowadzi przez Przełom Biznesowy. Szukasz technologii, która pozwala rozwiązać strategiczny, głęboko zakorzeniony problem w jednej, konkretnej branży. Twoim pierwszym krokiem jest skoncentrowanie 100% sił marketingowych i sprzedażowych na tej jednej niszy i stanie się jej intelektualnym liderem. Pierwsze projekty zdobywasz nie dzięki znajomościom technicznym, ale dzięki dogłębnej wiedzy o problemie biznesowym, co pozwala ci dyktować ceny oparte na wartości (ROI). Twoim naturalnym celem jest Biznesowy Lider Zmiany.

Ryzyko do Zarządzania (Pięta Achillesowa):

Twoim największym zagrożeniem jest niedoszacowanie złożoności technicznej. W swojej pogoni za idealnym rozwiązaniem problemu biznesowego ryzykujesz "zakochaniem się w problemie" tak bardzo, że ignorujesz ograniczenia narzędzi lub wybierasz technologię, która nie jest wystarczająco potężna i skalowalna, aby dostarczyć obiecany przełom. Musisz zapewnić, że twoja empatia biznesowa jest wsparta wystarczająco silnymi kompetencjami technicznymi.

Test Lustra dla Eksperta Domenowego:

• Czy twoja firma chętniej zatrudni byłego menedżera logistyki i nauczy go technologii, czy genialnego programistę i będzie próbowała nauczyć go logistyki?

• Czy wasze studia przypadków skupiają się na metrykach technicznych (np. czas odpowiedzi API), czy na metrykach biznesowych (np. redukcja kosztów magazynowych o 15%)?

• Czy największym bohaterem w firmie jest inżynier, który napisał genialny algorytm, czy analityk, który odkrył kluczowy problem w workflow klienta?

Wniosek: Najważniejsza Decyzja

Zanim zrobisz kolejny krok, musisz podjąć decyzję. Nie ma dobrej ani złej odpowiedzi, ale brak odpowiedzi jest katastrofą.

Firma "Architektów", która próbuje udawać "Ekspertów Domenowych", będzie brzmiała fałszywie i nie zdobędzie zaufania biznesu. Firma "Ekspertów", która próbuje konkurować na poziomie głębi technicznej z "Architektami", przegra.

Dopiero gdy zrozumiesz swoje prawdziwe, autentyczne DNA, możesz świadomie wybrać technologię i rynek, na którym twoja naturalna supermoc daje ci największą szansę na zwycięstwo. Ta decyzja będzie soczewką, przez którą będziesz patrzeć na wszystkie kolejne fazy "Testu Tornada".

Czy React Native jest dobrą technologią do budowy SH?

Poniższa analiza jest wygenerowana przy użyciu Gemini Pro 2.5 zasilonego książką “Test Tornada”.

Analizowana Technologia: React Native

Cel Analizy: Ocena potencjału do zbudowania pozycji Goryla Usługowego w oparciu o ekosystem React Native.

Data Analizy: 8 września 2025

Faza 1: Diagnoza Technologii – Czy Fundament Jest ze Stali?

W tej fazie oceniamy, czy React Native posiada fundamentalne cechy technologii "gorylotwórczej".

4.1. Test Przełomu Paradygmatycznego

React Native bezsprzecznie wprowadził przełom paradygmatyczny w tworzeniu aplikacji mobilnych.

• Czy Wymusza Nową Architekturę? TAK. Przed React Native dominowały dwa modele:

  1. Pełny Native (Java/Kotlin dla Androida, Swift/Objective-C dla iOS): Skuteczny, ale wymagający dwóch oddzielnych zespołów, technologii i codebase'ów. Kosztowny i wolny.

  2. Rozwiązania Hybrydowe (np. Cordova, Ionic 1-3): Oparte na technologiach webowych w "opakowaniu" (WebView). Prostsze, ale z fundamentalnymi ograniczeniami wydajności i dostępu do natywnych funkcji. React Native wprowadził trzecią drogę: "Learn once, write anywhere". Umożliwił tworzenie w pełni natywnego interfejsu użytkownika z jednej, współdzielonej bazy kodu (JavaScript/TypeScript), co było fundamentalną zmianą w myśleniu o architekturze mobilnej.

• Czy Zmienia Workflow i Role w Zespole? TAK. Zlikwidował potrzebę utrzymywania dwóch oddzielnych, wyspecjalizowanych zespołów mobilnych, tworząc nową rolę "React Native Developera". Umożliwił też firmom z silnymi kompetencjami w ekosystemie React (web) znacznie płynniejsze wejście w świat mobile.

• Czy Umożliwia Robienie Rzeczy Wcześniej Niemożliwych? TAK. Umożliwił startupom i firmom z ograniczonym budżetem wejście na rynek mobilny z produktem na obie platformy w czasie i koszcie, które wcześniej były nieosiągalne.

Wniosek strategiczny: React Native bezapelacyjnie jest technologią rewolucyjną, a nie ewolucyjną. Test zaliczony.

4.2. Test Przewagi Rzędu Wielkości (10x)

Przewaga React Native jest gigantyczna, ale manifestuje się w różnych wymiarach dla różnych decydentów.

• Dla Lidera Optymalizacji: TAK. Oferuje przewagę bliską 10x w efektywności zespołu. Możliwość współdzielenia ~80-95% kodu między platformami i wykorzystanie narzędzi takich jak Fast Refresh drastycznie przyspiesza development (developer experience). Zamiast dwóch zespołów, potrzebny jest jeden, co jest ogromną optymalizacją.

• Dla Biznesowego Lidera Zmiany: TAK. Przewaga 10x leży w time-to-market. Wprowadzenie nowej aplikacji lub kluczowej funkcji na obie platformy jednocześnie, a nie sekwencyjnie, jest strategicznym game-changerem, pozwalającym wyprzedzić konkurencję.

• Dla Strażnika Platformy: W tym wymiarze przewaga nie jest 10x. Koszty utrzymania jednej bazy kodu są niższe, ale potencjalne problemy z wydajnością i skomplikowane aktualizacje mogą generować nowe koszty operacyjne.

Wniosek strategiczny: React Native dostarcza bezdyskusyjną przewagę 10x w kluczowych dla biznesu i developmentu wymiarach (szybkość i efektywność). To wystarczająco silny argument, by pragmatycy podjęli ryzyko. Test zaliczony.

4.3. Test Fosy Kompetencyjnej

To kluczowy punkt analizy dla React Native.

• Stroma Krzywa Uczenia się: Pozornie niska dla deweloperów React, co jest ryzykiem komodytyzacji. Jednak prawdziwa, mistrzowska produktywność wymaga zrozumienia niuansów obu platform (iOS/Android), co jest znacznie trudniejsze.

• Złożoność Koncepcyjna: Największa fosa leży w tzw. "Bridge" (starym i nowym - JSI) – mechanizmie komunikacji między światem JavaScript a natywnym. Optymalizacja wydajności, tworzenie własnych modułów natywnych czy debugowanie problemów specyficznych dla platformy wymaga głębokiej, eksperckiej wiedzy.

• Niedobór Oczywistych Wzorców: Chociaż ekosystem jest dojrzały, wciąż pojawiają się nowe biblioteki i wzorce (np. w zarządzaniu stanem, nawigacji). Wybór odpowiedniego stosu technologicznego i architektury dla aplikacji o dużej skali jest nietrywialny.

• Niedojrzałość Ekosystemu: Ekosystem jest dojrzały, ale jednocześnie bardzo dynamiczny. Aktualizacje React Native bywają bolesne, a wiele bibliotek open-source jest porzucanych. Zależność od zewnętrznych paczek tworzy ryzyko, które ekspert musi umieć mitygować.

Wniosek strategiczny: Fosa Kompetencyjna w React Native jest szeroka i głęboka, ale ukryta. Łatwo jest zacząć, ale ekstremalnie trudno jest zbudować i utrzymać skomplikowaną, wydajną aplikację na dużą skalę. To idealne warunki dla Goryla Usługowego, który sprzedaje polisę ubezpieczeniową od ryzyka związanego z tą ukrytą złożonością. Test zaliczony.

Wniosek Fazy 1: Werdykt dla Fundamentu

Fundament technologiczny React Native jest ze stali. Technologia jest rewolucyjna, oferuje ogromną, mierzalną przewagę i posiada głęboką, choć subtelną, Fosę Kompetencyjną. To idealny kandydat na technologię "gorylotwórczą".

Faza 2: Diagnoza Rynku – Czy Scena Jest Gotowa na Nowego Króla?

Tutaj analiza staje się bardziej złożona. Oceniamy dojrzałość i strukturę rynku.

5.1. Test Błogosławieństwa Goryli

• Goryl Technologiczny: React Native ma najsilniejsze możliwe błogosławieństwo. Został stworzony i jest rozwijany przez Meta (Facebook). Jest również oficjalnie wspierany i używany przez Microsoft. To podwójne, platynowe błogosławieństwo od dwóch największych Goryli Technologicznych na świecie.

• Goryl Biznesowy: Technologia jest używana i sprawdzona w boju przez setki liderów rynkowych: Shopify, Tesla, Coinbase, Discord, Pinterest. To jednoznaczny sygnał dla pragmatyków, że technologia jest bezpieczna i przynosi ROI.

Wniosek strategiczny: React Native ma absolutnie niepodważalne błogosławieństwo od wszystkich kluczowych graczy. Ryzyko adopcji z perspektywy pragmatyka jest zminimalizowane. Test zaliczony.

5.2. Test Fazy "Przed Tornadem"

To najważniejszy i najbardziej otrzeźwiający punkt całej analizy.

React Native nie jest w fazie "Przed Tornadem". Tornado dla tej technologii miało miejsce w latach ok. 2017-2020. Obecnie, w roku 2025, React Native jest technologią w pełni dojrzałą, która znajduje się na Głównej Ulicy (Main Street).

• Pierwsze Referencje Pragmatyków: Mamy tysiące referencji.

• Rośnie Napięcie i FOMO: FOMO już dawno minęło. React Native jest jedną ze standardowych, domyślnych opcji.

• Ekosystem Zaczyna Dojrzewać: Ekosystem jest w pełni dojrzały, z ugruntowanymi rozwiązaniami.

• Brak Jasnego Lidera: Liderzy technologiczni są jasno zdefiniowani (Meta, Microsoft).

Wniosek strategiczny: Nie można już "wskoczyć w Tornado", ponieważ ono już dawno przeszło. Strategia nie może polegać na zdobywaniu rynku w chaosie. Musi to być strategia walki o udział w dojrzałym, ustrukturyzowanym, ale wciąż gigantycznym rynku. To fundamentalnie zmienia zasady gry. Test na fazę "Przed Tornadem" niezaliczony.

5.3. Test Przepaści Talentowej

• Trudność Rekrutacji: Istnieje paradoks. Rynek jest zalany deweloperami React, którzy potrafią tworzyć proste aplikacje w React Native. Jednak znalezienie prawdziwego eksperta z 5+ letnim doświadczeniem w komercyjnych, skomplikowanych projektach, rozumiejącego natywne API i optymalizację, jest ekstremalnie trudne.

• Wysokość Wynagrodzeń: Wynagrodzenia dla topowych ekspertów React Native należą do najwyższych na rynku.

Wniosek strategiczny: Przepaść Talentowa istnieje, ale nie na poziomie podstawowym, lecz na poziomie eksperckim. To doskonała wiadomość dla aspirującego Goryla Usługowego, którego model biznesowy opiera się na dostarczaniu elitarnego talentu, a nie "klepaczy kodu". Test zaliczony.

5.4. Test Pustego Tronu

Tron Goryla Usługowego w ekosystemie React Native nie jest pusty. Jest silnie oblegany, a być może nawet częściowo zajęty.

• Zmapuj Ekosystem: Na rynku globalnym istnieje kilku bardzo silnych, rozpoznawalnych pretendentów, takich jak Callstack, Software Mansion, Infinite Red.

• Przeprowadź Test Lakmusowy Goryla:

  • Skala i Zasięg: Firmy te mają po 100-250+ osób, globalną obecność i doświadczenie z klientami z listy Fortune 500.

  • Klarowność Fokusu: Ich pozycjonowanie jest w 100% skoncentrowane na React Native.

  • Wkład w Ekosystem: To jest ich największa siła. Software Mansion tworzy i utrzymuje kluczowe biblioteki (np. Reanimated, Gesture Handler). Callstack jest partnerem Meta i organizuje największą konferencję React Native EU.

  • Własność Intelektualna: Mają własne narzędzia i metodyki.

  • Zaufanie Pragmatyków: Posiadają portfolio z największymi markami na świecie.

Wniosek strategiczny: Próba frontalnego ataku i ogłoszenia się "nowym Gorylem React Native" byłaby strategicznym samobójstwem. Rynek ma już swoich liderów (co najmniej na poziomie Szympansów, a być może jeden z nich jest już Gorylem). Tron nie jest pusty. Test niezaliczony.

Wniosek Fazy 2: Werdykt dla Pola Bitwy

Scena nie jest gotowa na nowego króla, który przyjdzie znikąd i zdominuje cały rynek. Rynek jest dojrzały (Główna Ulica), a kluczowe pozycje są zajęte. Oznacza to, że strategia musi być inna. Nie "land grab" w chaosie Tornada, ale strategia podboju w ramach istniejącego królestwa.

Faza 3: Diagnoza Problemu Biznesowego – Jaki Rodzaj Pożaru Gasisz?

React Native rozwiązuje problemy o ogromnej skali.

• Lokalizacja Bólu: Epicentrum bólu leży na styku biznesu i rynku. Głównym problemem, jaki rozwiązuje RN, jest niemożność szybkiego i efektywnego kosztowo konkurowania na obu platformach mobilnych.

• Słownik Bólu: Dominuje język strategiczny (time-to-market, competitive advantage, market share) i finansowy (TCO, operational costs).

• Właściciel Problemu: Głównym właścicielem jest Biznesowy Lider Zmiany (CEO, CPO, Head of Mobile), który widzi, że przegrywa rynek. Lider Optymalizacji (CTO, Head of Engineering) jest kluczowym sojusznikiem, który ma dostarczyć rozwiązanie.

• Stawka: Konsekwencją nierozwiązania problemu jest utrata pozycji rynkowej, czyli porażka strategiczna.

Wniosek Fazy 3: Gdzie Leżą Prawdziwe Pieniądze?

React Native niemal zawsze jest odpowiedzią na problem o skali strategicznej. Stawka jest ogromna, co oznacza, że potencjał na marżę premium jest bardzo wysoki. Klienci nie płacą za kod w JavaScripcie; płacą za przetrwanie i wygraną na rynku mobilnym.

Faza 4: Diagnoza Potencjału – Jak Zbudować Strategię, by Zdobyć Tron?

Biorąc pod uwagę dojrzałość rynku i obecność silnych graczy, strategia musi być niezwykle precyzyjna.

7.1. Krok 1: Zbudowanie Mandatu od Społeczności

Nie da się już zbudować autorytetu poprzez proste kontrybucje. Mandat musi być zdobyty poprzez dominację w niszy. Zamiast być "dobrym we wszystkim", trzeba stać się najlepszym na świecie w jednym, konkretnym aspekcie React Native (np. animacje, bezpieczeństwo, aplikacje offline-first). To tam trzeba tworzyć biblioteki, pisać artykuły i przewodzić.

7.2. Krok 2: Identyfikacja Przyczółka (The Beachhead)

Strategia generalistyczna ("robimy aplikacje w React Native") jest skazana na porażkę i walkę cenową. Kluczem jest wybór przyczółka, który jest niedostatecznie obsługiwany przez obecnych liderów.

• Przyczółek Technologiczny: "Jesteśmy absolutnie najlepsi w budowaniu super-wydajnych aplikacji React Native z grafiką 3D i AR".

• Przyczółek Biznesowy: "Jesteśmy Gorylem Usługowym React Native dla branży MedTech, z pełną certyfikacją HIPAA".

7.3. Krok 3: Architektura Obietnicy

Obietnica musi być dopasowana do przyczółka. Dla przyczółka MedTech:

• Rdzeń Obietnicy: "Dostarczamy certyfikowane, bezpieczne i w pełni zgodne z HIPAA aplikacje MedTech w React Native, redukując ryzyko prawne i skracając czas wejścia na rynek o 50%".

• Filary Dowodowe:

  1. Elitarny Talent: Zespół z certyfikatami bezpieczeństwa i doświadczeniem w projektach HIPAA.

  2. Sprawdzona Metodyka: Nasz autorski HIPAA-Ready RN Blueprint™.

  3. Gwarancja Wyników: Gwarancja przejścia audytów bezpieczeństwa w umowie (SLA).

7.4. Krok 4: Operacjonalizacja "Całego Produktu"

Cała firma musi być zoptymalizowana pod kątem dominacji w wybranym przyczółku. Oznacza to dedykowane procesy rekrutacyjne (szukanie ludzi z doświadczeniem w MedTech), dedykowany zespół R&D (rozwijający HIPAA-Ready RN Blueprint™) i wyspecjalizowany marketing (treści skierowane do liderów w branży medycznej).

Ostateczny Werdykt i Rekomendacja Strategiczna

React Native jest technologią o ogromnym potencjale, która rozwiązuje strategiczne problemy warte miliony. Jej fundament jest ze stali. Jednak Tornado już dawno minęło, a rynek wszedł w dojrzałą fazę Głównej Ulicy, na której tron Goryla Usługowego jest już silnie broniony przez etablowanych graczy.

Werdykt: Szansa na zostanie globalnym, generalistycznym Gorylem Usługowym React Native od zera jest bardzo niska. Próba frontalnej konfrontacji z liderami takimi jak Callstack czy Software Mansion zakończy się porażką.

Rekomendacja strategiczna: Zamiast nierealistycznej walki o tron całego królestwa, strategia powinna polegać na stworzeniu i zdominowaniu własnego księstwa.

1. Porzuć Ambicję bycia "Gorylem React Native". Zamiast tego, postaw sobie cel bycia "Gorylem React Native dla branży X" lub "Gorylem od problemu Y w React Native".

2. Zidentyfikuj strategiczny przyczółek (technologiczny lub biznesowy), który jest wystarczająco duży, by generować wysokie marże, ale zbyt niszowy, by obecni liderzy byli w nim absolutnymi ekspertami.

3. Skoncentruj 100% sił (marketing, sprzedaż, R&D, rekrutacja) na zdominowaniu tej niszy, budując w niej mandat od społeczności i tworząc wokół niej swój "Cały Produkt".

4. Po absolutnym zdominowaniu pierwszego przyczółka, użyj zdobytych referencji i kapitału, aby zaatakować sąsiednią, logicznie powiązaną niszę, powtarzając strategię "Kręgielni" w ramach dojrzałego rynku.

Twoja droga do sukcesu nie prowadzi przez chaos Tornada, ale przez precyzyjną, chirurgiczną strategię podboju na Głównej Ulicy. Nie zostaniesz królem z dnia na dzień, ale możesz zostać niekwestionowanym władcą w najbogatszej prowincji tego królestwa.

Po słowie

Wybór przełomowej technologii, która stanie się filarem Twojej firmy na lata to moja specjalizacja. Jeśli jesteś SH, który zastanawia się nad tym czy obecna technologia jest dobrą inwestycją na lata, jak przejść na nową technologię i zbudować pozycję lidera na globalnym rynku - zapraszam do kontaktu (mat@shgrowth.com).

In this episode, Maciej (Mat) Gren introduces a powerful strategic tool for software development agencies: the Tornado Test. This framework helps agencies determine if their chosen core technology is the right wave to ride to become a "Service Gorilla"- a dominant leader in their market niche.

Selecting a technology is one of the most fundamental and difficult decisions for a software agency. It dictates hiring, training, and marketing investments, locking the company into a long-term path. But how do you know if you're betting on the right horse?

Inspired by Geoffrey Moore's classic "Inside the Tornado," this test provides a structured approach to analyzing a technology's potential. It's not just about what's new and shiny; it's about identifying a technology at the perfect moment in its lifecycle to build sustainable growth and market leadership.

In this episode, you will learn about the four critical phases of the Tornado Test:

1. Phase 1: Your Company's DNA: Are you obsessed with technology or with solving business problems? Understanding your archetype is the first step to aligning your strategy with the right kind of technology.

2. Phase 2: Technology Diagnosis: Does the technology introduce a revolutionary paradigm shift? Does it offer a 10x advantage over the old way? And critically, does it have a "competency moat" that makes deep expertise highly valuable?

3. Phase 3: Market Diagnosis: Is the market ready for a new king? We look for blessings from tech giants, assess the talent gap, and, most importantly, check if the "throne is empty" or already occupied by other Service Gorillas.

4. Phase 4: Building the Gorilla Strategy: Once you've analyzed the landscape, how do you build a strategy to dominate? It involves establishing a strong community mandate, focusing on a high-value problem, and building an offer based on risk elimination.

To make it concrete, Mat applies the Tornado Test to a real-world example: the Scala programming language. He shares insights from his seven years of experience in the Scala ecosystem, revealing whether it's still in the "tornado" phase or has moved to "Main Street," and what that means for agencies specializing in it today.

Listen to this episode to gain a strategic framework that will change how you view your technology choices and help you build a durable, high-margin service business.

Hi! My name is Maciej Greń, and for 17 years I’ve been helping Software House companies grow. Grow Your Software House is a newsletter with a free section on LinkedIn, expanded here on Substack with paid analyses, knowledge, tools, and videos showing how to stop wandering and start systematically developing your Software House.

In today’s issue:

• Brotherhood as a key element of SH success

• Exiting the niche where your growth engine operates can be painful – Callstack example

• GenAI Growth Engine – how SOFTIQ built scalable AI-driven sales in the Public sector

• What is the Open Source Growth Engine – Callstack and Rigby example

The knowledge shared in this newsletter should be used with caution and at your own responsibility. I frequently borrow phrases from English—please forgive me; I do it intentionally because we use them constantly in our daily work.

Brotherhood as a Key Element of SH Success

Paul Graham, one of the founders of Y Combinator, emphasized that one of the main reasons for rejecting applications is the fact that a startup has only one founder, though this is not an absolute rule — solo-founders are sometimes accepted, but rarely. Tomek Karwatka recently said something similar in an interview. It’s no coincidence that many of the companies they incubated began in Wrocław. It’s not the beauty of the city, but the proximity of founders that is key. Why is physical proximity so important? Because when things get tough, when intense conversations happen, they need to be built on personal relationships.

Your co-founder can be your wife, a friend, family, or an acquaintance. On the “family photo,” family usually looks best, which is why many people wrongly assume that a co-founder should be a stranger. We often avoid building close, friendly relationships, yet it’s one of the superpowers that matters immensely. A friend is someone who, above all, loves us. Yes, love is a rather dangerous word in business, but those who truly have such a friend in their company know what I mean. This is someone who cares less about money and more about their relationship with you. Someone who will support you through hardships and tell you the honest truth when they see you heading in the wrong direction.

The degree to which such a co-founder is underestimated is, unfortunately, lethal. First, I often see companies entering equity relationships and calling someone a co-founder when there is no real bond with that person. After all, business doesn’t have to go hand-in-hand with “love,” right? At the end of the day, we all want to make money, and that should be enough to keep us together?

Well… the problem is that when the money is less than you expected, or a better opportunity appears for your co-founder to build a better business with someone else — what will keep them with you?

If you have no bond, you don’t enjoy spending time together outside work, and you lack a shared conviction to move in the same direction, then unfortunately situations like this often lead to:

• Negotiations over equity: “or I’ll leave.”

• Pressure to pivot “into something more profitable right now.”

• Expectations for a high salary: “I have other offers, I could leave.”

Sadly, it turns out that what you’re building together depends on an illusory transaction in your co-founder’s mind, an expiry date that is inevitably approaching, and you have no way to “pay,” while carrying a ton of stress.

And what will motivate you to keep working when a cold sweat wakes you up at night and you fight paralyzing thoughts until morning?

These are truly hard moments, almost impossible to go through alone. A co-founder who walks with you through the dark valley and restores your faith is priceless.

Of course, sometimes your co-founder must leave for objective reasons. In my life, I had one co-founder who is still my friend today, though we had to part ways in very difficult circumstances when we both had burned through our savings and naturally couldn’t move forward together. What’s beautiful is that we’re still in touch, and no matter how long we go without speaking, whenever we reconnect there’s always that sense of “brotherhood.”

Having a co-founder with whom you share a deep bond is crucial at every stage of building a company.

A Co-founder Doesn’t Have to Hold Equity

People who support you and have been “on the bus with you from day one” don’t necessarily have to be shareholders. One of the huge mistakes founders make is assuming that key employees without equity will never be as committed as shareholders, so to fully engage them you need to give them shares. This is a fatal assumption leading to poor decisions:

• Offering equity to key employees who don’t care about shares but value the shared vision, respect, and friendship kills a perfectly functioning relationship and turns it into your constant expectations and complaints: “now you’re a shareholder, so you should do this or that.”

• Brotherhood in a relationship is more important to many people than equity. Undervaluing the potential of brotherhood in working with key employees and inserting managers between you weakens your collaboration.

• Replacing brotherly relationships with purely business ones — “showering” key employees with money, hoping it will motivate them more. What motivates them is working together, not money, which comes and goes.

• Introducing OKRs and other operational systems implemented by external consultants who destroy your partnership by “measuring performance,” ignoring the complex aspects of your prior agreements and a long-standing effective collaboration model built on a deep understanding of your mutual needs.

Key employees need appreciation and a deep connection with the founder. It doesn’t have to be friendship; sometimes admiration, alignment of ideas, and values are enough. This is the case with Elon Musk, who, due to Asperger’s, doesn’t build relationships the same way more relational people do. Through his attitude, dedication, ambition, and charisma, he creates a sense of elitism, mission, and deeper meaning. Many companies lack this, which is why people long to work for Elon’s companies.

A support team for whom being together matters more than the fastest ride in one direction is key. The fact that you’re on the bus together is enough for them, even if the well-equipped bus temporarily becomes an old model. You’ll still be in it together and can’t imagine riding with anyone else.

When Brotherhood Breaks — 5 Deadly Sins

There are a few situations where a seemingly strong brotherly bond can be quickly severed. Below are things I’ve personally witnessed in my work with companies — the five deadly sins that permanently, sometimes irreversibly, destroy a brotherly bond with a co-founder:

1. Ignoring heartfelt requests — When your co-founder sincerely asks you for something important and you ignore or dismiss it. If they’re asking, they’ve hit a wall. Rational arguments don’t work; they’re appealing to your relationship, hoping you’ll come to your senses. Often it’s a silent cry that gets ignored. In aggressive growth or survival mode, it’s easy to miss such signals, but this systematically kills the relationship.

2. Ordering instead of asking — “I’m the boss here.” Instead of a request, you use the argument of power, authority, or title, forcing your co-founder to do something against their will while ignoring their concerns. This destroys the bond and reduces your co-founder to a task executor.

3. Publicly undermining them — Attacking your co-founder publicly, taking away their sense of self-worth. Public arguments and questioning their competence hurt deeply. I’m not talking about having different opinions on a topic — I mean attacks that wound them.

4. Breaking agreements out of greed — Not fulfilling arrangements with your co-founder despite being able to, acting from a position of strength. Greed can lead you to betray your co-founder. Using your power against them kills the relationship.

5. Going behind their back — Doing things that undermine the very foundation of trust. Your co-founder trusts you and assumes you trust them. If you sabotage their work behind their back to avoid conflict, act inconsistently, or break trust in other ways, they cannot comprehend it. This disappointment and frustration, combined with a lack of understanding of your actions, quickly destroys the relationship.

Of course, the problem isn’t always you. Your co-founder might be influenced by various voices, thoughts, or fears, leading to emotional imbalance or a drop in professionalism. That may tempt you to take shortcuts — do things behind their back, avoid confrontation or discussion. Remember: in a brotherly, loving relationship with your co-founder, you can simply invite them for bowling, billiards, jogging, PlayStation — whatever you did together when you were close — to evoke those memories and use the bond as a platform to open up. Listening to your co-founder allows you to return to the depth of the relationship and clear the air.

One brutal truth, however, is that this cleansing of the relationship is very hard to achieve when you’re far apart. Physical presence, being together in daily life, is a powerful platform. Founders severely underestimate this, hoping that everything will be fine and that remote co-founding sometimes works. But if you look at the history of companies, you’ll see that co-founders and key employees spend time together daily and have a strong bond. Not because online work is impossible, but because they know their bond builds trust and the sense of “being on the same bus.” That sense gives meaning, strengthens the bond, and adds energy for the daily boring, tedious, sometimes disappointing work.

GenAI Growth Engine – How SOFTIQ Built Scalable AI-Driven Sales in the Public Sector

GenAI is on the lips of practically every business. Everyone looks at their tasks and processes and wonders: “Is this a good candidate for using GenAI?”…

GenAI is undeniably a Tornado, or even what I call a Cyclone, because a Tornado usually transforms a horizontal niche, whereas here both horizontally and across many vertical niches at once, the promise of time savings, process improvements, and quality gains through GenAI makes everyone think about it.

Even pragmatists in large companies — who usually wait for a “new standard” and a “complete product” — are trying to stay on top and sculpt something out of AI. But they quickly hit the entry barrier because GenAI technology is still, for them, undeniably an incomplete product. After all, how do you call something “complete” when it can generate beautiful essays and yet in the next moment make mistakes in simple math equations? (Yes, I know there’s GPT-5 Pro used for scientific research, but it suffers from similar fundamental limitations as the whole family of LLMs.)

Thus, we have a GenAI Cyclone — an intensified Tornado.

Even though pragmatists bravely stand in organizations and say, “AI is still far from being usable here,” they feel pressure from management because “the competition is already boasting that thanks to AI they’ve cut costs by X%.”

Pragmatists have to roll up their sleeves and… wade through the mud. That’s the last thing they want to do. They weren’t hired to do R&D. They were hired to deliver value in the area they’ve been studying, working, and building their competencies in for years. Now they dive into the world of AI and drown in a sea of solutions and platforms — a real Hyde Park.

Meanwhile, SOFTIQ, a software house from Gliwice, builds its growth engine on… public procurement contracts. Not just in Poland, but abroad as well. They do it manually at first, but when the first LLMs appear — they start experimenting. They try to optimize their bidding process. They improve it for themselves, not to turn it into a product — that wasn’t their goal. They grow — contrary to the global trend in the software house market. While SHs are laying people off in 2023–2024, they are hiring. They enhance their internal AI platform for applying to public tenders, and thanks to AI they expand into other countries — Scandinavia, Iceland, the UK.

Their product matures and inevitably the question arises:

Why should only SOFTIQ be its sole user?

They discover a vertical niche where by giving access to their platform, they won’t create direct competitors for themselves, but rather help companies from another segment grow — construction.

This is how Przetargi.io was born, a service that radically accelerates the tender application process for companies in that sector. The software house used its internal tool to reach those pragmatists who, under pressure from their boards to “do something with AI,” suddenly see SOFTIQ as a savior — with a ready-made product tailored to their niche.

Just a few months after launching the platform, SOFTIQ already has over 100 clients on it. Look at their pricing — it’s cheap. How does an SH make money then? Clients need customization. It’s the same here.

The platform confirms that the system works. It’s like an expanded demo that helps pragmatists in a given segment gain trust and overcome resistance.

And this is only the beginning. Every company has its internal document structures, procedures, etc. Here, since SOFTIQ is the leader in this tool, they can charge completely differently — based on delivered business value, not hours worked. It’s a textbook example of a vertical product-based growth engine for a specific industry niche.

Building a tool in a vertical niche — even just a prototype — is, in my opinion, an ideal way for software houses to sell custom GenAI development.

It’s much easier to go into one niche and build a reputation as a leader there, and it’s also easier to acquire subsequent clients when the first few projects are done “at cost.” This is the Bowling Alley strategy from Geoffrey Moore’s book Inside the Tornado.

However, remember that doing projects in a given niche is not yet a growth engine. The engine should lead to leadership in that niche. What does that mean?

If you really want to follow SOFTIQ’s path, you also need to roll up your sleeves and build a new brand in that niche — a domain expertise brand that delivers business value, not technological value. You need to want to become a leader in that niche. Without this, you’ll just be another SH with a few at-cost projects that aren’t properly leveraged to build leadership. SOFTIQ builds this leadership both in the public sector and in a given industry niche.

Which niche do you want to lead in?

Exiting the Niche Where Your Growth Engine Operates Can Be Painful – Callstack Case Study

The Open Source Growth Engine (OSSGE) uses an open-source project as a platform to build leadership for a service company (Software House). Sounds simple? Not quite. According to analyses, there are tens of millions of OSS projects, but only a tiny fraction can directly serve as the heart of a Software House’s Growth Engine.

What makes an OSS project ideal for becoming a SH growth engine?

An OSS project is essentially a technology. For it to become the heart of a growth engine, it must change the paradigm in a niche and trigger a Tornado (as described in Geoffrey Moore’s Inside the Tornado). A Tornado forms when two powerful forces collide:

1. The drive to maximize profits (the primary force pushing every business forward).

2. The resistance of the existing paradigm (tools, people, lack of access to resources).

Normally, these forces don’t meet because there’s no outlet for the pressure. Pragmatists in the mainstream market see a new technology but say:

“It’s too complicated, too risky, and there’s no support.”

This resistance is stronger than the promise of profit. That’s the Chasm and Bowling Alley phases in Moore’s model: innovators and visionaries experiment with the tech, proving its value. Pressure builds, but there’s no eruption yet.

When a complete service or OSS product appears that pragmatists can adopt safely, the Tornado begins. A de facto standard emerges, eliminating the risk of “choosing the wrong option” for mainstream decision-makers.

At that point, the entire market — like one organism — rushes to adopt the new standard, as sticking with the old becomes riskier than change.

A classic example: React Native in 2016–2020.

The trend of building custom mobile apps collided with frustration over maintaining two separate apps (Android/iOS). Solutions existed, but pragmatists resisted. PhoneGap never became a standard. React.js, however, was already mainstream, backed by Meta (Facebook), and had won the frontend Tornado. This created a huge pool of technical leaders familiar with React who wanted to extend its paradigms to mobile apps.

During the rise of React Native, Mike Grabowski heavily contributed to OSS projects, one of which made it into React Native Core. This placed him and Callstack at the center of global tech leadership, alongside Meta. As React Native overcame pragmatist resistance, Callstack became the go-to service provider — the “Service Gorilla” — bridging businesses to the new tech. Meta never intended to own that service niche; open-sourcing was part of its strategy.

Everything scaled beautifully until 2024, when Callstack tried to expand beyond its Tornado niche into general React.js/Main Street services.

They redesigned their website and messaging… and it didn’t work.

As ex-CSO Krzysztof Pawlak put it:

“We pulled back faster than we decided to go forward.”

Why? Because Callstack’s brand strength in React Native attracted clients outside its premium niche. React.js Main Street is a commodity market with downward pricing pressure — the pool of developers explodes, and premium margins vanish. Callstack hit a wall. High-margin (80–90%) projects were no longer within reach. Their old brand kept attracting clients, but outside React Native, they weren’t seen as premium.

This shows Callstack’s OSS Growth Engine revolves around React Native. Even the company’s sale for ~0.5B PLN didn’t lead to Mike’s exit — his role as a key community leader makes him indispensable for new owners.

What Is the OSS Growth Engine in Callstack & Rigby?

Callstack’s success as a commercial custodian for React Native wasn’t accidental; it’s a repeatable OSSGE pattern — a strategy for building market leadership around a breakthrough OSS project.

It starts with diagnosing which paradigm the OSS project breaks:

• Does it solve a tech bottleneck (like React Native)?

• Or a deep business problem (like Medusa.js in complex B2B commerce)?

The answer defines your go-to-market.

In tech paradigm shifts, the pain is in IT (inefficiency, lack of skills). Pragmatists adopt only after a Tech Gorilla (like Meta) signals stability and future viability. When the Gorilla endorses the tech, the Tornado begins. That’s when a service company can become the Service Gorilla — the leading commercial implementation partner.

In business paradigm shifts, the OSS project addresses a strategic industry pain. Here, the signal must come from Business Gorillas — respected industry leaders (Heineken, Mitsubishi) who validate its business value. The path is slower — Bowling Alley strategy: niche by niche, building trust.

Why Tech Community Leadership Matters

Regardless of the path, OSSGE success hinges on:

1. A market vacuum (no dominant Service Gorilla yet).

2. The company’s ability to become not just a partner but an active OSS contributor & steward, earning a silent mandate from the market to define the tech’s future.

3. Ongoing leadership in the OSS community to maintain that position.

Who Is the Decision-Maker for a Software House Using an OSS Growth Engine?

In the diagram above, I showed the heart of the OSS Engine. What’s very important is that the type of new paradigm determines to whom the Service Gorilla (meaning your Software House, if it wants to leverage the OSS Engine and become an undisputed leader) directs its services and what language it speaks.

If the paradigm is technological, the main decision-maker is the technology leader who personally selected the OSS project for their company and is now looking for the best ways to implement their project.

If the new paradigm originates from business needs, the Service Gorilla will instead communicate its services to business decision-makers.
This is very clearly visible when we compare the homepages of Callstack and Rigby.

Callstack Website (callstack.com)

Callstack’s slogan “Your React & React Native Development Experts” sounds rather… ordinary.
The most valuable space at the very top of their site explains why:

“Callstack was founded a few months after React Native was released to support developers and companies looking to use it, without having to worry about the complexity of building native apps.
Since then, we’ve helped teams of all sizes succeed with React Native, while contributing to the core framework and maintaining key open source tools.”

The messaging is aimed 100% at the technical community, which already knows them very well — they read their e-books on React Native app performance, attend their conferences, and use their libraries.
Any company wanting to invest in migrating to this technology and struggling to build those competencies internally will naturally come to Callstack.

Rigby Website (rigbyjs.com)

It’s different with Rigby, a company that serves as a model Service Gorilla for the open-source project Medusa.js — as Medusa.js’s CEO himself points out.

Rigby focuses on the business client; its website does not put “Medusa Experts” as the main message. Instead, the focus is on delivering business value, with Medusa simply being the best technology for Rigby to achieve that goal.

Mercur.js (mercurjs.com)

Interestingly, Rigby has created its own OSS product called Mercur.js, which is a textbook example of the strategy described in Inside the Tornado.
At the moment when multiple business niches start adopting a given technology, the Service Gorilla (Rigby) delivers the “Whole Product” — in this case, a platform for building B2B marketplaces on Medusa.js.

Mercur and Rigby are consistent — they continue to communicate with the business decision-maker because they understand which paradigm (business) their technology breaks.
For many, this may seem like a small detail, but it’s absolutely critical.

Why Messaging Alignment Matters

Who we communicate our services and products to also determines what kind of insights (gathered from our work with this type of client) we use to educate them.

If you are breaking a business paradigm, but fail to understand this and communicate using only technical values, you’re effectively telling the market:

“We’re not ready to be the Service Gorilla because we don’t understand you.”

At best, the client’s development team may carry you on a platter to their business decision-makers — but that is a very long and painful path, during which the dev team may decide:

“Actually, we can just do this ourselves without you.”

There are still several other ways in which the OSS Growth Engine can effectively and sustainably build a competitive advantage for a Software House.
I’ll write about these in future issues of our newsletter.

Afterword

Identifying which OSS project is ideal for a given SH and moving the company from level 0 to 10/10 is my specialty.
If you’re a Software House that is either “sitting on a golden egg” (i.e., you have a popular OSS project in your hands) or want to direct your growth strategy toward an OSS project — feel free to contact me at mat@shgrowth.com.

Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm typu Software House. Grow Your Software House to biuletyn z częścią darmową na Linkedin rozwinięty o płatne analizy tutaj na Substack wraz z wiedzą, narzędziami i filmami pokazującymi jak przestać błądzić i zacząć systematycznie rozwijać swój Software House. W dzisiejszym numerze:

• braterskość jako istotny element sukcesu SH

• Wyjście z niszy gdzie działa Twój silnik wzrostu może być bolesne - przykład Callstack

• GenAI Silnik Wzrostu czyli jak SOFTIQ zbudował skalowalną sprzedaż na AI w Public'u

• czym jest Open Source Growth Engine - przykład Callstack i Rigby

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.

Braterskość jako istotny element sukcesu SH

Paul Graham, jeden z twórców Y Combinator, podkreślał, że jednym z głównych powodów odrzucania aplikacji jest fakt, że startup ma tylko jednego założyciela, choć nie jest to sztywna zasada – solo-founderzy bywają przyjmowani, ale rzadko. Podobnie w ostatnim wywiadzie mówił Tomek Karwatka. To nie jest przypadek, że wiele z ich inkubowanych firmy ma początek we Wrocławiu. To nie piękno miasta tylko bliskość founderów jest kluczem. Po co fizyczna bliskość? Bo jak jest ciężko, jak są intensywne rozmowy to trzeba je budować na relacji osobistej.

Co-founderem może być Twoja żona, przyjaciel, rodzina, znajomy. Z rodziną najlepiej wypada się "na zdjęciu rodzinnym”, dlatego wiele osób błędnie zakłada, że co-founderem powinien być ktoś obcy. Unikamy budowania relacji bliskiej, przyjaźni, a jest to jedna z supermocy, które są niesamowicie istotne. Przyjaciel to ktoś kto przede wszystkim nas kocha. Tak, miłość jest to słowo dość niebezpieczne w biznesie, natomiast Ci, którzy faktycznie mają takiego przyjaciela w swojej firmie wiedzą o czym piszę. To ktoś komu nie zależy na pieniądzach tak bardzo jak na relacji z Tobą. To ktoś, kto będzie Ciebie wspierał w trudach i mówił szczerą prawdę gdy widzi, że idziesz w złą stronę.

To jak bardzo niedoceniany jest taki co-founder jest niestety zabójcze. Po pierwsze, często widzę firmy, które wchodzą w relacje udziałowe i nazywają kogoś co-founderem gdy tak naprawdę nie ma z daną osobą mocnych relacji. Biznes przecież nie musi iść w parze z “miłością” prawda? Przecież na koniec dnia chcemy wszyscy zarobić i to powinno nas razem łączyć?

No właśnie... problem w tym, że gdy pieniądze są mniejsze niż oczekiwaliście, lub pojawia się inna lepsza okazja dla Twojego co-foundera aby zrobić lepszy biznes z kimś innym to co go będzie trzymało z Tobą?

Jeśli nie macie więzi, nie lubicie ze sobą przebywać poza pracą i wspólnego przekonania, że chcecie razem iść w jedna stronę to niestety takie sytuacje doprowadzą do następujących wydarzeń:

• Negocjacji udziałów “bo inaczej odejdę”

• Presji aby zmienić kierunek “w bardziej rentowny tu i teraz”

• Oczekiwania wysokiego wynagrodzenia bo “są inne oferty, które mogę przyjąć i odejść”

A co będzie Ciebie motywowało do dalszej pracy gdy w nocy przejdzie Ciebie zimny dreszcz i do ranka będziesz walczył z myślami, które paraliżują?

To są naprawdę ciężkie momenty, których przejście samemu jest arcy trudne. Wówczas co-founder, który razem z Tobą przejdzie przez ciemną dolinę i przywróci wiarę jest bezcenny.

Oczywiście może się zdarzyć, że z obiektywnych przyczyn co-founder musi odejść. W swoim życiu miałem jednego co-foundera, który jest moim przyjacielem do dziś, a z którym musiałem się pożegnać w bardzo trudnych okolicznościach gdy zarówno ja jak i on spaliliśmy już nasze oszczędności i naturalnie nie było możliwości iść wspólnie dalej. To co jest piękne to to, że jesteśmy nadal w kontakcie i nie ważne jak długo ze sobą nie rozmawiamy to zawsze gdy wracamy do siebie jest to poczucie “braterskości”.

co-founder nie musi mieć udziałów

Takie osoby, które są dla Ciebie wsparciem, są z Tobą “w wspólnym autobusie od pierwszych dni” nie muszą być od razu udziałowcami. Uważam, że jednym z gigantycznych błędów popełnianych przez founderów jest patrzenie na kluczowych pracowników bez udziałów jak na osoby, które nigdy nie będą w stanie tak mocno się oddać firmie jak "udziałowcy", zatem aby ich w pełni zaangażować trzeba im te udziały dać. Jest to fatalne założenie, która prowadzi do złych decyzji:

• oferowanie udziałów kluczowym pracownikom, gdy im nie zależy na tych udziałach tylko na wspólnej wizji, szacunku, przyjaźni prowadzi do zabicia idealnie działającej relacji i zamiany jej w Twoje ciągłe oczekiwania i pretensje, że "teraz jesteś udziałowcem, więc powinieneś to czy tamto"

• braterskość w relacji jest dla wielu osób bardziej kluczowe niż udziały. Niedoszacowanie potencjału braterskości w pracy z kluczowymi pracownikami, wprowadzanie menadżerów pomiędzy Wami osłabia Waszą współpracę

• zamiana relacji braterskiej na relacje biznesowe czyli "obsypywanie" kluczowych pracowników pieniędzmi licząc, że to ich bardziej zmotywuje. Ich motywuje wspólna praca, nie tak bardzo kasa, która raz jest, raz jej nie ma.

• wprowadzenie OKR's itp. systemów operacyjnych dla firmy przez zewnętrznych konsultantów, którzy niszczą relacje partnerskie między Wami bo "oceniają wydajność” pomijając złożone aspekty związane z wcześniejszymi ustaleniami między Wami, wieloletnim wydajnym modelem współpracy, który opiera się na głębokim rozumieniu Waszych potrzeb.

Kluczowi pracownicy potrzebują być doceniani, potrzebują głębokiej więzi z założycielem. Niekoniecznie musi to być przyjaźń. Czasem wystarczy podziw, spójność idei i wartości. Tak jest z Elonem Muskiem, który z racji posiadania zespołu Aspergera, nie buduje więzi tak samo jak osoby bardziej relacyjne. Dzięki swojej postawie, oddaniu, ambicji, haryzmie - buduje poczucie elitarności, misji, głębszego sensu. Wielu firmom tego brakuje, dlatego ludzie pragną pracować w firmach Elona.

Taki zespół wsparcia, dla którego bycie razem jest ważniejsze niż najszybsza podróż w jedną stronę - jest kluczowy. To, że jesteście razem w autobusie im wystarcza, nawet jeśli autobus z bardzo dobrze wyposażonego zamieni się na jakiś czas w stary model. Będziecie w nim razem i nie będziecie w stanie sobie wyobrazić jazdy z kimś innym.

Jest kilka sytuacji gdy braterska wieź, pomimo, że wydaje się bardzo mocna może być szybko zerwana. Poniżej te rzeczy, które bezpośrednio doświadczyłem w mojej pracy z firmami.

5 grzechów głównych, które trwale, czasem nieodwracalnie niszczą braterską wieź z co-founderem.

1. Gdy Twój co-founder Ciebie o coś szczerze z serca prosi, ale Ty tego nie zrobisz i zbagatelizujesz jego potrzeby. Gdy jest coś bardzo ważnego dla Twojego co-foundera i używa prośby oznacza to, że doszedł do ściany. Argumenty racjonalne nie działają, odwołuje się do Waszej relacji i liczy, że się opamiętasz. Niestety często jest to niemy krzyk, który jest pomijany. To systematycznie niszczy relację szczególnie gdy jesteś w trybie agresywnej ekspansji lub walki o przetrwanie łatwo można zignorować tego typu sygnały.

2. Gdy karzesz swojemu co-founderowi coś zrobić bo “jesteś tutaj szefem"Odwracamy tutaj role. Zamiast prośby stosujesz argument siły, przewagi, roli, tytułu. Karzesz coś zrobić swojemu co-founderowi wbrew jego woli, ignorując jego uwagi. Niszczysz w ten sposób wieź i zamieniasz swojego co-foundera w zadaniowca.

3. Gdy wchodzisz w konflikt np. podważasz co-foundera publicznie zabierając mu poczucie własnej wartości. Kłócenie się publicznie, podważanie kompetencji publicznie boli. Twój co-founder czuje się zdradzony. Nie mylmy tutaj posiadania sprzecznych zdań na dany temat. Piszę tutaj o ataku na co-foundera, który prowadzi do jego zranienia.

4. Gdy nie spełniasz swoich ustaleń z co-founderem, pomimo, że możesz to zrobić. Robisz to z pozycji siły, jesteś chciwy.Chciwość niestety może doprowadzić Ciebie do zdrady Twojego co-foundera. Wykorzystując swoją pozycję masz władzę nad Twoim co-founderem. Jeśli użyjesz jej przeciw niemu zabijesz relację.

5. Gdy robisz coś za plecami swojego co-foundera, cos co narusza jego zaufanie w podstawy Waszej relacji.Co-founder Tobie ufa. Zakłada, że mu ufasz i działa z pełnym zaangażowaniem. Jeśli w tym czasie naruszasz jego zaufanie, np. sabotażujesz jego pracę bo nie chce Ci się z nim “walczyć”, gdy jesteś niespójny z nim, Twój co-founder nie jest w stanie tego zrozumieć. To poczucie zawodu i frustracji, połączone z brakiem zrozumienia Twoich działań szybko prowadzi do zniszczenia relacji.

Oczywiście nie zawsze Ty jesteś problemem. Twój co-founder może być pod wpływem różnych głosów, myśli, lęków. To może prowadzić do jego rozchwiania emocjonalnego, obniżenia poziomu profesjonalizmu, który może Ciebie zachęcać do pójścia na skróty - robienia czegoś za jego plecami, niechęci do konfrontacji, niechęci do rozmowy, nawet potyczek słownych. Pamiętaj, że mając relację braterską, miłości z Twoim co-founderem możesz po prostu do niego podejść i zaprosić go na “kręgle, bilarda, wspólny jogging, granie na PS” cokolwiek robiliście razem gdy byliście blisko aby przywołać te wspomnienia i użyć tej więzi jako platformy do otwarcia. Wsłuchanie się w swojego co-foundera pozwoli Tobie na powrót do głębi relacji, oczyszcza atmosferę.

Tutaj niestety pojawia się jedna bardzo brutalna prawda - to oczyszczenie relacji jest bardzo trudne do zrobienia gdy jesteście od siebie daleko. Fizyczna relacja, spotkanie, bycie razem w codzienności to potężna platforma. Founderzy bardzo tego niedoceniają mając nadzieję, że przecież będzie wszystko dobrze i remote co-founding się czasem udaje. Gdy jednak przyjrzysz się historii firm to łatwo zobaczysz, że co-founderzy, kluczowi pracownicy są ze sobą codziennie, mają mocną relację. Nie dlatego, że nie można pracować online. Robią to dlatego bo wiedzą, że ich wieź buduje ich wspólne zaufanie i poczucie “siedzenia w jednym autobusie”. To poczucie daje sens, wzmacnia wieź, która natomiast dodaje sił do codziennej nudnej, żmudnej, czasem rozczarowującej - pracy.

GenAI Silnik Wzrostu czyli jak SOFTIQ zbudował skalowalną sprzedaż na AI w Public'u

GenAI jest na ustach praktycznie każdego biznesu. Każdy patrzy na swoje zadania, procesy i myśli “czy to jest dobry kandydat do użycia GenAI?”…

GenAI to niewątpliwie Tornado a nawet nazywam go Cyklonem bo Tornado zazwyczaj zmienia niszę horyzontalną, a tutaj zarówno horyzontalnie jak i w wielu wertykalnych niszach na raz siła “obietnicy oszczędności czasu, usprawnienia procesu, poprawy jakości dzięki GenAl” powoduje, że każdy o tym teraz myśli.

Nawet pragmatycy w dużych firmach, którzy zazwyczaj czekają na “nowy standard” i “kompletny produkt” sami próbują być na topie i próbują wyrzeźbić coś z AI. Szybko się oczywiście zderzają z barierą wejścia bo tak naprawdę technologia GenAI jest jeszcze dla nich niewątpliwie niekompletnym produktem, bo jak nazwać coś co potrafi generować piękne eseje podczas gdy w innym momencie myli się w prostych równaniach matematycznych (oczywiście wiem że jest GPT5 pro, które jest do badań naukowych, ale ma podobne ograniczenia fundamentalne jak cała gama LLMów).

Pomimo, że pragmatycy stoją dzielnie w organizacjach i mówią “to AI to jest jeszcze dalekie od użycia u nas” to czują ze strony managementu niepokój bo “konkurencja już się chwali, że dzięki AI obcięli koszty o X%”.

Pragmatycy muszą zakasać rękawy i ... brodzić w błocie. To chyba najgorsze co chcą robić. Oni nie zostali zatrudnieni do robienia R&D. Oni zostali zatrudnieni do dostarczania wartości firmie w obszarze, w którym się uczyli, pracowali, budowali swoje kompetencje przez lata. Nurkują w świat AI i toną w otchłani rozwiązań, platform, to istny hydepark.

W tym samym czasie firma SOFTIQ, Software House z Gliwic buduje swój silnik wzrostu na ...zamówieniach publicznych. Nie tylko w Polsce, ale też za granicą. Robi to ręcznie, ale gdy tylko pojawia się pierwszy LLM - zaczynają eksperymentować. Próbują optymalizować swój proces aplikowania. Usprawniają to dla siebie, nie aby zrobić z tego produkt, to nie był ich cel. Rosną i to wbrew globalnemu trendowi na rynku Software Housów. Gdy SH zwalniają w latach 2023-2024 to oni zatrudniają. Usprawniają swoją wewnętrzną platformę AI do aplikowania do zamówień publicznych, a dzięki AI przechodzą na inne kraje, Skandowania, Islandia, UK.

Ich produkt staje się kompletny i w sumie pojawiło się pytanie:

Odkrywają więc niszę wertykalną, w której dając swoją platformę nie zbudują sobie bezpośredniej konkurencji tylko pomogą firmom z innego segmentu rosnąć. Budownictwo.

Tak powstał serwis Przetargi.io, który pomaga firmom w tym segmencie radykalnie przyspieszyć proces zgłaszania się do przetargów. Software House użył swojego wewnętrznego produktu aby uderzając do tych pragmatyków, którzy i tak w tych firmach czują presję od zarządu aby “zrób coś z tym AI” nagle SOFTIQ jest jak zbawiciel. Gotowy produkt pod ich niszę.

Od otwarcia platformy minęło kilka miesięcy a SOFTIQ już ma na niej ponad 100 klientów. Gdy spojrzycie na cennik ich usługi - tanio. Jak SH zarabia? klienci potrzebują dostosować narzędzie do swoich potrzeb. Tak samo jest i tutaj.

Platforma to potwierdzenie, że system działa. Jest jak rozbudowane demo, które pozwala pragmatykom z danego segmentu zaufać i przełamać ich opór.

To dopiero początek bo oczywiście każda firma ma swoje wewnętrzne struktury dokumentów, procedury itp. Tutaj z racji, że SOFTIQ jest liderem w tym narzędziu mogą mieć zupełnie inne stawki, oparte o dostarczoną wartość a nie spędzone godziny. Jest to wzorcowy przykład silnika wzrostu opartego na produkcie wertykalnym, dla danej niszy branżowej.

Budowa w danej niszy wertykalnej narzędzia, nawet będącego prototypem to w mojej ocenie idealny sposób dla Software Housów aby sprzedawać custom development na systemy GenAI.

Dużo łatwiej jest iść do jednej niszy i budować tam wizerunek lidera i też łatwiej jest zdobywać kolejnych klientów gdy kilku pierwszych zrobi się "po kosztach”. To strategia Bowling Alley z książki “Inside the Tornado” Geoffrey’a Moore’a.

Pamiętajcie jednak, że robienie projektów w danej niszy to nie jest jeszcze silnik wzrostu. Silnik powinien prowadzić do liderstwa w danej niszy. Co to znaczy?

Jeśli faktycznie chcecie iść drogą SOFTIQ to musicie też zakasać rękawy i budować nowy brand w danej niszy. Brand ekspertyzy dziedzinowej, która dostarcza wartość biznesową, nie technologiczną. Musicie chcieć stać się liderem w tej niszy. Bez tego, będziecie tylko kolejnym SH z kilkoma projektami zrobionymi po kosztach, które nie są odpowiednio wykorzystane do budowania liderstwa. SOFTIQ buduje to liderstwo zarówno w public'u jak i w danej niszy branżowej. W której niszy Wy chcecie być liderem?

Wyjście z niszy gdzie działa Twój silnik wzrostu może być bolesne - przykład Callstack

Open Source Growth Engine wykorzystuje projekt open source jako platformę do zbudowania liderstwa firmy usługowej (Software House). Proste? Niekoniecznie. Wg. tej analizy projektów OSS jest kilkanaście milionów, a tylko niewielki promil z nich można bezpośrednio wykorzystać do budowania Silnika Wzrostu dla Software House.

Jakie są kluczowe cechy projektu OSS aby stał się sercem silnika wzrostu w SH?

Dana technologia (bo projekt Open Source to nic innego jak po prostu technologia) powinna zmieniać paradygmat w danej niszy i wywoływać Tornado. Tornado (z książki “Inside the Tornado”) powstaje gdy zbiera się bardzo duża masa różnych frontów atmosferycznych. W biznesie to firmy, które mają jeden cel - maksymalizacje zysku. To pierwsza siła odwiecznie pchająca każdą firmę do przodu - zwiększyć zysk.

Druga siła to opór (paradygmat obecny) w uzyskaniu tego zysku, czy to w narzędziach czy to w ludziach, czy w braku dostępu do zasobów. Te dwie siły normalnie ze sobą się nie zderzają bo jedna siła nie widzi ujścia jej gdy się ściera z drugą.

Przez długi czas rynek główny (pragmatycy w firmach na tym rynku) widzi nową technologię, ale mówi:

Opór przed zmianą jest silniejszy niż obietnica zysku. To jest właśnie faza Przepaści (Chasm) i Kręgielni (Bowling Alley) z książki Inside the Tornado. W przepaści technologia jest testowana przez innowatorów i wizjonerów i udowadnia swoją prawdziwą wartość. Napięcie rośnie, fronty się zbliżają, ale jeszcze nie ma gwałtownego zderzenia.

Gdy to ujście powstaje (tam jest kompletna usługa lub kompletny produkt OSS gotowy aby być użyty przez pragmatyków) wówczas tworzy się tornado. Powstaje de facto standard, który eliminuje ryzyko wyboru złej opcji dla pragmatyków (liderów technologicznych) w organizacjach w głównym rynku danej technologii.

Ekosystem partnerów, którzy dotychczas zdobywali określone nisze daną technologią jest gotowy, aby dostarczyć kompletne, działające rozwiązanie dowolnej firmie, którą na tą technologię stać.

W tym momencie, nagle, cała skumulowana energia – całe to ciśnienie z "frontu dążenia do zysku" i "frontu oporu starego paradygmatu" – znajduje swoje ujście w nowej technologii, która łamie stary paradygmat wprowadzając nowy.

I wtedy następuje Tornado.

Cały rynek, jak jeden organizm, rzuca się, aby zaadoptować nowy standard, ponieważ dalsze pozostawanie przy starej technologii jest teraz postrzegane jako większe ryzyko niż sama zmiana.

Technologia React Native właśnie była czymś takim w latach 2016-2020. Trend tworzenia przez biznesy dedykowanych aplikacji mobilnych był jak olbrzymi front atmosferyczny, który ścierał się z frustracja pisania dwóch oddzielnych aplikacji na dwie główne platformy (Android i iOS). Pojawiały się różne obiecujące rozwiązania, ale brakowało przełamania oporu pragmatyków w dużych organizacjach. Nadal dla nich PhoneGap nie był standardem. Standardem natomiast był już w tym czasie React.js. Wspierany przez Metę (wówczas Facebook) był już w fazie Main Street tzn. Tornado się skończyło i walkę technologii frontendowych dla mas wygrał właśnie React.js. To stworzyło całą rzeszę technicznych liderów, ktorzy znali "React" i poczuli potrzebę przeniesienia pewnych fundamentalnych założeń tej technologii na aplikacje mobilne.

W tym czasie gdy React Native gwałtownie zdobywał zainteresowanie liderów technologicznych wizjonerów, którzy nie bali się wdrażać te technologię w swoich biznesach, Mike Grabowski zaangażował się na 100% i tworzył kontrybuował do masy projektów OSS, jednym z najbardziej spektakularnych w tamtym czasie, który został zmergowany do React Native Core. To był dopiero początek.

Mike systematycznie był w samym centrum rozwoju tej technologii blisko liderów technologicznych z całego świata i z Mety (wówczas Facebook). Ponieważ React już był na Main Street (czyli na głównym rynku zgodnie z modelem Geoffrey'a Moore'a) czyli stał się standardem, oraz ponieważ Meta intensywnie kontrybuowała do rozwoju React Native, a społeczność liderów technologicznych sumienie ewangelizowała o gotowości React Native, technologia ta przełamała opór pragmatyków i stała się Tornadem. Mike i jego zespół z Callstack stali się frontem dla świata biznesu, który chciał przejść na React Native. Meta nigdy nie miała tego w swoim modelu biznesowym i na rękę było i nadal jest otwierać swój kod aby biznes sam go utrzymywał. Callstack stał się numerem jeden aby taki most zapewnić.

Wszystko rosło pięknie gdy w 2024 ktoś w Callstacku postanowił spróbować ugryźć jeszcze większy tort, tzn. zaatakować niszę React będącą na Main Street. Zmienili swoją stronę, zaczęli zmieniać komunikację do rynku, do społeczności technologicznej... i nie pykło. Poniżej strona Callstack 2024.

Jak to powiedział Krzysztof Pawlak, Ex-CSO w Callstack w jednym z ostatnich wywiadów:

Co się stało? Nagle z racji olbrzymiej siły obecnej marki, bycia top of mind zaczęli pojawiać się klienci z innego segmentu. Nie na React Native, na ogólne usługi. Main Street z React.js nie jest dobry na usługi z stawkami premium. Main Street dąży do standardu nie tylko technologii ale też spłycenia ceny bo rynek masowy rodzi masowo developerów w tej technologii, ekspertów i proste zasady popytu i podaży powodują, że stawki premium nie mają racji bytu. Callstack zderzył się z ścianą. Nagle lukratywne projekty na marże 80-90% nie były nawet w sferze marzeń. "Dawna” marka nadal przyciągała masę klientów, a nowa - przyciągała klientów, którzy nie chcieli płacić premium dla firmy, która w sumie nie jest dla nich premium.. bo poza React Native, Callstack nie istnieje w ich głowie w ten sposób.

To właśnie dowód na to, że silnik OSS w Callstacku jest oparty o React Native i nawet ostatnia transakcja, w której firma została sprzedana za bajeczną kwotę 0.5 mld zł nie sprawiła, że z firmy odszedł Mike. A może mógł? Wg. Mnie niestety i stety jest częścią sukcesu Callstack jako osoba kluczowa i twarz w community jego odejście wraz z transakcją byłoby nie do zaakceptowania dla nowych właścicieli Callstacka.

Czym jest OSS Growth Engine w Callstack i Rigby

Przypadek Callstack'a, w którym firma usługowa staje się kluczowym komercyjnym powiernikiem dla technologii Open Source (React Native), nie był przypadkiem. To powtarzalny wzorzec, który można zdefiniować jako Open Source Software Growth Engine (OSSGE). Jest to strategiczny model, który wyjaśnia, jak firma może zbudować pozycję lidera, opierając swój rozwój na przełomowym projekcie OSS. Jego fundamentem jest diagnoza **paradygmatu**, który dany projekt OSS przełamuje.

Diagnoza ta zaczyna się od kluczowego pytania: czyj pożar gasi ten projekt OSS – biznesu czy technologii?

Odpowiedź na to pytanie determinuje całą ścieżkę wejścia na rynek danej technologii.

W przypadku React Native mieliśmy do czynienia z Technologicznym Przełomem Paradygmatu. Pożar płonął w działach IT, a jego paliwem była nieefektywność tworzenia kodu na dwie platformy oddzielnie. W takim scenariuszu firmy na rynek głównym (czyli tym gdzie jest większość firm), składający się z pragmatycznych liderów technologicznych, nie zaadoptuje nowej technologii, dopóki nie otrzyma silnego sygnału, że jest ona bezpieczna i ma przyszłość. Ten sygnał musi pochodzić od Goryli Technologicznych – technologicznych gigantów, takich jak Meta, który swoim autorytetem i zasobami daje technologii gwarancję stabilności - kluczowa dla pragmatyków.

Kiedy Goryl daje zielone światło, cały rynek rzuca się, by zaadoptować nowy standard, tworząc Tornado – okres gwałtownego, masowego wzrostu. To właśnie w tej chwili powstaje idealna próżnia dla firmy usługowej, by stała się Gorylem Usługowym, czyli liderem szytych na miarę wdrozeń komercyjnych dla nowej technologii.

Istnieje jednak druga, równie potężna ścieżka, inicjowana przez Biznesowy Przełom Paradygmatu. W tym wariancie projekt OSS rozwiązuje głęboki, strategiczny problem dla konkretnych nisz biznesowych, tak jak robi to Medusa.js dla złożonego handlu B2B. Tutaj sygnał dla rynku musi pochodzić od Goryli Biznesowych – szanowanych liderów rynkowych, takich jak Heineken czy Mitsubishi, którzy swoim sukcesem udowadniają jej wartość biznesową.

Droga na rynek jest tu bardziej metodyczna i wymaga strategii Kręgielni, czyli zdobywania zaufania klienta nisza po niszy.

Liderstwo w oczach społeczności technologicznej danego projektu OSS jest kluczowe

Niezależnie od ścieżki, sukces w modelu OSSGE zależy od istnienia rynkowej próżni i zdolności firmy usługowej do stania się nie tylko partnerem, ale aktywnym współtwórcą i opiekunem określonej technologii OSS, co daje jej milczący mandat od rynku do zdefiniowania technicznej przyszłości. Goryl Usługowy tak długo nim pozostanie jak długo będzie animował i prowadził społeczność liderów technologicznych danego projektu OSS.

Kto jest decydentem dla Software House, który korzysta z OSS Silnika Wzrostu?

Na powyższym diagramie przedstawiłem serce Silnika OSS. Co jest bardzo istotne, rodzaj nowego paradygmatu będzie określał do kogo Goryl Usługowy (czyli Twój Software House jeśli chce użyć silnika OSS i stać się bezdyskusyjnym liderem) kieruje swoje usługi, jakim językiem mówi.

Jeśli paradygmat jest technologiczny to głównym decydentem jest lider technologiczny, który sam wybrał dany projekt OSS dla swojej firmy i teraz szuka najlepszych dróg do realizacji swojego projektu.

Jeśli nowy paradygmat pochodzi od potrzeb biznesowych, wówczas Goryl Usługowy będzie komunikował swoje usługi do decydentów biznesowych. Widać to bardzo wyraźnie gdy porównamy główne strony firm Callstack oraz Rigby.

Callstack z swoim "Your React & React Native Development Experts" brzmi bardzo...zwykle. Najcenniejsza przestrzeń na samej górze strony tłumaczy dlaczego:

przekaz jest w 100% do społeczności technicznej, która tak naprawdę ich bardzo dobrze zna. Czyta ich e-booki nt. wydajności aplikacji zbudowanych na React Native, chodzi na ich konferencje, korzysta z ich bibliotek. Każda firma, która chce zainwestować w przejście na tą technologię, a boryka się z budową takich kompetencji w swojej firmie - przyjdzie do Callstacka.

Inaczej jest z Rigby, firmy która jest wzorem Goryla Usługowego dla projektu Open Source - Medusa.js Mówi o tym sam Prezes Medusa.js.

Rigby skupia się na kliencie biznesowym, ich strona nie stawia jako główny przekaz "Medusa Experts", ona jest skupiona na dostarczeniu wartości biznesowej, a Medusa jest dla Rigby najlepszą technologią aby zrealizować ten cel.

Co interesujące, Rigby stworzyło swój własny produkt OSS o nazwie Mercur.js, który jest książkowym przykładem strategii opisanej w książce Inside the Tornado, gdzie w momencie gdy różne nisze biznesowe aplikują daną technologię, Goryl Usługowy (Rigby) dostarcza dla nich "Cały Produkt" czyli platformę do budowy marketplace'ów B2B na Medusa.js.

Mercur i Rigby są konsekwentni - nadal komunikują do decydenta biznesowego bo wiedzą, który paradygmat (biznesowy) przełamuje ich technologia. To dla wielu wydaje się drobnym detalem, ale jest to kluczowe.

To do kogo komunikujemy nasze usługi, produkty, warunkuje też jakimi spostrzeżeniami (Insights) zdobytymi z naszej pracy z tego typu klientami go edukujemy. Jeśli przełamując paradygmat biznesowy, nie rozumiejąc tego aspektu, komunikujemy wartościami technicznymi - mówimy do rynku "nie jesteśmy gotowi aby być Serwisowym Gorylem bo nie rozumiemy Was." Dopiero zespół developerski tych firm może przynieść Was na tacy do decydentów biznesowych, ale to bardzo długa i bolesna droga, podczas której zespół developerski może dojść do wniosku, że w sumie to sami mogą to zrobić za Was.

Jest jeszcze kilka miejsc gdzie OSS Growth Engine potrafi skutecznie i trwale budować przewagę konkurencyjną dla SH. Napiszę o tym w kolejnych numerach naszego biuletynu.

Po słowie

Sprawdzenie, który OSS projekt jest idealny dla danego SH oraz przeniesienie firmy z poziomu 0 do 10/10 to moja specjalizacja. Jeśli jesteś SH, który albo siedzi “na złotym jajku” czyli ma w rękach popularny projekt OSS lub chciałby skierować swój rozwój w stronę projektu OSS - zapraszam do kontaktu (mat@shgrowth.com).

Have you ever seen a beautifully crafted growth plan, maybe from a top consultant or your own C-level team, that just... fizzles out? It looks great on a whiteboard, but it fails to gain traction in the real world. This is a common and dangerous trap for many software houses.

In this episode, we're tackling a critical mistake many leaders make: building ambitious strategies based on guesswork, gut feeling, or what the competition is doing, rather than on a solid foundation of validated learning.

This isn't about having a "bad" plan; it's about the danger of committing to a plan before you've done the hard work of experimentation and discovery.

In this 14-minute deep dive, you'll learn:

• The Flaw in "Top-Down" Strategy: Why simply adopting a framework like "Playing to Win" (f.e. using such great framework for Sales Strategy) without tangible, market-validated learnings is a recipe for disaster.

• The Power of Iteration: We'll look at the "Testing Business Ideas" framework as a practical tool for moving from risky assumptions to confirmed hypotheses through a continuous cycle of design and experimentation.

• The Most Important Question to Ask: Before you commit to any growth plan, what is the single most important question you need to ask your leadership team about the "learnings" behind it?

• The Alignment Problem: Why even the most brilliant market opportunity is worthless if it doesn't align with your founding team's core capabilities and passions. We'll explore why trying to "bolt on" a new expertise, like design, often fails if it's not part of your company's DNA.

• A Simple Path Forward: Don't build a huge plan if you don't have learnings. Instead, build a simple plan to get learnings. Iterate, learn, and let a real, proven growth engine emerge from that process.

This episode is for any founder or leader who feels the pressure to have a grand strategy but suspects it might be built on shaky ground. It’s a call to embrace a more disciplined, honest, and ultimately more effective approach to growth.

We're kicking things off with a deep dive into a powerful, timely, and somewhat controversial topic. You've likely felt the shift: the market for junior developers has changed dramatically, while at the same time, companies are desperate to integrate AI into their workflows. These two trends are deeply connected.

In this episode, I break down the "AI-First Development Team" concept – a growth engine designed not just to adapt to AI, but to leverage it as a core competitive advantage. This isn't theory; it's a concrete analysis of what's happening on the ground and how you can turn it into a strategic opportunity.

In this 10-minute deep dive, you'll learn:

• The Problem: Why the old model of hiring junior developers for leverage is broken, and why senior developers are often resistant to adopting a new AI-centric toolset.

• The Contrarian Solution: The strategy of hiring smart, hungry junior talent specifically to become AI automation experts, creating a dedicated engine for innovation within your company.

• The Playbook in Action: How companies like HatchWorks AI are formalizing this into methodologies like "Generative Driven Development," and how leaders like Zapier's CEO are creating new roles for AI automation.

• The "Why": This isn't just about coding faster. It's about fundamentally changing how you scope projects, interact with clients, and deliver value at every stage of the development lifecycle.

This episode is for any software house founder or leader looking to move beyond the hype and find a practical, powerful way to make AI a core part of their growth strategy.

Yeah, that was a nice opening, like yet another piece of coaching advice. However, this is a real story, and this playbook will give you actionable steps. You can check how Callstack grew with a staggering 30% EBITDA. You might think: How did they get there? Well, it isn't magic. It's math, mindset, and a repeatable process.

The numbers from BizRaport speak for themselves:

2023:
EBITDA: 41 657 294 PLN ÷ revenue 98 200 840 PLN ≈ 42.4 %

2024:
EBITDA: 47 375 337 PLN ÷ revenue 129 620 715 PLN ≈ 36.6 %

EBITDA (Earnings Before Interest, Taxes, Depreciation, and Amortization) measures your operating profitability by excluding financing costs and non-cash charges. To hit a 40% EBITDA, you must sustain exceptionally high operating margins that both cover all expenses and still leave ample room for that level of earnings.

These aren't just impressive figures - they represent a systematic approach to building a highly profitable software business. While many software houses struggle to break 20% margins, companies like Callstack have consistently delivered exceptional profitability while scaling their revenue. This playbook will show you how they and others have done it, and more importantly, how you can apply these same principles to your software business.

8 Common Reasons Why Software Houses Fail to Achieve High Margins

Before we unpack the specific plays, I noticed one eye-opening pattern in most software houses that reached out to me for consulting. Their hourly rates are surprisingly low, effectively cutting themselves off from high-margin opportunities.

Why does this happen? Here are the 8 biggest culprits:

1. Local market: They started from the local market and couldn't find a good reason to ask for a premium price. They're afraid that when they propose a higher rate, they hear, "Well, I can hire such a person instead."

2. Body leasing: Since they only offered remote developers hired through their agency, they could add a small margin on their rate; bigger ones were hard to justify.

3. Purposely competing on price: Fearing they'll lose on price, they start low with their prices and never get to the best deals.

4. Fear of losing a deal: They would rather win a low-margin project to keep his long-lasting employee in the company, but forget about the maintenance cost and their operations capacity that is spread too thin on low-margin & high-risk projects.

5. Fear of rising rates: Same as above, but this time avoiding rising rates, although everything rose and inflation ate a huge chunk of their margin already.

6. Walking dead: Running a software house on low margins usually leads to a walking dead mode. You wake up in the morning running for pennies, and you close your laptop with more troubles. This mode leads to a poor decision-making process and a search for “growth hacks/quick wins” which leads the Software House into a limbo of unfinished initiatives.

7. Big client: Having one big client blinded them. They eat their margin, and suddenly, find themselve in an unpleasant place - be acquire-hired or start actually selling their services to others?

8. Fixed-price projects. Tey began with fixed-price projects to secure the deal. Unfortunately, in many cases, they misestimate the required effort and apply only slim margins to the final price. Note: Selling fixed-price projects can be an ideal way to achieve up to 90% margins—I’ll show you how.

The above reasons are blinding the software house founders. They feel they live in a bubble they can't escape. They have no arguments to win this battle. It is sometimes just too hard to watch how they struggle every day.

Fortunately, many software companies have strong reasons to charge more. They deliver great value to their clients, but they overlook that.

The "Build to Sell" Lesson - Focus Over Breadth

A great book about it, "Build to Sell" describes such drama in an agency business.

At first, the author's agency offered half a dozen services, including web development, print collateral and marketing strategy, each delivered at only average quality. Margins were razor-thin, clients found it hard to understand the agency's core strength, and staff turnover rose. In a particularly painful debrief, a lost client said, “You do everything but nothing really well.”

That wake-up call revealed the problem: being a generalist diluted their value. He chose to specialize in logo design, created a clear delivery process and focused on a specific audience. Within months, the agency had transformed into a premium logo design boutique.

This book offers a valuable lesson for any software agency owner wrestling with the jack of all trades trap. Keep in mind, however, that while logo design can serve as an effective appetizer, it typically lacks the deal size necessary for a custom software house to sustain its growth. I think it's also an excellent read for anyone who struggles in their software agency.

Playbook: Plays to Reach 90% Margins

This isn't about bullshit coaching. It's about fundamentally rethinking your value and then structuring your sales, services, and client management around it.

Play #1: The 90% Margin Litmus Test Helps in Defining New High-Value Services

Ask yourself:

"Can I architect a deal structure for a specific type of project where a 90% margin is feasible?"

It is not about cheating your clients to pay more; it's about identifying scenarios where your unique value, efficiency, or the client's alternatives make such a margin justifiable because the value delivered is immense. If the immediate answer is "no way," your current mindset is the first bottleneck.

Therefore you should use this question and reiterate with your business developers or yourself on what are the reasons you think this client will not pay so much for the service you provide. It might be that you simply can’t do that because he approached you with a low-margin request: “I need some help with my Wordpress site.”

In most cases, the answer is "No." If they need such support, this signals deeper issues, like a lack of understanding of the complexity of his business or the technology he is using.

This is a great insight into deciding how to structure your offering. Instead of saying, "Yeah, I have someone who can help you for x$/h," talk with the person and educate them on their challenges. Commercial Teaching (I'll write about it later in this Playbook) is a great tool for building an image of a premium software house in your clients' eyes.

In such a play of reiterating the "90% margin", the question will help you define new services. Instead of selling "ad-hoc Wordpress support", you could craft a monthly package of WordPress support and use your remaining skills in your team, e.g., a Project Manager who is on shift to add this as a premium SLA parameter and return to your client with a new offer in another conversation between you and them:

I see that you will continue developing your system, and the issues you face will most likely return here or there. I believe you need a partner who can be there for you and provide support on a long-term basis. Here is what I prepared for you (...)

Remember, when you calculate the cost of the service provided, try to hit the 90% margin. This can be achieved in many ways, e.g., by offering an uptime monitoring service that you already pay for or by offering a PM service that you already have. You add this all in the bundle and sell it for a premium price.

Yeah, sounds easy, but usually it's not that simple. At the end of the day, you need to realize that helping clients just on an ad-hoc basis will not make your Software House successful. You have to look at the long-term perspective on the clients. If they are stubborn and just want your short-term help, think twice before jumping on that ship. The effort needed to close small gigs, get paid for them is tremendous, and your margin will melt like ice cream in the summer.

Play #2: Uncovering Hidden Value in Your Current Projects with Total Cost of Ownership

The most money usually is in our current projects. Can we try to bump them to a 90% margin?

Most founders stop their imagination at "How can I charge a 90% margin on this developer's time?" They think, "Well, even if I put some juniors on the project, the average rate will just be around 50-60% margin; it's not possible to hit 90%." Not with that attitude. For sure.

The crucial mindset change is to:

look at the total value you provide, not just the cost of your inputs.

If you provide just good developers for hours, you might end up with 40-50% margins. The challenge here is elsewhere.

If you limit your understanding of the value you provide to your clients to the skill of a particular person on your team, you are limiting yourself dramatically. What your clients often buy is way bigger than you think. This requires a different approach anchored in understanding their Total Cost of Ownership (TCO).

You can find a nice article about how Momentum software house switched from a generic to a healthcare-specialised software agency in 6 months. They found out that for the projects in that sector:

• In healthcare projects, price pressure occurred less frequently

• Clients in this industry valued quality, reliability, and safety over cost

• Projects were more complex, which raised barriers to entry for competitors

• Collaborations were long-term in nature, rather than one-off projects

It means that they found out that focusing on specialization in healthcare allowed them to increase their impact on their clients' Total Cost of Ownership. They saw an increase in the average rate from 45-50 USD to 65 USD an hour. This is just the beginning of their journey to a 90% margin. However, I think they made an important step towards that goal: they changed their mindset from selling hours of engineers to delivering value.

The crucial thinking change is to look at the value you provide through the lens of Total Cost of Ownership. This concept forces you to look at a client's initiative from their highest possible view - how much new software will cost their organization to develop, maintain, expand, host, and care for legal aspects and security over its entire lifecycle. TCO is the ultimate north star of this mindset change. It allows you to find all possible venues of potential value drivers in your client's eyes.

Going back to your current projects…

Total Cost of Ownership is mitigated by the companies in many ways, but here are some very popular:

• using off-shelf solutions

• using existing team expertise to build custom software maintained by them

• buying external services to deliver one of the above

• reducing complexity of the systems by integrating them in new way and removing steps in the process

• buying company that has the team and software needed

• building off-shore/near-shore subsidiaries and move to them the operations and accompanying software

• trainings on the best practices how to use the off-shelf solutions

• hiring experts that can be cheaper and work in-house for them

Now, look at the system you develop for your client and all surrounding systems.

Ask yourself if your client can mitigate the TCO of the system you develop using any of the above techniques?

Using the above list you can find "black swans" - term coined by Christopher Voss, an author of the "Never Split the Difference: Negotiating as if Your Life Depended on It" book, where he explains that a black swan is knowledge about your negotiation opponent that changes their negotiation position dramatically and justify high-margin engagements. What are the common “black swans”:

• Your expertise and knowledge on the system complexity is so high that any attempts in on-boarding new “in-house” members by the client failed. Of course not because of your active actions but because of the complexity, DNA of your company that curates experts in this domain, process knowledge, communication barriers.

• the system itself is “legacy” for others and “known” to you and it is very hard to find new people to join the project unless it’s your way of onboarding them.

• the system is hosted, maintained by your team and none on the client side actually knows how to assure business continuity without you

• the company tried to build off-shore presence but failed due to lack of focus/budget

• your system is already simplifying the work for your client and is vital part of their software, is not easily replaceable

It is your responsibility to align your pricing with the immense value and risk mitigation you provide. This might involve a respectful but firm conversation about the strategic partnership's value.

Ask yourself a question:

Finding black swans can work both ways, though. If you realize that your core value is in one person with great relationships with your client's team, you can quickly end up in hard talks about "buying out" your crucial team member.

These are “black swans” of your collaboration with them and should be treated with great attention. When a client tries to buy out your crucial team members, it's a signal that they want to reduce the dependency on you and look into seriously limiting an engagement with your company.

Don't get fouled by “promising new projects” around the corner, “but we just need your colleague to be part of our organization, in other way we can’t unlock it.”

Play #3: Be a Business Consultant

Another angle is to use TCO to find places where your client naturally needs you to step up and contribute more.

A good example is when you have a great relationship with key stakeholders on the client side, but you keep asking them for a "new project". You walk around them, have great talks, but they keep saying, "We need more time to think about it, we will get back to you in the next quarter."

Instead of waiting, look at the Total Cost of Ownership of your client's current systems. You know a big set of them from your team. You might find places where they miss a crucial person who can pull off new initiatives. The ownership is divided between your team and theirs, with neither having the capacity to bring new initiatives to life.

Putting another pair of eyes on the project, someone who looks from the business perspective and from the broader perspective as an owner of the system, you find a vast set of new features, business concepts, and improvements you can challenge with your stakeholders.

What works very well here is to create a map of people on the client side and craft their main Jobs to be Done. A great article about it written by it’s author can be found here.

Thanks to AI, you can now feed it to your preferred AI model and prompt:

#Prompt 1 of 4
Act as Tony Ulwick (Jobs-to-be-Done), with the lens of a Software-House Business Developer.

I’ll give you:

A brief system description (features built, upcoming milestones).

A list of client stakeholders.

Your tasks:

For each stakeholder, use Ulwick’s template:

When [context], I want [action], so I can [outcome].
Identify their functional, emotional and social jobs.

Ground each job in our current technical progress and strategic timing.

For every job, propose 1–2 business opportunities (new modules, integrations, partnerships, GTM concepts) that fit our roadmap.

Such business opportunities open up a new type of conversation with upper management of your clients. Such conversations have to be value-driven, which means that they should be oriented around what kind of value you can bring to your client, taking into account their current and nearest business objectives and their respective JTBD (Jobs To Be Done).

Here is an example of ChatGPT, where I use the above prompt to discover new opportunities for a sample client. As you can see, the proposed opportunities might fall too far or too near the current business objectives. Your role is to provide as much data as possible. When you feel the proposed opportunities are so good that you can actually take them to the client's stakeholders, the big question is: How do you do it?

Another great book can help us in this process: The Mom Test. It is a great framework for conversations with clients that enables you to avoid being too sales-oriented, narrow-minded, or attached to your beliefs. Below is a next prompt that you should use as a follow-up of our JTBD conversation:

#Prompt 2 of 4

Using Mom Test principles help me in validating the above Opportunity Proposals

This prompt will instantly convert the Opportunities Proposals from the first prompt into projects or services with questions that trigger your stakeholder attention and validate their desire to pursue that path or not.

Secondly, you have to understand that to win such new projects discovered using the Business Consultant approach, you might go through an earlier sales funnel than you usually do. Why is it so?

Play #4: Build new services to get early in the process

Every project in a bigger organization goes through a few stages before it rolls out as a full-scale custom software development endeavor. It has to be discovered by upper management and researched internally. The findings sometimes have to be verified with external service providers (you!) in small projects that could seem like a "waste of time” to many software houses. It might be a PoC project or even something way smaller, e.g., Copilot training or UI Path training. You might think "this is not my specialization, I’m not good in trainings", yep, that could be a good reason to reject such an opportunity. However, down the line, the agency that will sell this training will gain insights into your client's problems outside your current project scope. They will be in touch with your stakeholders much sooner, having a huge advantage over you - they are teaching your client how to use the new tool to address their upcoming business objectives.

This is just an example, but the play is more generic. To discover new projects for your current clients, you have to be open to creating new services. Not to get spread too thin with your offering, but to learn one crucial truth:

This exercise with your client's stakeholders to discover the broader scope of the system, looking from the point of view of their business objectives, enables you to specialize in a new set of lucrative services. You might learn that your software house, which you thought has a core unique selling point in RPA, actually can build a great business around selling training because this is an easy door opener for much bigger deals. Just don't close your eyes to it.

Will this spread you too thin? If the new service leads to your core offering, no. If na new service has no direct implication on your core service, you must reconsider how significant an investment it is for you and in most cases, reject this opportunity. The crucial thing here is:

Therefore, continuing our example GPT, let's use the following prompt:

#Prompt 3 of 4

My software house specializes in [your specialization], the above business opportunities and corresponding experiments is a lot of work and assuming the client sees value in one or a few of them, instead of doing them upfront, I would like to sell it as productized service (a service with defined scope, result and price). I still want to follow JBTD and Mom Test approach, just move the burden of validating towards the client. Can you help me in reframing the above experiments in such way that we keep our principles but we shift the effort further and we firstly get client buy-in?

The result is surprising. You get a list of well-shaped productized services ready to be pitched to your stakeholders!

But how to pitch it?

#Prompt 4 of 4 

I like productized-service no [select the number], how shall I approach my stakeholder following Mom Test principles?

The above prompt (as a continuation of previous ones) will result in a well-drafted frame for a meeting where you know:

• How to open it

• How to measure the demand

• How to steer the conversation towards your newly created service

I encourage you to experiment with new services because you are:

• Breaking out from the current development cycle

• Jumping into new areas

• Shifting your client's perception of you

• Being ahead of others

Of course, the devil is in the details. You must judge how well you can deliver the newly crafted productized service. If, for instance, the producized service will lead you to an entirely new set of technologies (e.g., ready systems vs custom ones), you might end up positioning yourself as an expert in a new, gigantic domain.

In moments like this, think outside the box and tap into your network of companies and individuals who can help you deliver this new service. The last thing you want is to hand a “warm, ready-to-buy” client over to an unknown company with a slick website shouting, “We are experts in X.”

Even if you partner with someone to launch a finely crafted, productized service, remember to own the process and the big picture - and keep the client close to your company.

Play #5: Look for Gold Peanuts - The "Hero" Fixed-Price Model

I mentioned the Fixed Price model as one of the main reasons for low margins. Many software houses have abandoned it after terrible experiences, and it can even kill a business. Yet it is also a powerful way to capture the true value of your service and command high margins.

This works when clients overestimate the total cost of ownership. They approach you thinking a project will cost far more than it actually does because they lack deep technical insight or because you have (ethically) educated them on the complexities they’d face if they went it alone. Without your specialized skills, years of experience, or proprietary methods and reusable components, the project looks massive to them.

For you, though? It is peanuts.

Gold peanuts.

This is the sweet spot for high-margin fixed-price work.

How to Execute the "Hero Fixed-Price" Play:

• Identify "Gold Peanut" Opportunities: Look for projects where clients warn, “This is a massive undertaking for us,” yet you know you have a proven, ultra-efficient solution.

• Anchor on Their Perceived Value/Alternative Costs: Explore their alternatives: internal build estimates, bids from less-specialized firms—and position your fixed price as a bargain by comparison.

• Structure with Phased Value Delivery: Break the work into milestones that each unlocks a portion of the total value. Some phases may absorb most of your effort but deliver outsized client impact.

• Deliver with Grace, On Time, and Premium Service: YYour communication, regular updates, and expectation-setting are part of the high-end experience. Share timely status reports, run bi-weekly demos, and manage the project professionally.

• Never Mention Hourly Rates: To the client, the rate isn't the argument. The value behind the project is vastly bigger than your fixed price. The alternatives are all far more expensive or risky. This is what matters. You charge a fixed price, deliver excellently, and the client is in heaven because they got immense value. You are in heaven because you're earning a 90% margin that gives you space to innovate and improve.

The checklist above is essential. Your workflow with these clients shifts - project management changes, internal communication adapts, and everyone on the team must understand we’re in a fixed-price model. If a client requests new features, the team should immediately escalate to the PM or Account Manager, who can, with grace, discuss scope changes and turn them into upsell opportunities.

Sounds simple. But where is the trap?

In a fixed-price engagement, your greatest effort goes into teaching the client what’s in—and what’s out—of scope, using clear logic and courtesy. If you ever have to say, “That’s hard to estimate,” you’re on shaky ground. A strong fixed-price proposal has one hallmark: a naturally well-shaped scope of work.

If your offer leaves too many loose ends zones and you tell to your client “we’ll cover that later in a separate SOW” you’ll end up negotiating forever.

Play #6: Discover places where client overestimates Total Cost of Ownership

Sometimes you’re sitting on a gold mine. Your reputation can be unbeatable in a specific segment - thanks to your marquee clients, niche expertise, proprietary software or business know-how, and relationships with the right decision-makers. When clients look at your track record, they assume that even at your top consulting rates, their total cost of ownership will still be lower than working with cheaper, less capable agencies or hiring and training in-house staff.

Case in Point: Callstack

They sell what’s essentially a commodity - React Native consulting - but they’ve built a powerful premium brand. Despite many competitors, Callstack reached roughly 40 percent EBITDA. That margin isn’t generated by developers alone - it must cover operations, sales, marketing, project management, software licenses, hardware and R&D. To net 40 percent EBITDA, you need exceptional rates.

From a Polish cost base, here’s a quick back-of-the-envelope:

• Mid-level React Native developer salary: 14 000 PLN/month (~3 500 USD)

• Billable hours/month: 154 (inc. paid holidays) ⇒ about $22/hour cost

• To hit 90 percent margin: you’d have to charge $220/hour

That’s unrealistic without a top-tier brand. Callstack achieved it by positioning itself as the market leader co-hosting a React Native conference with Meta, producing high-value e-books, and having their own developers evangelize best practices. Their prospects’ in-house teams already read Callstack content daily and speak highly of their experts.

Look for the same signals in your niche:

• Client developers reference your blog posts or open-source projects.

• They expect a “wow” from the very first interaction.

• They want you to look-and be-expensive.

This requires a "face" in the whole process - someone who:

• Has a strong opinion

• Is known by the community

• Has a strong track record (contributions to OSS)

That person projects the premium impression. Behind them, a skilled business developer nurtures the relationship, signals expertise, and identifies broader business needs.

Callstack embodies this strategy through key figures who combine deep technical authority with community leadership - making their premium-price “hero” model not just viable, but irresistible.

Key OSS Figures as Brand Ambassadors

• Mike Grabowski - His contributions to facebook/react-native and microsoft/react-native-code-push with 130,000 GitHub stars combined, making his name instantly recognizable to any RN developer

• Michał Pierzchała - Built his reputation as the testing and performance authority through his work on Jest (44.7k stars), becoming the go-to expert developers trust for best practices

• Satyajit Sahoo - With 2.4k GitHub followers and libraries like react-native-tab-view used in thousands of projects, he represents the modern face of React Native innovation

When potential clients see these names on your proposal, they know they’re not just hiring another development shop but getting direct access to the people who built the tools their teams rely on.

Behind the scenes, you need a systematic delivery engine:

• A lead consultant who owns the process and maintains the premium impression.

• Cost-effective team members who execute each step under that consultant’s guidance.

• A brand and account-management approach that together enable 90 % target margins. Even after back-office, marketing and shareholder costs, this yields impressive EBITDA.

Callstack’s GitHub stars add up to 13.7 k + 1.7 k + 3.2 k + 3 k + 3 k + 1.1 k, for a total of 25.7 k stars. That level of visibility drives tens of thousands of dollars’ worth of traffic every month. Their open-source growth engine, built on the repositories they own and the projects they contribute to. Forms the top of their marketing funnel and creates massive leverage.

Your agency might not yet have such an extensive OSS portfolio, but even a handful of well-targeted projects in your niche can set you apart from 99.9 % of competitors.

Watch for signals that clients are overestimating your value:

• have your clients ever negotiated with you on the price?

• Are they unusually enthusiastic about your price-to-value ratio?

• Do they come to you for broader business advice, not just software?

• Have they invited you to industry events where no other software agency is present?

Those are clear signs they view you as a strategic partner rather than just a vendor.

I’ve been in situations where a client’s unexpected enthusiasm revealed that I’d underpriced my offer. Afterward, I revisited my proposal and confidently increased my margin.

Play #7: Contract project in phases tightly connected to delivered value

You can think of it as small fixed-price projects. Several of them are phased in the Statement of Work. The key here is to look at every phase as an opportunity to maximize the margin by understanding the value of this phase in your client's eyes. Your specialization and reusability can significantly reduce the risk of incorrect cost estimations. Phasing this in small “fixed-price” projects assures you don’t fall into too big troubles if something is omitted.

Let's give you an example. A regular division of phases in a project will look like this:

• Discovery & estimation session, two weeks

• Building project framework and environment, two weeks

• [X, Y, Z] user story/feature shipped - MVP v 0.1, two-week sprint

• [X, Y ,Z] user story/feature shipped - MVP v 0.2, two-week sprint

Instead, look from the perspective of value delivered to your client.

• Validated user interface, including cost estimation

  • 1 week for client acceptance

• Crucial workflow x/y/zis ready for review on a staging environment

  • 1 week for client acceptance

• Validating the workflows with pilot users

  • 2 weeks for the client and his users

• Pilot launch

  • 4 weeks

The first example shows your perspective on the project, where keeping the team busy is most important to you in order to reduce operational costs.

The second example shows that you understand your client's perspective. It makes realistic assumptions about his time to react and his business objectives. It also gives space for a premium price.

Play #8: Use Challenger Sale to shift talk from hours to value

A few weeks ago, I had a great conversation on LinkedIn with Michael Grubka, CEO of Apropo, who wrote a very popular article about hourly rates.

Long story short: Specialized software houses charge around 280 PLN/h (approximately $70/h), while generic firms offer services for just $50/h. Despite the higher rates, these specialized companies often win projects because clients are willing to pay a premium for their domain-specific expertise and proven experience in the field.

My comment triggered a discussion about a different way of looking at rates. Instead of aiming for the highest rates, we should aim for the highest margins. Michael wrote, "The best companies with the highest EBITDAs are the ones that very often sell fixed-price projects."

Bingo! I'm not delusional. My experience is not an exception. It's a pattern.

What is the most important thing you need to do? Stop talking about rates. Period.

So, what can you do if your prospect asks you about hourly rates?

I've created a GPT for you. You can access it here. It uses publicly available Challenger Sales excerpts and is sprinkled with my prompts to make it more accurate for software houses. In essence, it helps you turn the talk from rates to the real value you deliver. You have to reposition yourself in the eyes of your clients from the very beginning.

Here is an example chat with our GPTS. You can see how our AI tries to reframe the conversation from “hourly rate” to value-based. You can notice how, by providing context about the client and our company, the GPTS tune the message and focus on Challenger Sale methodology.

The most important value of this tool is that you are not alone in your mindset change. The prompt will help you find arguments to talk with your clients differently in challenging moments.

Many business books advise here to talk about their problems, but this is not enough:

Stop that nonsense. Let's talk a bit about your project. If your prospect does not have time to explain his situation, you might be in touch with the wrong person or just with someone who already knows what he is looking for: the cheapest offer. In The Challenger Sale book, they pinpoint exactly this challenge: if there are no differentiators, the only one becomes the price.

Fortunately, many clients are not that tight to the "show me your rates" request. They are keen on explaining their situation in a broader context:

• So, how is this project already going?

• Is it part of something bigger?

• What is your company's core business?

• What is your team size?

In the responses you receive from your clients via emails and on the calls supported by Challenger Sale GPT, you slowly draft a picture of client’s business. You start to understand that their money is much bigger. They have a great "90% margin" business themselves.

That's what you are looking for.

However, you can also learn the opposite:

• Their business is not in really good shape

• They are in a very aggressive market, and their own USP is quite hectic

• The people you talk with are B-players, you see their actions, answers, and you feel that

• They are not open to talking about their actual business situation

• There is no cultural fit, no flow between you and them

You have to pause for a moment. If you have these or similar signals, even if you manage to reframe the deal into a 90% margin, you have to be sure of one thing: it won't be easy to deliver because they will challenge you, provide hectic requirements, play you, or even try to cheat.

You have to be cautious and prioritize such deals that actually, using the Challenger Sale process gives you confidence that they are in good business, because when they are in good business, your 90% margin play might have enough room to roll out.

Play #9: Capture the high-trust window and tailor your product to your client's needs on the fly

Here is another crucial mindset change: You are the product.

You have to understand that people buy from people. Harvard Business School research reveals that emotions drive up to 95% of purchasing decisions, even in B2B environments. While business decisions appear data-driven and ROI-focused, underlying emotions like trust, confidence, and perceived risk are the real drivers. They are building their decision process on many factors, but when they open up to you emotionally, they become less analytical and more feeling-driven. The emotions behind the areas you uncover in front of them are strong - they feel fear, they feel tension, they know they could do better.

If you can capture that trust by asking the right questions and building the right relationship, you become (for a moment) a product. As Yale Insights research shows, decisions made on the basis of feelings hold up longer in the face of new information than decisions made deliberately and rationally - meaning when you win emotionally, you win durably.

This moment does not last forever, especially in bigger companies. The emotions cool down, and the founder starts analysis once more, seeks confirmation in your offering, tries to ask more complex questions, and validates you. But this is the time that allows you to improve or even build your new service or services. I call it "high-trust window."

You know that you take a calculated risk. Either the client buys from you on a 90% margin and you have to deliver a new promise and most likely eat up a bit of the margin, or you just sit and see how this business opportunity runs away from you.

The Reality of Sales Meetings

So, how do you do such sales talk? Look at the article: Why We Sell Ourselves for Free and Get Upset with Clients When They Don't Buy Anything.

This article teaches you how to perform the first phase of the Challenger Sale process - Commercial Teaching.

The second phase is the Tailor Phase, which is exactly our play is about. You should not pitch the same old story about your company and the same old services to everyone. You must rethink the Value Drivers, the kind of Organisation you deal with (DNA), and the Emotional Impact on the fly.

Drafting such a new offer is material for a new playbook. However, the crucial mindset change is as follows: use the trust window to redesign your service, keeping in mind the 90% margin goal and the maximum value delivered to your client.

The above stories aim to uncover one crucial thing in our 90% margin playbook:

Know your value.

You'll need to repeat to yourself daily what your unique selling point is and the value you give to your clients that you are very specific about. You can't get distracted by "prospects" who come and say that you are too expensive. They might be right because they don't want to buy your service, but just a tiny fraction of it. The challenge here is to educate or leave them because sometimes the best educator for your client are their own mistakes.

Play #10: Focus on the long run

You know the saying "Stay hungry, stay foolish", a famous quote popularized by Steve Jobs in his 2005 Stanford commencement speech. I often see this approach on the sales calls where Software Houses try to close the deal too fast because they are frustrated by endless calls with hesitant prospects.They are not willing to invest in yet another free consulting call. This mindset of brutally qualifying leads not based on the potential but based on the actual, direct business value is short-sighted.

BANT is not always your friend

Probably you know this lead-qualifying technique where we assess Budget, Authority, Needs, and Timeline for a given prospect. It’s a great way to gauge the actual state of the prospect’s buying process and your position in it; however, just relying on BANT can extremely harm your business. What’s very important is to also score the prospect on its alignment with your ICP (Ideal Customer Profile) and its Buying Committee. An example:

You’re in talks with a Director of Technology at a big corporation of about 5,000 people. His current situation is a bit weak - he doesn’t have much budget but must solve a crucial pain point in their custom software.

Looking from the BANT perspective: budget is small, the person has authority, need, and timeline, but the deal size is too small for you to engage. You already see similar projects you had in the past where for months you’d fix some small piece of software for a friend or a tiny company.

It’s clear that this Director of Technology has significant decision power in his organization. He simply doesn’t have a proper decision window to push a new project through right now - but that doesn’t mean he won’t have one six months from now. The small project he’s talking with you about is a starter. He’s learning how you work with him, if you’re trustworthy, and - most importantly - whether you can solve his problem.

I’ve been embarrassed a few times seeing founders kill a relationship with a vast, promising company because they failed to realize how the “big boys” play.

Again, doing business with big corporations is very different from startups (that’s a topic for another playbook), but what’s essential to understand is that you have to score your leads and business relationships on their long-run potential.

Your mindset should always look at a realistic but ambitious long-run perspective. If you don’t have time for such investments, pass it to someone who can spend the time and conduct Commercial Teaching - just keep yourself in the loop. Be there; you’ll be surprised how often just being part of the process teaches you so many new things and opens possibilities you’d never have thought of.

Imagine the worst-case scenario

At the beginning of this playbook, I wrote eight reasons companies keep low rates. They’re all rooted in one thing: fear. Even when you apply the above 9 plays and understand your real value, you still have to face that fear.

What helps is visualising the worst-case scenario. It sounds simple, but breaking it down makes your emotions less likely to influence your decisions. You can prepare for the bad scenario or acknowledge with the other stakeholders the calculated risk you’re taking to turn the tables. This will shift your relationship with your client into a space where you can take a deep breath and start building your Growth Engine.

I often fall into that trap:

• “What if the client starts to look for another vendor?”

• “What if our deal is rejected and we have people on the bench?”

• “What if we underestimated the effort needed in this fixed-price project offer?”

All these questions are totally valid. Instead of muting them, write them down and take a realistic look at what you can lose and what you can gain. Write it down, share it with your shareholders, and keep it in the back of your notes when you talk with your clients.

Conclusion

Each play discovers the hidden gems you might already have in your software house.

• Play #1 uncovers side services that are at your fingertips.

• Play #2 broadens your view of your clients with TCO.

• Play #3 scales your value by shifting your role to that of a business consultant.

• Play #4 uncovers how you can open new opportunities if you get in early in the decision process with a new set of services.

• Play #5 turns your eyes toward your know-how and opens you to a new way of looking at fixed-price projects.

• Play #6 uncovers a hidden gem in your team and brand—how your client can be intimidated by it and pay the premium for it.

• Play #7 shows you how to structure your offer into value-driven phases so you can sell it at a premium rate.

• Play #8 shows you how to talk with new prospects using Challenger Sale in a way that reframes your relationship from hours to value.

• Play #9 shows you that sometimes you are the product, and leveraging that allows you to draft new, high-value services on the fly.

• Play #10 shows you how simply changing your approach to your clients will change how they perceive you and ultimately lead to higher-margin deals.

There are more plays to come. The above ones aim to show you the many places your current software house can search to maximize its margins without a huge shift in the Unique Selling Proposition.

These plays can dramatically change your financial situation and help you reach your highest level of contribution to your clients. However, there are more levels to achieve. If you look deeper into your company - your team, values, drivers, unique offer, passion, and knowledge - you can use that to discover a potential Growth Engine: a growth engine that allows you to specialize in the eyes of your clients and hit even higher valuations, better deals, and, most importantly, deliver superior value to your clients.

This is an english and updated version of original polish article written in SH Growth Engine.

You're about to kick off another meeting with a prospect who, on paper, looks promising. The company fits your ICP (Ideal Customer Profile), and the person, at least on LinkedIn, appears to be a decision-maker. The agenda? A chat about your case study that featured a CTA like "Let's talk about your project."

You're all set.

You've come armed with notes, a slick presentation, and you're holding back the pricing details until the end. You try to showcase your expertise while concealing that you did the same case study project two years ago, and it fell through because the client bailed at the last minute, leaving some unresolved issues. Throughout the conversation, you're scanning for any objections, mapping the client to your sales process, and figuring out which stage of their buying journey. After 45 minutes of chatting, you're left wondering what's next. The client asked about the past project but never broached pricing, and you're hesitant to jump the gun. So you ask: "What's your next step?"

After a moment's thought, the client says the famous Hollywood theme:

When you timidly ask when you might expect a response, you hear, “He's on vacation right now; perhaps we'll know more when he returns." You exchange well wishes for the week, and the call wraps up.

Back at your desk, you pore over your notes, trying to summarize the call and honestly evaluate the BANT criteria. Soon, you start to rationalize:

• Budget: Well, they did mention they already have a budget planned for this year and have set something aside for this project, so “B” checks out.

• Authority: You spoke with the department director, who mentioned that talking to the C-level is more formal, so “A” is also in the bag.

• Need: Do they have a need? Absolutely! They recited how they currently operate and what needs to change, so they definitely need our software.

• Timeline: This is the tricky part. “This year” isn't very concrete, but hey, I've got BAN, just missing the T. So you log the deal into Pipedrive as “hot” to ensure you follow up every morning with your team and push it forward.

This scenario has probably played out for many of you, including me. As you read it, you're likely already thinking about what could've been done better. Perhaps you should have pressed harder about budget and timeline, or asked that question:

Maybe you needed to delve deeper into objections…there are so many things you can do better!

Three Important Truths About Client Interactions in Sales

1. None is on this call for fun

Neither you nor the prospect is on this call just for fun. The act of someone devoting their time (especially someone labelled “A”) is a strong signal. They need something. Often, our "A prospects” aren't just after advice; under the guise of asking questions about your experience, they're analyzing whether you're the right partner for them. It's about how you talk about your projects, whether you signal "We did this for that client.” or "We build these systems for market X; this project was for client Z." The prospect showed up because they preliminarily valued you enough to spare their time. That's the foundation.

2. Your client knows less than you

Assume that in 90% of cases, your potential clients don't fully grasp the problem you solved for another company. I've often seen the need to justify ourselves, a sort of anxious, even condescending portrayal of our company as "still learning, with interesting experience, but with a long road ahead." Don't do that. First, because “Mr. A” came to you because he believes you're worth his time, playing a weak card tells him, "You're mistaken; we're still just learning." Second, as I mentioned, most potential clients start from a low awareness level, and your existing knowledge is far more valuable than you might think.

3. You are not in the right seller profile

We want to be natural on the call. We want to feel comfortable with ourselves, therefore we don't care about our hat or profile we wear on the call. Unfortunately there is a dramatic difference in the efficiency of your sales activities if you are in the wrong profile. "The Challenger Sales" book documented a few seller profiles:

• The Hard Worker. Goes the extra mile, doesn’t give up easily, is self-motivated and likes feedback and development.

• The Relationship Builder. Builds strong customer advocates, generates customer loyalty, is generous with giving their time to help others and gets along with everyone.

• The Lone Wolf. Follows their own instincts, is self-assured and independent.

• The Problem Solver. Is reliable, ensures all of their customer’s problems are solved and is detail-oriented.

• The Challenger. Has a different view of the world, understands the customer’s business, loves to debate, pushes the customer to get out of their comfort zone.

Check your seller profile. If you're anything other than "The Challenger,” consider why you approach meetings the way you do.

In my case over the years, I've primarily been a natural Challenger, though I sometimes slipped into "The Hard Worker" and tried to win the client heart with extreme ownership on their project. Thanks to my natural knack for developing new concepts on the fly, I smoothly transitioned between these styles but being a Challenger is more than just tossing out creative ideas. It's a process where we deliberately use our experience from previous client pains, similar to our current prospects, to shift their perception of their situation.

The “Challenger Sale” methodology consist from three stages:

In this article we focus on the Teaching stage because this is the very first place where most of Sales people in Software Houses make biggest mistakes.

The Warmer: Setting the Stage

In the "Challenger Sale" methodology, the Teaching phase begins with "The Warmer." It's a somewhat misleading term because many interpret it as simply getting the client to feel comfortable with you. This often leads salespeople to fall into the "Relationship Builder" profile, which isn't the intent.

Effective warming isn't about building rapport through casual jokes or finding common LinkedIn connections. Instead, try these tactical approaches:

• Research roles thoroughly before the call. When introductions begin, verify what you've learned against what they share. If there's a discrepancy, ask a question that demonstrates your understanding of their position in both the process and organization. For example: "I noticed on LinkedIn that your company is building a new team. I imagine your role involves deciding whether to develop internally or bring in external expertise?"

• Demonstrate business intelligence. After introductions, strategically reference your research by discussing their business model and how you believe they're looking to enhance it with your assistance. For instance: "I see you're expanding into several new markets. Is this discussion focused on adapting your system for the Brazilian launch?"

Even if the prospect responds with "No, we're actually..." you've already elevated the conversation. You've moved beyond discussing immediate steps to establishing a broader perspective. This creates the latitude needed to identify the frame they've placed you in, grasp it, and effectively reframe it.

The goal isn't to build a friendship - it's to establish yourself as a knowledgeable equal who has done their homework and understands the business context. This foundation makes your upcoming insights and challenges far more credible and impactful.

Draw a New Frame

Again, in 90% of cases, your prospect isn't fully aware of how dire their situation really is. By showing them the bigger picture, uncovering deeper connections and their impact on the company and their role, you open them up to new possibilities and solutions. This is the so-called "reframe" stage, where the goal is to anchor them with one pivotal insight that opens up a broader or entirely new horizon.

The "Challenger Sale" methodology offers several reframing techniques: connecting to larger business problems, revealing hidden costs, identifying future risks. But how do you get into those topics so quickly? Remember the first lesson: no one is on this call for fun. They are highly paid executives who sit in front of you (most likely virtually) because in the back of their head there is this "big thing" that keeps them awake.

What works for me is using The Warmer stage, especially the "business model discussion," to identify what kind of business objectives your client has. Keeping the high latitude I've gained after properly setting up The Warmer phase, I keep wondering in the sky with them, looking at their challenges like small buildings from an airplane, trying to find their place in this picture.

Almost every day I have such calls with clients, and eventually all reframing techniques from the "Challenger Sale" methodology point to one basic question:

Why are you wasting your time with me today?

Of course you shouldn't ask this question to your client, but you should keep asking this to yourself. Every hypothesis you think of that is valid can be instantly verified by simply dragging the client between questions. Often, because you're aiming for the right spot, the client is more than happy to answer. This is their reason for sitting here, and having someone who actually understands that is certainly very refreshing.

Climb the Hill and Show the View from the Top

At this point, we move into what's known as "rational drowning." This is an ethically crucial moment. We aren't trying to manipulate; we want to educate about the problem. After the reframe phase, where we help the prospect realize their issue is broader than they thought, the "rational drowning" phase anchors them to real, long-term problems- the view from the hill.

Since the prospect isn't fully aware of their issues in 90% of cases, we present them with a factual picture based on our expertise. Ethically, this is very important because we might veer into problems that aren't critical for the prospect but fit our solution. So, you need the courage to explore with the prospect whether these expanded problems truly affect their goals and needs during the rational drowning phase.

What helps is a well-crafted narrative that illustrates:

• How a previous client struggled with the same problem

• The tangible costs: wasted time, lost money, depleted resources, and inefficient processes

• The genuine pain points they experience daily

This narrative helps prospects emotionally connect with your process, even before you present your complete solution.

Notice that I've taken a similar approach in the introduction of this article and am following that methodology as I write. This is the first phase of the Challenger Sale process, which we call Commercial Teaching. As you can see, we do not give away our knowledge for free. We use our knowledge as leverage to open our client's eyes to new horizons and reposition our conversation on an equal level.

The Commercial Teaching stage also gives us insights about the Value Drivers, Organization DNA (deeply understanding the client's unique organizational culture, power structures, and decision-making processes) and Emotional Impact (individual concerns, aspirations, and pain points). The Commercial Teaching is foreplay that outlines the data you can use to tailor your offer and pitch to the client.

Here's the brutal truth: We are afraid of dynamically changing our offer during the call. We would like to sell the same thing, tell the same story, and win every time. That's where Commercial Teaching efforts can go to waste in a second. Get out of your own frame and draw a service that is a new version every time, tailored to what you've heard. It's not cheating - it's teaching your client how your service can best serve them by simply linking what you've learned to it.

You have no idea how many times I see this happening on the call. Big company, great sales guys who are just pretending to listen to you but in the back of their head I see already “Our Offer Slide no 5” opened, just waiting for me to look at it.

So, Why Do We Sell Ourselves for Free?

We don’t have many good workshops for B2B IT service salespeople in Poland. We all learn as we go. Due to our cultural baggage, we often enter meetings with the "Hard Worker," "Relationship Builder," or “Problem Solver" mindset. The issue with these approaches is that in complex B2B IT services sales, we try to win the client by giving away tons of knowledge, advice, and even help.

In doing so, we sell ourselves for free.

We assume that by helping and being brutally honest, we'll win the prospect's heart. Unfortunately, prospects need something else:

• They need a solution

• They don't want to feel like they're being tested or forced to take a risk

• They're genuinely searching for a solution, not more problems

Bombarding them with knowledge on how to solve the problem on their own doesn't help either. Either they use that knowledge to sort it out themselves, or end up even more confused.

How to Stop Giving Away Your Expertise for Free and Start Selling Your Value?

Protect Your Expertise

Don't give away the know-how to solve the problem for free. That expertise is your asset. You've honed it on past projects, often at the cost of margins, nerves, and sleepless nights. It might seem obvious to you, but it's pure gold to others.

Present Your Solution as a Process

After “rational drowning” stage, after you share a "life story" about another client (one similar to them) and assuming you hit the mark, you then present your process. This is the beginning of “Tailor Phase” of the “Challenger Sale” methodology. You don't show them just the software; you show them the process that ultimately delivers a software solution built by you.

Other important outcomes of the presented process include:

• Implementation and staff training

• Achieved KPIs

• Other needs are directly tied to the highlighted problems

This process might be broken down into 7 steps or blocks (something simple and easy to understand) that ultimately give your prospect the desired feeling, state, or result. The software is just one element.

Don’t forget to tailor it! what it means? you take all the findings from the “Commercial Teaching” phase and wrap them around the process. Example:
your client said that they are lacking tech leadership to scale their team? put an emphasis on the knowledge sharing, technical leadership, best practices of your own services. The “Tailoring Phase” is much more than this and we will follow-up in another article on it.

Avoid the "Outside Our Scope" Trap

If in your solution, you often have to say, "Oh, that's outside our scope" (for example, legal/compliance matters), assume that every time you do, it's like telling the prospect, "Don't buy from us because we don't cover that." Instead, reframe it positively:

• "Compliance with current regulations is a comprehensive service we deliver in partnership with X"

• "At the right moment, we'll guide you through that process"

Sounds better? And at the same time, you're earning a success fee.

Escape the "Friend Zone" with Prospects

I've often heard from SH salespeople that a prospect is "hopeless" because they talk a lot, but nothing ever comes of it. It's a bit like that guy stuck in the "friend zone."

The Friend Zone Analogy:

• He's head over heels for the girl, but she treats him as a "buddy"

• He cooks for her, takes her to the movies, showers her with compliments

• She appreciates it, but doesn't want a relationship

With prospects, every call is like serving them a free meal. A Challenger has the guts to say:

• "I really like you, but let's define our relationship"

• "If we're in it together, I'm ready to commit"

• "If we're just friends, let's set the rules, like splitting the bill"

Of course, you need to choose your words carefully, but to a prospect, it might sound like:

"I'm really excited about our next meeting. We're currently gathering requirements, a phase that will take a few more weeks and involve several people from our company. I'm thrilled to potentially work with your company because you're a well-known brand. But first, I'd like to establish how our investment can pay off later, for instance, when we execute a joint project. Could we discuss this further with you or the decision-maker?"

As you read this, you might think, "Great, I'm about to scare them off." If that's the case, ask yourself whether you've already lost them and are doomed to the "friend zone," while someone else is already going on "dates” with your client. Gathering requirements and creating a beautiful document, without (heaven forbid) a signed NDA protecting your IP, is nothing more than providing the client with free fodder for an RFP they might send to companies like yours.

The True Purpose of Commercial Teaching

As you can see, Commercial Teaching is all about:

• Educating the client on their problem

• Building a trust platform where they let you lead them

• Discovering data about clients’ values, DNA, and personal/emotional goals to reposition your company more towards their needs

It is NOT ABOUT teaching clients how to solve their core problem on their own. That's what you and your paid services are for.

While this article has focused on mastering the Teaching phase, remember that the complete Challenger Sale methodology continues with Tailoring (customizing your message to different stakeholders) and Taking Control (guiding the customer through the purchase process). But without a strong foundation in Commercial Teaching, the subsequent phases won't have the same impact.

Many software houses chase growth by diversifying. Neti Soft, a company I've had the pleasure of working with, took a harder, more focused path: They decided to build their Growth Engine around deep, specialized blockchain technical expertise. This singular focus hasn't just defined what they do but, critically, where and how they pursue growth trajectories.

The result? Their core team constantly travels to distant global hubs – a surprising strategy for a company specializing in perhaps the most digital technology ever created. This apparent contradiction reveals a profound truth: selecting blockchain as your technical specialization fundamentally dictates which growth trajectories will succeed.

In this newsletter, we'll unravel why this digital realm requires such an analog approach:

• First, we'll examine why specialized blockchain expertise naturally dictates specific growth paths

• Then, we'll explore how Neti Soft identifies and cultivates relationships with "whale" investors through face-to-face engagement

• Next, we'll analyze the strategic partnerships that extend their reach globally

• We'll reveal their proven approach to separating genuine innovators from hype merchants

• Finally, we'll extract practical lessons on aligning technical expertise with appropriate growth trajectories

Many software houses falter precisely because they mismatch their chosen tech engine with inappropriate trajectories or attempt to define trajectories before solidly establishing their core competency. Neti's journey demonstrates the strategic power of getting this sequence right.

Note: As you might notice, I'm switching to English from now on. I made this decision to share my content with a broader global audience. Thanks for joining me on this exciting new chapter!

The Blockchain Paradox: Digital Realm, Analog Trust

Blockchain is unique. It's not just a tech stack for specific business cases; it has birthed entire new economies and investor types. This "new universe," as I call it, operates with different mechanics: smart contracts replacing traditional company structures, ultimate transparency, and decentralized data. Anonymity can make billionaires, and new risks demand unprecedented security.

This is the crucial paradox: in the most digitized universe we know, the purely online channel is often not the optimal way to build a trusted software agency business. When identity is fluid and capital immense, how do you verify a trustworthy partner? For Neti, the answer born from their deep expertise engine is: in-person engagement to build analog trust. This is why their team is so often on the road.

Neti's Engine: Deep Blockchain Expertise Fueling Specific Trajectories

Neti's core Growth Engine is their profound and specialized Blockchain technical expertise. This isn't just knowing the tech; it's understanding its evolving applications, its security intricacies, and its unique business implications. This engine then powers several key growth trajectories:

Trajectory 1: Cultivating the "Whales" through High-Trust Engagement

The blockchain space is home to "whales" – individuals holding significant crypto wealth, often early adopters or creators of new chains. These tech-savvy investors are cautious, value deep technical discussions, and prioritize personal relationships over conventional contracts or corporate structures.

• Engine Application: Neti's deep expertise allows them to engage these whales on a technical peer level.

• Trajectory Execution: This necessitates direct, often in-person interaction at global Blockchain hubs and events. Neti's recent presence at Next Block Expo in Warsaw, Consensus2025 in Toronto and FIL Dev Summit in Brussels isn't just about visibility; it's about the nuanced, trust-building conversations that their expertise engine enables with this specific persona. This is where the "travel" becomes a strategic imperative, not just a cost.

Trajectory 2: Strategic Partnerships: Becoming the Blockchain Arm for Other SHs

Large corporations, especially in fintech, are keen to tap into blockchain's capital but often lack the specialized internal knowledge. Their Innovation Directors frequently turn to their existing, trusted (often larger, generalist) software house partners.

• Engine Application: Neti's specialized blockchain engine makes them an ideal, non-threatening partner for these larger SHs who need to deliver blockchain solutions without building the deep expertise themselves.

• Trajectory Execution: Neti actively builds these SH-to-SH relationships. Their SODA award in the "Foreign Markets" category is a testament to their success in this collaborative approach, leveraging their core engine to extend their reach via partners.

Trajectory 3: Product Incubation as an Engine Output: Neti Shield

Innovation Directors also seek "bridge" solutions that connect the conventional business world to the blockchain universe. Platforms like Ripple, which focus on payments and digital assets for financial institutions, are prime examples.

• Engine Application: Neti's deep technical expertise engine allows them not just to use platforms like Ripple, but to innovate on top of them.

• Trajectory Execution: Their recent win at the Ripple hackathon (SwissHacks 2025) with ⋮netiShield, a product aimed at more secure, stablecoin transactions, is a powerful example. ⋮netiShield is now a second, distinct engine being incubated by Neti, born directly from the expertise of their primary blockchain engine. It potently demonstrates their capabilities, attracting clients looking for solutions, not just billable hours.

Good Guys and Bad Guys in the Blockchain World: How to Tell the Difference

The blockchain startup world has its "good guys" (genuine innovators) and "bad guys" (hype merchants). Both might seek SH collaboration.

• Engine Application: Neti's deep understanding of blockchain's technical and economic realities (their "engine") helps them discern viable projects from scams.

• Trajectory Execution: For "good guys" (often funded by crypto investors and wary of traditional contracts), Neti again leverages personal relationship-building. For "bad guys," their engine's expertise helps them identify red flags (e.g., undue hurry, disinterest in technical details) and avoid engagements that could damage their reputation or lead to financial loss.

The Engine Dictates the Trajectories

Neti Soft's journey with their blockchain Growth Engine illustrates a vital principle: choosing your core specialized engine (in their case, deep blockchain technical expertise) fundamentally defines the viable and effective growth trajectories. Their global travel, their partnerships, and the incubation of products like ⋮netiShield are not random activities; they are logical extensions and applications of their central engine, tailored to the unique demands of the blockchain market.

For any software house considering a tech specialization, Growth Engine, the lesson from Neti is clear: first, build an undeniably deep and specialized core competency. Then, and only then, meticulously choose the growth trajectories that best leverage that engine in your chosen market.

In my SH Growth Engine newsletter, I've analyzed various software houses and their growth strategies. Soon, I'll organise these insights into a comprehensive Growth Engine Radar for paid subscribers. Stay tuned—this valuable resource will be available next week!

Subscribe now

W tym artykule przeanalizujemy cztery kluczowe filary, na których możesz zbudować długoterminową strategię swojego software house'u:

• Warstwa pryncypiów - najgłębsza warstwa, która dotyczy postaw założycieli, ich ambicji, przekonań i wartości;

• Koło zamachowe (flywheel) - budowanie potencjału firmy poprzez właściwe przywództwo i konfrontację z brutalną prawdą;

• Warstwa najwyższej kontrybucji (Drive) - określenie, gdzie Twój zespół daje największą wartość;

• USP i wiedza o rynku - dopracowywanie unikalnej propozycji wartości w oparciu o głębokie zrozumienie potrzeb klientów.

Na przykładzie firmy Divante, która w ciągu 7 lat przeszła drogę od lokalnego gracza do globalnej firmy wartej ponad 175 mln zł, zobaczysz, jak te filary mogą całkowicie odmienić trajektorię rozwoju Twojego software house'u.

Zebrana w tym biuletynie wiedza 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 nich nieustannie.

1. Warstwa pryncypiów (Principles Layer)

Jest to najgłębszą warstwa, która dotyczy zarówno postawy zarówno naszej, jak i naszych udziałowców. Składają się na nią ambicje, moralność (czyli przekonania i wartości), podejście do pieniędzy i ryzyka oraz inteligencja. Wiele razy widziałem, jak ta warstwa rezonowała na strategiczne decyzje. Czasem to były bardzo złe decyzje, które wynikały z mocno nieprzepracowanych wewnętrznych cech osobowości prezesa. Śmiem twierdzić, że to, czy dany SH obecnie rośnie w większości zależy właśnie od tej warstwy. Nie od rynku, tylko właśnie od tego, jakie są te głęboko zakorzenione mechanizmy.

W SH#4 poznaliscie historię Jakuba, który z dużą otwartością mówił o relacjach ze swoim wspólnikiem, który miał dużo mniejszą chęć podejmowania ryzyka. Zupełnie inaczej też podchodził do pieniędzy. Tego typu rozjazdów widziałem wiele. O chorobach w tej warstwie można napisać książkę. Skupmy się więc na tym, co mają wspólnego zdrowe firmy i ich zespoły założycielskie w tej najgłębszej wastwie.

Wspólne cechy zdrowych firm i ich założycieli

1. Osobowość

Postawa założycieli to coś, co jest często pomijane w początkowym etapie rozwoju. Szczególnie, jeśli "duży projekt" dał nam wiatru w żagle i wszyscy przez chwilę patrzą w ten sam, krótkofalowy cel. Wówczas też często następują podziały udziałów w firmie oparte na bliżej nieokreślonych zasadach. Udziałowcy starają się być wobec siebie fair, patrząc na to, co robią teraz jak na wystarczająco duży kawałek tortu i tym się między sobą dzielą.

Osobowość wychodzi dopiero potem, np.:

• gdy trzeba dopłacić do firmy,

• gdy trzeba przyznać się do oczywistego błędu,

• gdy będzie trzeba przeprosić.

Wówczas okazuje się, że w zdrowych firmach po prostu dużo się o tych sprawach mówi. To ciekawe, ale w firmach, którym doradzałem widać bardzo wyraźnie, kto z kim rozmawia na tym poziomie. Widać to w gestach, w szacunku wobec siebie, w tym, że się pracuje nad tym, aby mieć jedno zdanie.

Dążenie do jedności w zespole założycielskim jest według mnie kluczowym znakiem, że na warstwie osobowości jest dobre dopasowanie.

Amazon ma tutaj bardzo ciekawy model o nazwie "disagree and commit":

W skrócie chodzi o to, żeby dać zespołowi założycielskiemu lub odpowiedzialnemu za daną inicjatywę możliwość wyrażenia swoich obiekcji. Jedna osoba w danej inicjatywie jest decyzyjna i to ona - po wysłuchaniu i dokonaniu gruntownej analizy - decyduje. Wówczas pozostałe osoby, nawet jeśli jedna z nich ma inne zdanie, przyjmują tę decyzję jak własną i angażują się w taki sposób, że od tego momentu już działają do wspólnego celu.

Jedność często jest mylona z byciem w czymś razem. Nawet ostatnio jeden z moich partnerów biznesowych, z którym pracujemy nad nową inicjatywą zaadresował to, że mówię o naszej współpracy poprzez “moje” i “jego” biznesy. Widać, że bardzo mu zależy na tym, żebym mówił “my” zamiast “ja i Ty”. Dla mnie jedność w biznesie nie oznacza mówić “my”. Jedność oznacza być spójnym co do drogi, jaką kroczymy i jej celu. Od wielu lat widzę straszną presję na to, aby w zamian za to, że ktoś czyni mnie udziałowcem, zaczął mówić “my”. Według wynika to z lęku, że skoro dałeś komuś część swojej firmy, to teraz on powinien być w niej za wszystko odpowiedzialny. To jest bardzo przytłaczające i moim zdaniem niepotrzebne. Uważam, że to zdrowe, żeby mówić “My/Ja/Wy/Ty”. Granice w zadaniach czy procesach są bardzo ważne, bo nie ma nic gorszego niż wszyscy robiący wszystko w firmie. Skupienie na rezultatach zamiast na sztucznych granicach i procesach pozwala naturalnie kształtować się obszarom odpowiedzialności. Podejście to nazywa się Outcome Based Responsibilities (OBR).

Przykład działania OBR dla Delivery Managera w software house

Tradycyjne podejście:
Delivery Manager ma dbać o harmonogram projektu, przekazywać informacje między klientem a zespołem, zarządzać ryzykiem i pilnować budżetu. Formalnie wszystko jest zrobione: są spotkania statusowe, raporty i checklisty. Mimo to klient nie jest w pełni zadowolony - projekt się ślimaczy, komunikacja jest sztywna, a oczekiwania i dostarczane rezultaty się rozmijają.

Podejście OBR:
Delivery Manager nie jest rozliczany z samego faktu „organizowania spotkań” czy „wysyłania raportów”, a jego OBR brzmi:

„Zapewnij klientowi poczucie pełnej kontroli nad postępem projektu i wysoką satysfakcję z jakości współpracy.”

Jak to osiągnie? To jego odpowiedzialność i inicjatywa. Może:

• dostosować częstotliwość i formę komunikacji do stylu klienta,

• szybko rozwiązywać problemy zanim klient je zauważy,

• proaktywnie proponować usprawnienia,

• budować partnerską, a nie tylko formalną relację z klientem.

Kluczowy jest efekt. Nie chodzi tu o wysłanie cotygodniowego raportu PDF. Chodzi o to, że klient ma czuć, że projekt jest w dobrych rękach i przebiega zgodnie z jego oczekiwaniami.

2. Ambicje

Ambicje to coś odrębnego niż osobowość. To nie tylko cele, to obrazy bogate w emocje. Obrazy, które sami sobie wtłóczyliśmy, ale też takie, które ktoś (np. ojciec, matka, były szef, żona, dawna miłość) nam narzucił. Ambicje to coś, czym żyjemy i do czego zarówno świadomie, jak i podświadomie dążymy.

Część ambicji jest bardzo łatwa do odkrycia w sobie oraz w swoich udziałowcach. Dużo trudniej jest odkryć te podświadome oraz te, które ktoś bliski nam lub naszym wspólnikom ciągle wrzuca do głowy.

Ostatnio rozmawiałem z moim wspólnikiem i usłyszałem, że chciałby, aby biznes, który robimy przynosił mu 100 tys zł. miesięcznie pasywnego dochodu. Tego typu ambicja zaświeciła we mnie tak wiele światełek, że trudno mi było spokojnie przejść dalej do sedna rozmowy. Musiałem się zatrzymać i z nim o tym porozmawiać. Dlaczego? Bo dla mnie mój wspólnik i jego ambicje są bardzo ważne. Jeśli przedstawia mi swoją ambicję, a ja totalnie się z nią nie identyfikuję, to moim zadaniem jest wszystko zatrzymać i popracować nad naszą jednością jako wspólników.

Ambicje można bardzo łatwo komuś narzucić, na przykład dając mu tytuł. Według mnie chyba najbardziej problematyczny z nich to CTO, bo w software house oznacza jednocześnie tak wiele ról, że bardzo szybko prowadzi to lawiny nowych ambicji. Nowy CTO sam tworzy nowe definicje tego co powinien robić. Pozostali pracownicy i liderzy natomiast, mylnie rozumiejąc tytuł CTO, narzucając swoje oczekiwania na tą osobę.

3. Przekonania

Czy pracujesz z ludźmi, którzy mają bardzo mocne przekonania i nie chcą ich zmieniać, nawet w obliczu twardych dowodów? Wspólnicy powinni mieć mocne przekonania, ale też być w stanie bardzo szybko je zmieniać w obliczu nowych faktów. Można powiedzieć, że od począktu są świadomi, że ich przekonania mają swój kres (tzn. w określonym momencie mogą być błędne). Przekonania to dla mnie bardzo ważny obszar, który szybko wskazuje, czy pracuję z kimś z właściwą postawą. Przykładowo, jeśli mój wspólnik z olbrzymim przekonaniem przedstawia swoją opinię, którą po chwili musi zmienić w obliczu niepodważalnej wiedzy, to albo wyląduje z gracją (czyli podziękuje i natychmiast z niej skorzysta), albo spali się próbując brnąć błędną drogą. Przekonania dotykają także aspektu duchowości. Jeśli udziałowiec, Ty sam łączysz duchowość głęboko ze swoim życiem, to naturalnie Twoja religia będzie kształtować pewne przekonania co do tego, jak działa biznes, ludzie, jak działania, które podejmujemy należy prowadzić. Ja na przykład jestem osobą wierzącą, ale jestem też świadomy, że Bóg dał mi i każdemu z nas rolę zarządcy, po pierwsze swoim ciałem, po drugie tym, co nas otacza. Zarządzanie nie oznacza własności, bo oczywiste jest, że kiedyś to wszystko, łącznie z naszym ciałem, przestanie być pod naszym zarządem. Przekonania zatem mogą prowadzić nas i naszych udziałowców do odpowiedniego lub nie podejścia do: pieniędzy, życia czy czasu współpracy.

4. Wartości

To chyba najbardziej popularny termin, bo używany na poziomie wartosci, o jakie dba firma. Natomiast wartości na poziomie indywidualnym to po prostu hierarchia tego, co jest dla nas ważne, a co jest ważniejsze. Brzmi banalnie, ale wystarczy proste ćwiczenie, aby odkryć, że tak nie jest.

Ćwiczenie na odkrycie firmowych wartości:

Napisz na kartce, jaką hierarchię wartości powinieneś mieć i co powinno być dla Ciebie najważniejsze, a potem sprawdź, jak dużo czasu/energii/skupienia poświeciłeś tej najważniejszej wartości.

Często rozmawiam o tym z osobami zarządzającymi i w 99% przypadków słyszę westchnienie, że niestety wir codziennych spraw zaburza nam to, co jest dla nas najważniejsze. Podczas budowania firmy, wartości udziałowców są bardzo ważne. Nie muszą być identyczne, ale powinniśmy je dobrze znać.

Mi zdarzyło się zignorować to, że ewidentnie moje wartości są sprzeczne z tymi, które ma mój udziałowiec. Co więcej, moi bliscy mi nawet to pokazywali. Nie słuchałem ich, ponieważ ambicja, którą sobie narzuciłem w tym czasie przyćmiła krytyczną ocenę. Po roku i tak musiałem się z nim rozstać, bo wartości tak mocno burzyły naszą jedność jako wspólników, że nie mogliśmy dalej ze sobą pracować.

5. Inteligencja

Mamy różne rodzaje inteligencji. IQ mierzy ogólną zdolność rozumowania, logikę, analizę i szybkość uczenia się. Pozostałe aspekty inteligencji obejmują emocje, umiejętności społeczne, kreatywność, praktyczność i specjalistyczne talenty. Patrząc na budowanie firmy, IQ jest istotne, ale ważniejsza jest inteligencja emocjonalna i społeczna, a także kreatywność i praktyczność. Po prostu te pozostałe cechy inteligencji są kluczowe, aby można było z daną osobą pracować oraz aby ta osoba potrafiła rozmawiać, budować relacje z kluczowymi pracownikami i klientami. To zadziwiające, jak często udziałowcy mają podstawowe braki w tych obszarach. Otrzymują tytuł CxO i z racji braków inteligencji niezwiązanej z IQ po prostu nie są w tej roli dobrzy.

Podsumowując, warstwa pryncypiów jest najgłębszą częścią filarów naszej firmy. Ponieważ ten artykuł ma służyć jako samodzielne narzędzie do określenia filarów, to poniżej przedstawiam Wam, jak wykorzystać powyższą wiedzę do budowania trwałego fundamentu firmy.

Jak zbudować trwały fundament firmy oparty na warstwie pryncypiałów?

1. Nie próbuj zmieniać innych

Po pierwsze, nie oszukuj się, że możesz zmienić czyjąś postawę, kluczowe ambicje, przekonania czy wartości. Nie potrafimy tego zmienić u siebie, a co dopiero u naszych udziałowców. Po prostu skup się na tym, żeby jak najbardziej prawdziwie odkrywać siebie i Twoich udziałowców.

2. Określ, czy istnieją obszary utrudniające rozwój organizacji

Możecie się różnić na wielu płaszczyznach i firma może rosnąć. Natomiast są takie płaszczyzny, które zdecydowanie utrudniają rozwój organizacji. Oto przykłady:

• Zła postawa dotycząca odpowiedzialności za rezultat (OBR) połączona z ambicją bardzo szybkiego zarobku to klucz do beznadziejnego CTO, który nie dość, że dużo kasuje, to jeszcze nic konkretnego nie dowozi.

• Jeśli dla Ciebie wartością najważniejszą jest life-work balance, masz dzieci i chcesz być w ich życiu, a Twój wspólnik za najwyższą wartość uważa sukces zawodowy, któremu poświęca się bez reszty, to niestety to nie zadziała.

3. Odkryj mocne strony każdego udziałowca i podziel role w oparciu o te cechy

Niestety, ale wysokie IQ może bardzo często prowadzić do tzw. “postawy palanta”, czyli kogoś kto pozostałe obszary inteligencji zaniedbuje na tyle, że nikt nie chce z taką osobą pracować.

Kiedy ja współpracuję z założycielami SH w tym obszarze, to po poznaniu ich warstwy pryncypiów, przedstawiam im profil ich mocnych stron, na których określam ich charakter w firmie. To bardzo delikatny proces, ale mając lata doświadczenia z C-level potrafię to robić na tyle umiejętnie i z odpowiednimi argumentami, że część tych osób się słucha ;)

Przykładowo, jeśli widzę, że CEO:

• posiada wysokie IQ, ale niską inteligencję emocjonalną,

• ma w zarządzie osoby, które potrafią te braki niwelować,

• potrafi zmieniać swoje przekonania w oparciu o dane,

• ma odpowiednio ustawione ambicje, które dają przestrzeń na świadome rozwijanie firmy,

to wówczas naprawdę może on rozwinąć swój SH jako strateg i innowator. Nie będzie natomiast dobrym sprzedawcą, marketerem czy liderem zespołu technicznego.

Polecam zatem spojrzeć na postawy, ambicje, wartości, przekonania, jak na coś czego nie zmieniacie w sobie lub w innych osobach, a raczej zastanawiacie się, czy da się z tego zbudować stabilny filar firmy. Nie podążajcie też za schematami, które działają w innych organizacjach.

2. Flywheel - warstwa potencjału

Warstwa potencjału nie dotyczy tylko osób kluczowych w Twojej firmie, tak jak to jest z warstwą pryncypiów. Warstwa potencjału dotyczy zarówno ludzi, jak i Twojej firmy.

Tutaj bardzo często konsultanci biznesowi skupiają się na analizowaniu potencjału rynku, w którym jest dany SH i próbują to łączyć w jedno. Moim zdaniem to błąd. Dzięki książce “Good to Great” - która jest wynikiem wieloletniego badania setek firm, o tym jak udało im się rosnąć wbrew rynkowi - wiem, że rynek jest wtórny. Dużo ważniejsze jest to, jaki potencjał ma firma w oderwaniu od rynku. Firmy z tej książki bardzo często zmieniały zarówno usługę, produkt, jak i rynek, w którym operowały.

Autor wspomnianej książki “Good to Great” Jim Collins wraz ze swoimi badaczami wyszczególnił sześć kluczowych wniosków, które prowadzą do stworzenia tzw. koła zamachowego firmy (ang. Flywheel). To właśnie warstwa potencjału naszych filarów strategii. Wyraz “dyscyplina”, brzmi trochę “żołniersko”, bo w języku polskim kojarzy się pejoratywnie (przynajmniej mi 🙂) natomiast autor książki tak naprawdę pod tym wyrazem rozumie bardziej samodyscyplinę.

Pisze o tym wiele osób. Ostatnio na przykład Szymon Janiak trafnie zdiagnozował brak dyscypliny w pracy nad rozwojem firmy:

Wracając do książki “Good to Great”, Collins wyszczególnia tam trzy filary:

1. ludzie,

2. myśli,

3. działania,

a w każdym z nich kluczowa jest samodyscyplina.

Filar #1: Samodyscyplinowani Ludzie

Level 5 Leadership

Pierwszy filar (Disciplined People) dotyczy tzw. Level 5 Leadership. Collins w swoich badaniach doszedł do bardzo prostego wniosku:

To, z kim coś robisz jest dużo ważniejsze niż co.

Lider poziomu 5 to osoba, która łączy w sobie skrajną osobistą pokorę z niezwykłą zawodową determinacją. To skromni ludzie o niezłomnej woli, gotowi zrobić wszystko, co konieczne, by uczynić swoją firmę wielką.

Kluczowe cechy wyróżniające liderów poziomu 5

Poniżej znajdziecie zbiór cech, które w książce “Good to Great” cechowały firmy z grupy “great”:

• Ambicja skierowana na dobro firmy - ich największym celem jest pomyślność organizacji, a nie własne bogactwo czy osobista sława.

• Porywająca skromność - w odróżnieniu od liderów firm porównawczych w książce Collinsa, często skoncentrowanych na sobie, liderzy w firmach rosnących „From Good to Great” rzadko mówią o sobie.

• Niezłomna determinacja, by zrobić to, co trzeba - cechuje ich ogromna potrzeba osiągania rezultatów. Nie tolerują przeciętności i nie godzą się na podejście, że „dobre” wystarczy.

• Koń pociągowy, a nie koń pokazowy - wykazują się pracowitością i rzemieślniczą starannością, unikając światła reflektorów.

• Mentalność okna i lustra - gdy odnoszą sukces, patrzą przez „okno” i przypisują go czynnikom zewnętrznym. Gdy przychodzą porażki, spoglądają w „lustro” i biorą pełną odpowiedzialność na siebie. Co ciekawe, liderzy firm, które w badaniu zostały określone jako “good” zazwyczaj postępowali odwrotnie.

Najpierw kto, potem co (First who, then what)

Tutaj, jak widzisz, od razu wracamy do warstwy pryncypiów. To one w dużej mierze rzutują na to, czy dana osoba będzie miała potencjał bycia liderem 5-poziomu. Po co w firmie takie osoby?

Lider 5-poziomu będzie naturalnie budował mocne zespoły samodyscyplinujące się. W przeciwieństwie do liderów 4 i niższych poziomów - którzy zaczynają od wizji na firmę i wokół niej budują zespoły - liderzy 5 poziomu budują firmę wokół wybitnych liderów, którzy będą samodzielnie prowadzić firmę na dobre tory:

Jest to kluczowe, ponieważ budując firmę na takich liderach długofalowo nie będzie ona zależna od jednego “geniusza” z tysiącem pomocników. Widzieliśmy wielokrotnie, jak takie firmy wznosiły się, aby potem, wraz z odejściem lidera, powoli odchodzić w cień.

Dobrym przykładem podejścia First who, then what w SH i firmach technologicznych podzielił się Piotr Sędzik z Momentum w jednym z postów na Linkedinie:

Filar #2: Samodyscyplina Myśli

Konfrontacja brutalnych faktów

Kolejny filar to samodoscyplina myśli. Co to oznacza? W skrócie: Collins odkrył, że zespoły odnoszące największe sukcesy pozostają w ciągłej pracy nad konfrontowaniem siebie z brutalną prawdą o ich zespole, firmie, rynku, usługach i klientach. Ta ciągła konfrontacja z zimną prawdą działa jak mantra wśród dobrych zespołów. Nie oznacza to, że nie potrafią się cieszyć z postępu. Po prostu wiedzą, że nie mogą osiąść na laurach.

Samodyscyplina myśli to esencja mojej pracy z software house’ami. To właśnie w tym miejscu pracujemy nad tym, czy to, co odkryliśmy to już potencjalnie nowa linia biznesowa czy też tylko mrzonki o niej. Tutaj kluczowy dla sukcesu jest zwinny proces, który skupia się na eksperymentach i wnioskach. Nie ma tu miejsca na reklamy, zmiany strony i brandingu, to są kroki późniejsze w fazie transformacji organizacji na nowe linie biznesu. To, czego szukamy w fazie eksperymentacji i co jest spójne z książką Collinsa, to konfrontacja z brutalną i zimną prawdą, na której budujemy nowe hipotezy i pozyskujemy nową wiedzę. I tak w kółko, aż osiągniemy twarde długofalowe wnioski, które nie są dziełem przypadku, tylko dyscypliny myśli i eksperymentów.

Koncepcja jeża

To, co jest piękne w książce Collinsa, to jak bardzo ona rezonuje z warstwą pryncypiów Waszego zespołu. Collins odkrywa, że po stworzeniu zdyscyplinowanego zespołu z dobrym procesem myślowym, kluczowe jest wrócić do pryncypiów, czyli tego w czym Twój zespół jest głęboko zanurzony, w czym ma pasję i w czym może być najlepszy na świecie. Ważne jest też połączenie tego z wiedzą rynkową, ponieważ to ona potwierdza, że takie podejście daje dobry model biznesowy.

Collins nazwał to Hedgehog Concept, czyli „koncepcją jeża”, a pochodzi to ze starożytnej greckiej przypowieści:

Przypowieść tę spopularyzował filozof Isaiah Berlin w eseju „Jeż i lis”, używając jej do podziału myślicieli, według którego lisy to ci, którzy zajmują się wieloma rzeczami, a jeże skupiają się głęboko na jednej, centralnej idei.

Jim Collins wykorzystał tę metaforę w książce “Good to Great" do opisania firm odnoszących sukces, dzięki skoncentrowaniu się na jednej, kluczowej koncepcji, która leży na przecięciu trzech obszarów:

1. tego, w czym mogą być najlepsze na świecie,

2. tego, co napędza ich model ekonomiczny,

3. tego, do czego mają prawdziwą pasję.

A jak to się łączy z warstwą pryncypiów?

Twój zespół powinien znaleźć jedną rzecz, która jednoczy go na poziomie pasji, ambicji i wartości. Następnie, powinien w zdyscyplinowany sposób eksperymentować, aby skonfrontować brutalną prawdę z tym, jak chce przejść ze stanu obecnego do momentu, w którym robi coś najlepiej na świecie za naprawdę dobre pieniądze.

Ten proces może trwać lata. Przez lata możecie ze swoim zespołem eksperymentować, nawet gdy z boku może wyglądać to tak, jakby Wasza firma już się rozwijała. Jako zespół nie spoczniecie dopóki nie dojdziecie do poziomu światowego, bo wiecie, że miejsce, w którym drążycie ma olbrzymi potencjał.

To też jest niesamowicie ważne. Musicie mieć jedność co do tego, że drążycie w odpowiednim miejscu, że chcecie w nim być na długo i stać się najlepszymi. I tutaj znów wracamy do warstwy pryncypiów, gdzie często obsewuję zjawisko pochopnego podejścia do kwestii udziałów, nie patrząc na to, gdzie dana osoba zmierza, jak długo z nami chce trwać i co ją z nami trzyma. Często to po prostu dobry czas, w którym jesteście i biznes się kręci. Gdy pojawia się przestój, nagle okazuje się, że jesteś sam, a miejsce, w którym drążysz nie “jara” nikogo poza Tobą samym.

Filar #3: Działania

Hedgehog Concept to także narzędzie, które - według obserwacji zespołu Collinsa - jest wykorzystywane przez najlepsze zespoły jako fundament decyzji. To prowadzi do zdyscyplinowanych działań, które są piątym filarem koła zamachowego i które według Collinsa przekształcają dobre firmy w wybitne.

Zdyscyplinowana kultura

Typowym zjawiskiem w rosnących organizacjach jest tzw. spirala biurokracji - gdy firma się rozrasta i pojawia się coraz więcej wyzwań, zarząd często sprowadza "profesjonalnych menedżerów", którzy wprowadzają struktury, procedury i hierarchie mające uporządkować chaos. Problem w tym, że te same mechanizmy, które tworzą porządek, często duszą przedsiębiorczość i kreatywność, które początkowo napędzały sukces. George Rathmann, jeden z liderów badanych firm, zrozumiał kluczową zasadę: biurokracja jest potrzebna głównie tam, gdzie brakuje właściwych ludzi i wewnętrznej dyscypliny. Gdy masz odpowiednich ludzi na pokładzie, możesz budować zdyscyplinowaną kulturę zamiast sztywnych struktur kontroli.

Najwybitniejsze organizacje zamiast zatrudniać MBAs ze znanych firm, skupiały się na potencjale swoich zespołów i ich kulturze. Skupiały się na utrzymaniu ustalonego kierunku korzystając z Hedgehog Concept’u, co prowadziło do odrzucenia wielu pobocznych aktywności w myśl totalnego skupienia na tym, co zrobić, aby osiągnąć maksimum kontrybucji w ustalonym obszarze.

Przykładem takiego skupienia na Hedgehog Concept jest wypowiedź Tomka Karwatki z prelekcji podczas InternetBeta 2022. Tomek opowiada tam, jak zmiana myślenia w zespole liderskim doprowadziła do odrzucenia większości obecnych klientów:

3. Akceleratory technologiczne

Ostatnim filarem według Collinsa, na który składa się koło zamachowe najlepszych firm to tzw. akceleratory technologiczne. Obecnie ten termin ma różne znaczenie i może dla wielu z Was oznaczać coś zupełnie innego niż dla Collinsa.

Akceleratory technologiczne to umiejętność dobrania z olbrzymiego zbioru obiecujących technologii tych, które mogą idealnie wzmocnić Hedgehog Concept.

Przykładowo, w Divante taką technologią było przez jakiś czas Magento, które miało swoje lata świetności w latach 2010-2020. Intensywny rozwój technologii e-commerce oraz rywalizacja pomiędzy nowo powstałymi technologiami wymagała odpowiedniego doboru.

Kiedy spojrzymy na archiwalną wersję ich strony z 2015 roku, widzimy, że wówczas Divante poza Magento integrowało tę technologię z różnymi systemami ERP oraz PIM. Czy to było takie jasne i oczywiste? Nie.

Warto przypomnieć, że Divante dołączyło do Grupy OEX w marcu 2015 roku, a przejmowane udziały spółki wyceniono wówczas na 3,2 mln zł. Zgodnie z informacjami z portalu ITwiz, 6 lat później były one warte już znacznie więcej:

Jak widać, Divante sprzedało pakiet większościowy w 2015. Nikt zapewne nie przypuszczał, że kwota 3.2 miliona złotych zamieni się w kilkaset w ciągu 7 lat. W tym okresie Divante przechodziło olbrzymią transformację. Wprowadzenie zewnętrznego zespołu współzarządzającego zmusiło Divante do bardzo stanowczego skupienia się na tym, w czym byli najlepsi. Kreatywność braci Karwatkow i kultura, z jaką przez te lata tworzyli swój SH przyciągnęła liderów 5-tego poziomu. Jedną z takich osób jest Artur Wala, który przez 7 lat pracy w Divante skupiał się głównie na tym, aby to, gdzie Divante zmierza (ich Hedgehog Concept) łączyć z innowacyjnymi technologiami. Brał udział zarówno w projektach VueStorefront (obecnie Alokai) oraz w Open Loyalty.

Divante wybrało drogę Magento jako swój akcelerator technologii, ale wiedzieli, że jest to tylko akcelerator. Kiedyś się skończy. Kiedyś jego przewaga przestanie wzbudzać zainteresowanie co brutalnie zweryfikował wyjazd na konferencje w Holandii:

3. Drive - warstwa najwyższej kontrybucji

Jak widzisz, jest wiele elementów, które muszą zadziałać:

1. Musimy mieć jedność na poziomie pryncypiów.

2. Musimy mieć odpowiedni zespół, który ma odpowiedni mindset, aby powstało koło zamachowe naszej organizacji.

3. Musimy mieć ustalony swój Hedgehog Concept jako wewnętrzny kompas decyzyjny.

Bardzo dużo rzeczy musi być “na miejscu”, aby w ogóle mówić o firmie, która będzie kierowała się w stronę “Good to Great”.

Można to uprościć do takiego prostego obrazka, gdzie nasze pryncypia to grunt, po którym zespół kroczy codziennie, przykładając się wspólnie do koła zamachowego, aby nadać mu coraz większy pęd.

Tutaj pojawia się kluczowe pytanie:

Najwyższa kontrybucja to miejsce, gdzie nasze koło zamachowe, pchane codziennie przez nasz zespół, przecina się z rynkiem. Gdzie unikatowe cechy osób w zespole i unikatowe cechy produktu, który powstaje poprzez ich pracę dają największą wartość.

Przykładowo, jeśli nasz Hedgehog Concept brzmi:

• “Jesteśmy głębokimi pasjonatami nowinek technologicznych w obszarze OSS”

• “Możemy być najlepsi na świecie w tworzeniu nowych technologii OSS w obszarze e-commerce, dzięki czemu przyciągniemy globalne duże firmy, które będą płaciły nam wysokie marże za pracę w obszarze R&D w e-commerce”

… to potrzebujemy kilku kluczowych cech zespołu, aby mógł on dostarczyć najwyższą możliwą kontrybucję zarówno dla siebie nawzajem jak i dla klientów.

Potrzebujemy także mieć wyraźnie określone miejsce, gdzie dajemy najwyższą kontrybucję dla naszych klientów. We wspomnianym wcześniej wystąpieniu Tomek opowiada o tym, jak mierzyli swoją najwyższą kontrybucję do wartości dla klienta poprzez NPS, czyli Net Promoter Score.

Co ciekawe, Tomek w swojej prezentacji umieszcza na tym samym poziomie “Drive”, z posiadaniem USP i wiedzy na temat rynku. Według mnie jednak Drive czy Warstwa Najwyższej Kontrybucji jest czymś, z czego wypływa potem USP (unikalna propozycja wartości) oraz kluczowa wiedza na temat rynku.

“ Trzeci filar to jest drive, czyli cała firma musi chcieć pójść global. To jest też totalnie częsty problem, który widzę, że founderzy chcą robić firmę globalną a wszyscy pracownicy mają tą funkcję Pompie i to się zaczyna od tego że ktoś coś sprzedaje, a potem zespół tego nie potrafi zrobić, albo zespół robi taki produkt, który jest po prostu do dupy i nikt tego nie chce i może to sprzedać a potem nikt tego nie chce używać i to jest po prostu bez sensu totalnie.“

Powyższa opowieść Tomka pokazuje, że możesz mieć zespół, który nie skupia się na tym, aby dać najwyższą kontrybucję zarówno w organizacji, jak i dla określonej grupy klientów. Musisz wtedy przemodelować swój zespół i ułożyćw nim role tak, aby każdy dostarczał najwyższą możliwą wartość w kole zamachowym oraz dla klientów.

Piotr i Tomek odkryli, że ich największą kontrybucją dla firmy i klientów będzie udział w procesie sprzedaży nowo określonego USP i produktu/usługi do docelowych klientów. Zrozumieli, jakie są ich mocne strony i jaki mają zespół. Ustalili, kto w zespole może dostarczyć największą kontrybucję i w jakiej roli. Następnie - nie patrząc na to, kim są w oczach pracowników - po prostu zaczęli pracę nad ustabilizowaniem nowego USP firmy.

4. USP i wiedza rynku

Dopiero teraz, gdy:

• masz już odpowiednią spójność co do pryncypiów;

• masz odpowiedni mindset i zespół, który jest świadomy tego, jaki Hedgehog Concept jest Waszym kompasem;

• jesteś świadomy, gdzie możesz ze swoim zespołem dawać największą kontrybucję sobie nawzajem i klientom;

możesz patrzeć na USP i gromadzenie wiedzy o rynku.

Dlaczego dopiero teraz? Bo to jest najbardziej zmienna część firmy. Wartości, mindset, Hedgehog Concept zostają z firmą na lata, przenikają jej DNA.

Natomiast proces przekształcania naszej firmy, doskonalenia produktów i usług oraz wprowadzania innowacji to niekończąca się droga rozwoju.

Nie ma czegoś takiego jak bezpieczna przystań. Nawet najmocniejsze USP i dobrze umiejscowiony produkt czeka zmiana, dlatego tak bardzo istotne jest nastawienie się na długofalowe, ciągłe poszukiwanie USP i poznawanie rynku.

W przypadku Tomka i Divante, w 2016 roku, gdy robili pivot mieli już “stabilną” linię biznesową opartą o Magento w Polsce. Wiedzieli jednak, że ich największy potencjał to bycie global R&D w e-commerce. Rozpoczęli więc równoległy i bardzo agresywny proces eksperymentacji nowych USP, zbierania z pierwszej ręki informacji zwrotnej i dopracowywania.

A kiedy tego typu ruch jest niebezpieczny? Pisałem o tym w SHI#4 w rozdziale “Czego unikać gdy Twój SH walczy o przetrwanie”.

Po słowie

Kręcenie się w kółko to efekt braku spójności w fundamentach swojego SH. Czasem na warstwie pryncypiów są mocne zgrzyty np. jeden z founderów zasysa kapitał gdy reszta inwestuje, a może po prostu ktoś w zespole ma wysokie IQ, ale nie emocjonalne i jest po prostu toksyczny…tych przypadków jest bardzo wiele.

Pomagam SH w tym aby zrobić Audyt Filarów SH, na których budują swoją firmę, przekazując swoje obserwacje wraz z sugestiami zmian opierając je na doświadczeniach pracy z innymi SH.

W dzisiejszym numerze skupimy się na:

• Jak porzucić złą strategię (zanim pogrąży Twój SH)?

• Dlaczego założyciele software house'ów wolą wydawać miliony na ryzykowne inwestycje?

• Czego unikać, kiedy Twój software house walczy o przetrwanie?

• 10 rzeczy, których powinieneś unikać oraz 7 rzeczy, które pomogą wyciągnąć SH z dołka

• Clorce - historia upadłego SH, który wrócił do gry

Zebrana w tym biuletynie wiedza 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 nich nieustannie.

Ważne: Po miesięcznej przerwie w publikowaniu wracam zdwojoną siłą. Kolejne SHI będą publikowane co tydzień.

Jak odrzucić złą strategię (zanim pogrąży Twój SH)

Jesteś założycielem software house, który istnieje na rynku od 8 lat. Co roku powtarzasz sobie: Będę pracować nad strategią, wprowadzę OKR-y, MIND, 4DX lub inne modne narzędzie, o którym słyszałem. Mija rok, a Ty nadal zmagasz się z narzędziami i jesteś wyczerpany po serii spotkań z kluczowymi członkami zespołu.

Ale po tej serii spotkań wreszcie to masz. Strategię. Odważasz się nawet zaprezentować ją swoim pracownikom podczas jakiegoś fancy wydarzenia. Masz to! Gratulacje! Jesteś w 1% drogi.

Przykro mi to mówić, ale taka jest brutalna rzeczywistość. Strategia to - obok pracy zespołowej - najczęściej nadużywane słowo w każdej firmie. W ciągu ostatnich 17 lat pracy z software house’ami uczestniczyłem w wielu spotkaniach strategicznych, burzach mózgów i grupach fokusowych. Co łączyło 95% z nich?

One wszystkie były planami, a nie strategiami.

Dokładnie tak. Nie chcę tutaj zagłębiać się w teoretyczne dyskusje. Wszyscy popełniliśmy ten błąd. Mieszaliśmy strategię z planem. Kropka. Nie ma nic złego w mieszaniu tych rzeczy. Niebezpieczne jest jednak coś zupełnie innego.

To ignorancja.

Każdy założyciel firmy powinien za wszelką cenę walczyć z ignorancją: ignorowaniem swojego zdrowia, rodziny, współpracowników, ducha, ale jeśli chodzi o firmę - ignorowaniem trudnej, brutalnej prawdy.

Zróbmy szybką weryfikację z użyciem AI. Użyj następującego prompta:

Wciel się w rolę A.G. Lafley'a i Rogera Martina i doradź mi w kwestii mojej strategii. Jestem założycielem software house'u. Naszym celem jest [jakiś ambitny cel], będziemy konkurować w [gdzie będziemy działać] poprzez [jak wygrać], wspierani przez [kluczowe kompetencje Twojego zespołu] i utrzymywani dzięki [systemom zarządzania, takim jak OKR/4DX/MIND itp.].

Moja najważniejsza inwestycja strategiczna w tym roku, mająca na celu stabilny wzrost, to: [Twoja inwestycja strategiczna]. Obawiam się, że mogę przeoczyć kluczowe aspekty, które mogą osłabić tę strategię i uniemożliwić osiągnięcie długoterminowej stabilności mojej firmy. Czy mógłbyś wskazać poważne ryzyka lub słabe punkty mojego planu, które mogę przeoczyć?

Właśnie użyłem tego polecenia w o4-mini, aby ocenić aktualną strategię jednego z moich klientów i muszę przyznać, że otrzymałem naprawdę precyzyjną listę zagrożeń. Niektóre z nich już obserwujemy i jesteśmy ich świadomi, a inne są bardzo istotne, ale wcześniej nie zdawaliśmy sobie z nich sprawy.

Jednak świadomość ryzyka nie jest lekarstwem na ignorancję. Nadal możesz ignorować ryzyko. Z moich obserwacji wynika, że przyczyna takiego stanu rzeczy jest prosta:

Po prostu nie mamy lepszego pomysłu, więc realizujemy plan, który jest “w miarę ok”. Cóż, lepsze to niż nic, prawda?

Nie. Plan „w miarę ok” nie zadziała. Nie możemy prowadzić działalności biznesowej w tak niepewnych warunkach. Musimy znacznie zmniejszyć poziom niepewności. Jednak przyznanie się, że NIE wiemy, jaka strategia będzie dobra, budzi strach. Jak można przyznać przed sobą, współpracownikami, pracownikami i networkiem, że NIE wiemy, jaka strategia pozwoli nam osiągnąć sukces?

Najzabawniejsze w tym wszystkim jest to, że:

realizując niesprawdzoną strategię, wszyscy wokół ciebie wiedzą, że NIE wiesz, jaka strategia jest skuteczna. Widać to w miejscu pracy, podczas spotkań, kiedy raz po raz przedstawiasz swoją strategię, a twój głos drży w momentach, gdy bullshit radar bzdur podpowiada Ci:

Ale w głębi duszy naciskasz przycisk „Ignoruj” i kontynuujesz tę historię.

Dlaczego tkwimy w tej niepewności?

Po prostu nie mamy innego wyjścia. Nie wiemy, że istnieje inny sposób na przygotowanie strategii. Wpadamy w pułapkę OKR, 4DX, MIND i innych systemów, mając nadzieję, że w magiczny sposób wyleczą one nasz brak sprawdzonej strategii.

Jak więc przekonać się, że strategia rzeczywiście jest zła?

Na początku, zaprezentuj strategię samemu sobie – w całości. Jeśli oszukujesz sam siebie, Twój wewnętrzny bullshit radar od razu to wykryje. To wewnętrzne poczucie, że tylko wróżysz z fusów, zakładając zbyt wiele niepewnych kwestii, jest tak łatwe do zauważenia, że po prostu nie da się go przeoczyć.

Zapisz wszystkie momenty, w których Twój wewnętrzny radar wykryje bzdury. Nie zakładaj, że je zapamiętasz. Po prostu je zapisz.

Później spójrz na listę i zadaj sobie te dwa pytania:

1. Ile wysiłku będzie mnie kosztowało zminimalizowanie obawy, że to stwierdzenie w mojej strategii jest nieprawidłowe?

2. Czy jestem gotowy zaryzykować kolejne 6–12 miesięcy pracy w oparciu o nie sprawdzoną strategię bez uprzedniego wyjaśnienia tej kwestii?

Jeśli potrzebujesz kilku tygodni lub miesięcy na zminimalizowanie pewnych ryzyk i bez tego nie możesz rozpocząć realizacji założonej strategii w ciągu najbliższych 6–12 miesięcy, to znak, że nie jesteś jeszcze gotowy. To też sygnał, że sytuacja wymaga pilnej poprawy.

Uważaj na efekt Dunninga-Krugera.

Zbyt dużym uproszczeniem byłoby polegać wyłącznie na wewnętrznej ocenie i tych dwóch pytaniach, aby stwierdzić, czy strategia rzeczywiście jest zła. Wielu założycieli firm, z którymi miałem okazję rozmawiać, posiadało bardzo głęboką wiedzę na temat swojego rynku, mieli naprawdę bardzo dobre przemyślenia, ale byli tak niepewni swoich wniosków, że w kółko powtarzali tę samą “bezpieczną” strategię.

Z drugiej strony widziałem jeszcze większą liczbę założycieli, którzy nie mieli prawie żadnej wiedzy na temat swojego rynku, a byli tak pewni swoich decyzji, że ich bullshit radar nie zadziałał nawet wtedy, gdy zapach tych bzdur był tak silny, że ludzie wokół nich go wyczuwali.

Ten cytat doskonale oddaje sposób, w jaki założyciele firm często popadają w tzw. false-positive strategy. Często mają temperament, nad którym nie potrafią zapanować, poddając się irracjonalnym emocjom. Emocje te są zazwyczaj główną przyczyną, dla której popadają w strategię samospełniającej się przepowiedni. Niestety przepowiednia ta się nie spełnia, a założyciel bardzo często okłamuje siebie przez wiele lat.

Dlaczego założyciele software house'ów wolą wydawać miliony na ryzykowne inwestycje zamiast ciężko pracować?

1. Są zmęczeni.

Zmęczenie walką, ciągłymi spotkaniami, poszukiwaniem informacji, czytaniem ton książek i rozmowami z „kolejnym świetnym doradcą”. A my po prostu chcemy po prostu wykonać swoją PRACĘ. Nie możemy ciągle zmieniać strategii. Musimy działać.

Jesteś zmęczony pracą nad strategią? Pogódź się z tym, bo inaczej skończysz realizując złą strategię…

2. Prawo Brandoliniego

Prawo Brandoliniego, sformułowane przez Alberto Brandoliniego w 2013 roku:

„Ilość energii potrzebnej do obalenia bzdur jest nieporównywalnie większa niż ilość energii potrzebna do ich stworzenia”.

W kręgach technologicznych i skupionych na krytycznym myśleniu stało się to popularnym aforyzmem ilustrującym, jak tanie jest rozpowszechnianie dezinformacji – i jak kosztowne jest jej obalanie.

Oto, co zaobserwowałem: założyciele SH zbierają się, opracowują strategię, tworzą ładny dokument i prezentację, a następnie dzielą się nimi z zespołem. Teraz bzdury są dziesięć razy trudniejsze do obalenia, ponieważ już zostały sformułowane. W większości przypadków wysiłek ten jest tak ogromny, że zespoły po prostu poddają się i realizują bzdurną strategię.

3. Unikają winy.

Lepiej realizować głupią strategię i obwiniać za to założycieli niż opracować własną. Dlatego zespoły stosują się do złej strategii.

Zjawisko to jest klasycznym przykładem efektu HiPPO (Highest Paid Person's Opinion), w którym decyzje podejmowane są nie na podstawie danych lub wiedzy zespołu, ale po prostu dlatego, że tak mówi osoba o najwyższej pozycji w hierarchii. Organizacje padają ofiarą tego efektu, gdy przedkładają hierarchię nad dowody, co prowadzi do tworzenia strategii, którą wszyscy prywatnie kwestionują, ale publicznie popierają.

Oczywiście wyjątkiem są ambitni pracownicy, którzy dołączyli do firmy z nadzieją na udział w czymś wyjątkowym. Oni będą zgłaszać uzasadnione wątpliwości, a kluczowe znaczenie ma Twoja reakcja. Czy słuchasz wszystkich pracowników firmy, którzy zadają właściwe pytania czy też ignorujesz ich, jeśli nie są to osoby z najwyższego szczebla kierowniczego? Wyraźnym sygnałem złej strategii jest odejście dobrego pracownika po narzuceniu mu nowej strategii.

4. Mają dobrze działający biznes.

Wszyscy dążymy do osiągnięcia sukcesu w biznesie. Stabilnych dochodów przez lata. Dobrej marży, atrakcyjnych premii i wysokich zysków dla akcjonariuszy. Brzmi bardzo dobrze. Niestety, sukces w biznesie utrudnia założycielom krytyczne spojrzenie na swoją pozycję i strategiczne myślenie. Popadają oni w pułapkę 1% optimization, wierząc, że skupienie się na drobnych usprawnieniach przyniesie ogromne korzyści w dłuższej perspektywie. Choć jest to dobre dla ciągłości operacyjnej, nie jest to doskonała strategia dla firmy. Pokazuje to bowiem tylko, że nie wiesz, co robić, więc skupiasz się na czymś łatwym do osiągnięcia, aby wyglądać na mądrego. Bardzo łatwo przenosi się to na wszystkich członków zespołu. Czują, że prowadzą dobry biznes, zarabiają świetne pensje, uczestniczą w wyjazdach firmowych, szkoleniach i zatrudniają więcej osób. Marzenie. Dopóki nie przestaje nim być. Wiele dużych firm upada, postępując właśnie w ten sposób.

5. Naśladują konkurencję.

Software house'y dobrze się znają. Znają swoich bezpośrednich konkurentów: spotykają się na konferencjach i słyszą o sobie od potencjalnych klientów. Obserwują rozwój innych firm IT i chcą podążać ich śladami. Naśladują je. Zatrudniają pracowników z konkurencyjnej firmy i robią to samo. Nie analizują, dlaczego dany SH wybrał właśnie taką ścieżkę rozwoju. Niestety widziałem to zbyt często.

Jak więc porzucić złą strategię?

Po pierwsze, może się okazać, że Twoja strategia wcale nie jest w 100% zła. Muszę przyznać, że w swojej karierze spotkałem tylko kilka software house’ów, które moim zdaniem miały w 100% złą strategię. W większości przypadków założyciele mają dobre pomysły, ale zbyt szybko przechodzą do ich pełnej realizacji.

Zamiast tego powinni zacząć kwestionować wszystkie założenia. Wiele firm konsultingowych prosi software house’y o stworzenie analizy SWOT, modelu biznesowego Canvas, a nawet OKR z metrykami. To, co sprawdza się w moim przypadku i co bardzo często doradzają eksperci zajmujący się tworzeniem strategii, to powrót do klienta. W tym celu najwygodniej jest skorzystać z:

• Value Proposition Canvas,

• Twojego dotychczasowego doświadczenia jako retrospektywy dogłębnych przyczyn, dlaczego ten konkretny klient trafił do Ciebie, kto go do Ciebie skierował i przez jaki kanał.

To dopiero pierwszy krok do prawdziwego przemyślenia wartości, jaką oferujesz swoim klientom. Jest to punkt wyjścia do naszej dalszej podróży i serii artykułów, które opublikuję w kolejnych edycjach SHI. Będzie to zestaw materiałów szkoleniowych, który będziecie mogli wykorzystać razem z zespołem:

• Jak ocenić, czy Twoja strategia jest dobra czy zła? (ten artykuł)

• Jak zdefiniować trwałe filary, na których opierasz swoją strategię?

• Jak odkryć pełen potencjał swojego software house’u?

• Jak ocenić potencjalne ścieżki rozwoju przed podjęciem dalszych działań?

• … a także kolejny zestaw szkoleń dotyczących eksperymentowania z wybraną ścieżką.

Czego unikać, kiedy Twój software house walczy o przetrwanie?

Zone to Win to książka na temat tego jak dzielić kluczowe inicjatywy w ramach organizacji. Opiera się na doświadczeniach Geoffrey Moore'a zdobytych podczas pracy w Salesforce i Microsoft. We wstępie Moore pisze, że jest to playbook dla organizacji o dowolnym rozmiarze: a playbook- for organizing and managing established enterprises of any size in a time of category disruption. Każda firma, nawet mała, która ma ustabilizowany obszar przynoszący dochód dla firmy, który ją utrzymuje, może popatrzeć na swoje działania z perspektywy opisanych przez niego obszarów.

Na czym to polega?

Opiera się na podzieleniu działalności przedsiębiorstwa na cztery strefy i zarządzaniu każdą strefą niezależnie od pozostałych trzech. W ten sposób ma ona na celu sprostanie dwóm wyzwaniom. Pierwszym z nich jest pomoc zespołom zarządzającym w tworzeniu franczyz w zarządzaniu wyzwaniami związanymi z alokacją zasobów przy wprowadzaniu nowej linii biznesowej, przy jednoczesnym utrzymaniu zobowiązań wobec istniejących linii. Nazywamy to zone offense. Drugim jest pomoc tym samym zespołom w zorganizowaniu się, aby odeprzeć atak przełomowego innowatora wymierzonego w jedną z ich dojrzałych podstawowych działalności. Nazywamy to zone defence. Razem stanowią one zone management, dyscyplinę mającą na celu umożliwienie przedsiębiorstwom konkurowanie z pełną siłą w obliczu przełomowych innowacji, które tak bardzo zmieniają nasz świat.

Źródło: Zone to Win (tłum. własne)

W 2022 roku Geoffrey Moore wprowadził piątą strefę:

Celem strefy przejściowej (Transition Zone) jest przeniesienie nowego produktu ze strefy inkubacji (Incubation Zone) do strefy wydajności (Performance Zone) i zintegrowanie go z ogólną ofertą przedsiębiorstwa. Jest ona przeznaczona dla ofert, które będą wprowadzane na rynek za pośrednictwem istniejących kanałów sprzedaży, wspierane przez istniejący ekosystem partnerów i sprzedawane potencjalnym klientom, z którymi nawiązano już kontakt.

Źródło: Zone to Win, wydanie 2023 (tłum. własne)

Czym różni się Transition zone od Transformation zone?

Strefa transformacji (Transformation Zone) jest przeznaczona dla ofert wysoce przełomowych, które wymagają nowych kanałów sprzedaży, nowych partnerów ekosystemowych oraz przyciągnięcia uwagi nowych grup docelowych.

Źródło: Zone to Win, wydanie 2023 (tłum. własne)

Jako mała firma nie dysponujemy osobami, które mogą np. przez kilka lat pracować nad jakaś inicjatywą, która np. w pierwszym roku nie przyczynia się do przychodów firmy. Możemy natomiast patrzeć na nasz biznes i nasze działania, oceniając, na jakich obszarach się skupiamy. Przykładowo, jeśli większość swojego czasu pracujemy nad nowym “lejkiem” sprzedażowym, który nie przynosi obecnie zysku dla firmy, to warto uświadomić sobie, które pozostałe obszary na tym cierpią:

• Wydajność – czyli obszar, w którym zarabiasz pieniądze

• Produktywność – czyli obszar, w którym optymalizujesz swoje działania

• Transformacja – ponieważ lejek, który angażuje większość Twoich zasobów, zmienia również Twoją organizację

• Inkubacja – obszar, w którym eksperymentujesz z nowymi sposobami przekształcania swojej firmy w lepsze miejsce

Pierwsze, czego należy unikać: Nadmierne angażowanie się w nowe przedsięwzięcia

Zamiast poświęcać „nowemu lejkowi” bardzo ograniczony czas i zasoby, poświęcasz mu zbyt wiele uwagi i dostosowujesz do niego całą firmę.

To, co otwiera tę książkę, to kluczowy rozdział “The Crisis of Prioritization”, w którym autor opisuje, jak duże firmy, mające bardzo dobre zespoły, niestety przegapiły swoje szanse i odeszły w cień. Jego wniosek jest prosty: w obliczu dużej zmiany na rynku (tzw. disruption), robienie cały czas tego tego samego nic nie da, robienie wielu rzeczy na raz - także nic nie da.

Drugie, czego należy unikać: Powtarzanie tych samych czynności w nadziei, że tym razem wynik będzie inny

Należy rozdzielić prace i rozluźnić powiązania pomiędzy tym, co przynosi dochód teraz (Performance zone), a tym co może przynieść go za 2-3 lat (Incubation oraz Transformation zone).

No dobrze, to jak teraz, mając kilkuosobowy SH, walcząc codziennie z zadaniami, ma to wyglądać w Twojej firmie?

WIN, czyli What’s Important Now

Jeśli kluczowe dla Twojego SH jest po prostu przetrwać, pieniądze się kończą i w zasadzie zaraz będziesz zwalniał ludzi, to nie ma tutaj miejsca na Incubation czy Transformation. Po prostu jesteś w trybie przetrwania. Wszelkie inicjatywy, pomysły, które nie mają bezpośredniego i bardzo szybkiego przełożenia na rentowność firmy zatrzymujesz.

Trzecie, czego należy unikać: Rozpoczynanie długotrwałych inicjatyw, których efekty są odczuwalne dopiero po długim czasie

Jeśli walczysz o przetrwanie, ostatnią rzeczą, jaką powinieneś robić, jest podejmowanie dużych inicjatyw, które przyniosą efekty dopiero po miesiącach lub latach. W następnej sekcji przedstawię listę takich czasochłonnych inicjatyw, które przynoszą efekty zbyt późno.

Czwarte, czego należy unikać: Ślepe podążanie za radami ekspertów bez krytycznej oceny

A to ostatnia, ale najważniejsza rzecz, którą musisz zrobić, gdy Twój SH walczy o przetrwanie: nie akceptuj ślepo inicjatyw tylko dlatego, że zostały zaproponowane przez kogoś mądrego, kogoś, kto „wie lepiej, bo jest ekspertem w tej dziedzinie”.

Dotyczy to również tego, co tu czytasz. Mimo, że staram się pisać w sposób uwzględniający złożoność sytuacji i pokazujący różne ścieżki, dając Ci wybór i przestrzeń na własne przemyślenia.

Co robić i czego unikać, jeśli nie chcesz, aby Twój software house trafił na śmietnik?

Nie możesz tworzyć nowych silników wzrostu ani lejków, gdy zagrożone są kluczowe obszary, takie jak płynność Twojego SH.

Czego zatem nie robić w momencie, gdy Twój dział performance jest zagrożony, a wraz z nim Twoja płynność finansowa?

Odpalać inicjatyw, które z pewnością nie przyniosą nowych klientów w czasie, w którym ich potrzebujesz.

Brzmi to prosto, ale tak właśnie ma być. Masz robić wszystko aby ustabilizować swój biznes, zarówno redukując koszty jak i znajdując nowy biznes. Jeśli z wszystkich Twoich inicjatyw, które podejmujesz jesteś na 100% pewny, że nie mają one szans przynieść klienta w oczekiwanym dla Ciebie czasie - to je po prostu wstrzymaj.

Czy to oznacza, że masz zatrzymać wszystko? Nie. Spośród wszystkich możliwych działań wybierz te, które odpowiadają na to proste pytanie:

Czy jest to możliwe, że angażując się w te inicjatywy przyciągnę klienta, który będzie gotowy kupić moje usługi w oczekiwanym przeze mnie czasie?

Załóżmy, że musisz znaleźć projekt w ciągu dwóch miesięcy. Które inicjatywy odpowiadają na to pytanie twierdząco?

7 rzeczy, które warto zrobić, gdy Twój software house upada:

1. Kontakt z obecnymi klientami, aby sprawdzić czy jest u nich szansa na upsale

2. Kontakt z partnerami, którzy wcześniej korzystali z Twoich usług i zapytanie ich, czy mają jakieś otwarte tematy w swoich lejkach

3. Outreach do odpowiednich osób w organizacji, które rekrutują osoby z tymi niszowymi kompetencjami (w przypadku body leasingu premium, czyli kompetencji niszowych, których jest niedobór na rynku)

4. Kampanie płatne, które kierują określone osoby z komitetu zakupowego do niej (w przypadku, gdy masz gotowy produkt lub sproduktyzowaną usługę)

5. Odpalenie produktu na Product Hunt, który jest software’owy i przyciąga osoby z Twojego komitetu zakupowego do jego użycia i udzielenia Ci zgody na kontakt marketingowy (tutaj przykład jak to zrobił Papermark)

6. Odpalenie wirtualnego SH w niezaadresowanej niszy, podpięty do istniejących profilów osób, które mają mocną widoczność sieci.

7. Outreach do konsultantów biznesowych, którzy pracują w firmach sprzedających licencje na produkty technologiczne, które Twój SH wdraża

Punkty 5 i 6 mogą wydawać się trudne i złożone. Jeśli zaczynasz od zera, to tak pewnie jest. Natomiast zadziwiająco często odkrywam, że w firmach drzemie ukryty potencjał, pół-produkt, framework, technologia, którą można użyć. Punkt 7 natomiast to bardzo ciekawy sposób na użycie sieci profesjonalnych BDMów, którzy - mając swoją sieć klientów korzystających z produktów technologicznych - mają specyficzne problemy wymagające wdrożenia oprogramowania szytego na miarę - czyli Waszych usług.

10 inicjatyw, których należy unikać, gdy Twój software house potrzebuje klientów już teraz

1. Outreach do osób bez jasnej intencji zakupowej po stronie danej firmy (np. gdy nie wiemy czy rekrutuje)

2. Wszelkiego rodzaju kampanie płatne, które mają promować Twój SH i jego złożone usługi (np. Custom development w Sales Force)

3. Prowadzenie webinarów

4. Uczestnictwo w meetupach (wyjątek: wydarzenia mocno niszowe, które umożliwiają spotkanie konkretnych osób z komitetu zakupowego, poszukujących dokładnie takich rozwiązań, jakie oferujesz. Na przykład, jeśli Twoja firma stworzyła wtyczkę do Jiry, wartościowy będzie meetup poświęcony integracjom tej platformy, skierowany do firm już z niej korzystających)

5. Raporty

6. Artykuły

7. Uczestnictwo w konferencjach (wyjątek: niszowe konferencje (tak jak w meetupach), które gromadzą osoby z komitetu zakupowego i Twojego idealnego profilu klienta)

8. Partnerstwa technologiczne (one wymagają zbudowania świadomości Twojej marki, zaufania po stronie firmy z którą budujesz partnerstwo)

9. Zatrudnianie sprzedawców, BoMów

10. Sprzedaż Twojego SH

Część z tych inicjatyw z pewnością wymaga oddzielnych artykułów, natomiast najważniejsze jest to, aby uczciwie ocenić, czy jest szansa, aby dana inicjatywa przyniosła klienta gotowego do zakupu w określonym przez nas czasie. Po prostu przestań słuchać ludzi, którzy nie wiedząc, co faktycznie może pomóc, próbują robić cokolwiek, aby pokazać, że są zajęci, a co gorsza - wymyślają jeszcze całkiem logiczne argumenty, że dana inicjatywa jest dobra.

Pamiętasz cytowane wyżej prawo Bradoliniego (o tym, że ilość energii potrzebnej do obalenia bzdur jest nieporównywalnie większa niż ilość energii potrzebna do ich stworzenia)?

Oznacza to, że osoby, które wrzucają Was na złe inicjatywy (i jeszcze próbują je uzasadnić) zmuszają Was do włożenia 10x więcej energii, aby te inicjatywy zabić w zarodku. Dlatego bardzo ważne jest, abyś zadawał to pytanie zarówno sobie, jak i tym, z którymi pracujesz, a także, abyś patrzył, czy te osoby się uczą. Jeśli ciągle tylko rzucają inicjatywy, które nie próbują tego pytania poprawnie zaadresować, to możliwe, że są po prostu spanikowane i próbują robić cokolwiek, aby tylko zachować swoją pracę.

Clorce - historia upadłego SH, który wrócił do gry

Kilka lat temu w San Francisco spotkałem Jakuba Tabędzkiego. Opowiedział mi o tym, jak przeszarżował w swoim software housie, a inkubacja jego ambitnego projektu o nazwie EneGIVE pochłonęła zarówno jego uwagę, jak i finanse do tego stopnia, że główny silnik wzrostu firmy – doradztwo i tworzenie oprogramowania – nie był w stanie przetrwać.

Jakub jest założycielem firmy Clorce, która w 2015 roku została partnerem Salesforce, pozycjonując się jako butikowa firma konsultingowa dostarczająca customowe rozwiązania IT. Równolegle uruchomił EneGIVE – platformę do zarządzania sieciami ładowania pojazdów elektrycznych – wykorzystując wczesne zachęty rządowe do promomowania elektromobilności w Polsce.

W czerwcu 2018 roku Jakub opublikował swoje pierwsze szczere wideo. W filmie tym opowiada o tym, jak jego software house znalazł się na skraju upadłości. Zastanawia się nad psychiczną ceną prowadzenia firmy „z dnia na dzień” i przyznaje, że każda porażka była jego winą: od zatrudnienia nieefektywnych dyrektorów sprzedaży i dyrektorów operacji, których nigdy nie nadzorował, po wydanie około 250 000 zł na działania sprzedażowe, które nie przyniosły żadnych nowych klientów. Opowiada o podróży do San Francisco w poszukiwaniu nieistniejących kontraktów i powrocie „wrakami”, gdy liczba pracowników spadła z 50 do poniżej 10 w ciągu zaledwie kilku miesięcy.

W ostatnim dniu pracy września 2018 r., w drugim filmie (poniżej), Kuba przyznaje, że zalega z wynagrodzeniami, projekty utknęły w martwym punkcie z powodu zmieniających się wymagań, a po ostatniej próbie uzyskania finansowania od współzałożyciela, formalnie zamyka zarówno Clorce, jak i EneGIVE.

Z jego historii można wyciągnąć wiele lekcji. Dla mnie jest on przede wszystkim przykładem odważnego przedsiębiorcy, który po prostu zbyt optymistycznie ocenił przejście swojej firmy z fazy inkubacji (Incubation zone) do transformacji (Transformation zone). Przeinwestował i upadł, ale powstał i prowadzi firmę opartą o silnik wzrostu partnerstw technologicznych (Technology Partner Growth Engine) - w tym przypadku Salesforce.

Największe błędy

1. Rozproszone przywództwo i odpowiedzialność

Zatrudnił dyrektora ds. sprzedaży i dyrektora zarządzającego, ale nie udało mu się narzucić im jasnych wskaźników wydajności – co otwarcie przypisuje własnemu brakowi nadzoru.

2. Wypalenie założyciela i przeciążenie zespołu

Jakub doprowadził siebie i swoich współpracowników do granic wytrzymałości, przenosząc tak dużą część obowiązków operacyjnych na bliską przyjaciółkę, że osiągnęła ona punkt krytyczny. To pokazuje, jak niebezpieczne jest ignorowanie możliwości zarówno własnych, jak i swojego zespołu.

3. Rozproszenie uwagi na trzy przedsięwzięcia

Zamiast skoncentrować zasoby na podstawowej działalności Clorce, czy wytwarzaniu oprogramowania (Performance zone), Jakub jednocześnie prowadził EneGIVE i firmę zajmującą się wypożyczaniem samochodów Tesla. Rozproszenie czasu, kapitału i uwagi kierownictwa uniemożliwiło osiągnięcie samowystarczalności przez żadną z linii biznesowych.

4. Nadmierne zaangażowanie w długoterminowy projekt

Clorce podjęło się wdrożenia dużego systemu ERP przy zmieniających się wymaganiach klientów, świadcząc pracę za darmo aby rozwiązać bieżące problemy z systemem. Jednocześnie EneGIVE zainwestowało w budowę infrastruktury stacji ładowania i oprogramowania do zarządzania siecią – obie inicjatywy miały przynieść ROI w perspektywie od kilku miesięcy do kilku lat – podczas gdy zobowiązania płacowe Clorce zaczęły rosnąć.

5. Zbyt późne zamknięcie nierentownych projektów

Pomimo powtarzających się sygnałów o problemach z płynnością finansową, opóźnień w wypłatach części wynagrodzeń dla pracowników oraz zastoju w realizacji projektów, Jakub zwlekał z zamknięciem EneGIVE i projektu związanego wynajmem Tesli ze względu na efekt utopionych kosztów i nadmierny optymizm. Każdy kolejny miesiąc działalności dodatkowo uszczuplał rezerwy, które mogły zostać przekierowane do dochodowego trzonu biznesu.

6. Zaniedbanie pozyskiwania potencjalnych klientów i inbound marketingu

Clorce nie prowadziło żadnych systematycznych działań w ani zakresie inbound, ani performance marketingu. W rezultacie, wyczerpały się możliwości pozyskania nowych projektów, co pogłębiło problemy z płynnością finansową firmy i osłabiło jej zdolność do terminowego wypłacania wynagrodzeń.

7. Stawianie na wielkie deale kosztem szybkich zysków

Firma koncentrowała się na kontraktach wartych miliony złotych (w tym potencjalne zlecenie o wartości 2 mln PLN), ale nie zdołała pozyskać mniejszych, szybko realizowanych projektów, które mogłyby wypełnić lukę między tymi dużymi umowami. Gdy flagowe projekty utknęły w martwym punkcie, zabrakło tymczasowych źródeł przychodów.

5 Kluczowych taktyk zarządzania kryzysowego, czyli jak upadająca firma odwróciła sytuację

Jak wiemy z filmu, Jakub planował zdecydowane działania, aby poprawić sytuację swojej firmy:

1. Brutalna samoocena i strategiczne zamknięcie: Stojąc w obliczu rosnących zaległości płacowych i wstrzymanych projektów, Jakub uruchomił swój "bullshit radar", przyznając, że ani Clorce, ani EneGIVE nie mogą być uratowane bez nowego kapitału. Postanowił formalnie zamknąć obie firmy we wrześniu 2018 roku.

2. Likwidacja aktywów dla zapewnienia płynności finansowej: Postanowił sprzedać swoją flotę Tesli - główny aktyw niezwiązany z podstawową działalnością - aby wygenerować około 100 000 PLN kapitału obrotowego. Ten zastrzyk finansowy zapewni mu środki niezbędne do realizacji kolejnego przedsięwzięcia i był przykładem ścisłego przestrzegania zasady “What’s Important Now”: zachowanie zdolności generowania pieniędzy ponad wszystko inne.

3. Nacisk na zweryfikowany popyt rynkowy: Przy ponownym starcie Jakub postanowił przyjmować tylko projekty od klientów, którzy byli gotowi do zapłaty. Odmawiał rozpoczęcia jakiejkolwiek inicjatywy bez wyraźnych zobowiązań wynikających z umowy, unikając tym samym spekulacyjnych inwestycji, które wcześniej wyczerpały jego zasoby.

4. Wykorzystanie istniejących relacji dla finansowania pomostowego: Zwrócił się do swojego byłego współzałożyciela o dokapitalizowanie Clorce, uznając, że sprawdzeni partnerzy mogą zapewnić szybsze, mniej problematyczne finansowanie niż źródła zewnętrzne - tym samym zastosował 7 dobrych praktyk dot. strategii przetrwania, które poruszyłem w tym wydaniu newslettera.

5. Celowanie w krótkoterminowe możliwości uzyskania przychodów: Nawet w sytuacji kryzysowej Jakub zidentyfikował kilka niewielkich projektów z realnymi perspektywami realizacji w ciągu tygodnia. Skupienie się na szybkim zamknięciu transakcji było dokładnie tym, co omówiliśmy w scenariuszu działania dla firm znajdujących się w “trybie przetrwania”.

Odrodzenie i Obecny Fokus

Jakub otworzył na nowo swoją agencję specjalizującą się wyłącznie we wdrożeniach Salesforce. Spłacił swoje długi wobec byłych pracowników, którzy byli wystarczająco cierpliwi, aby poczekać na odrodzenie jego firmy. Zbudował organizację wokół zweryfikowanego silnika wzrostu partnerstw technologicznych (Technology Partner Growth Engine). Ograniczając działalność do jednej, wysoko poszukiwanej niszy z jasną widocznością przychodów, zapewnił, że nowe przedsięwzięcie mogło utrzymać swoje zobowiązania płacowe i uniknąć pułapek płynności, które dotknęły jego poprzednie przedsięwzięcia.

Po słowie

Każdy założyciel software house'u może znaleźć się w takiej samej sytuacji jak Jakub. Próba znalezienia wyjścia z Doliny Śmierci to proces, który zawsze budzi strach.

Wspieram firmy poprzez prowadzenie warsztatów Software Agency Growth Paths, podczas których analizujemy obecną pozycję software house'u, identyfikujemy łatwo dostępne możliwości rozwoju (tzw. low-hanging fruit) oraz projektujemy ścieżki przyszłego wzrostu w ramach Growth Engine Experimentation Lab.