Leon Schubert is managing director of Okeano GmbH in Lippstadt, Germany. Seven people, five of them developers, building software for clients for about five years now: e-commerce, apps, process automation. For the past eighteen months they have also been selling a product of their own — Pylo, a backend platform that a dozen companies now run on.
This is a summary of Episode 188 of the “Happy Bootstrapping” Podcast (German).
Twenty, Thirty, Forty Projects Became One Product
There was no lightbulb moment. There was a pattern that eventually became impossible to ignore. As Leon puts it, they kept building very, very similar things for many different clients. Data models, user management, permissions, processes, interfaces. After twenty, thirty, forty projects, they knew the recurring parts well enough to pull them out.
Internal toolkits came first, and the platform grew out of those. What Leon now calls his most expensive mistake is not a wrong decision but a missing one: they could have generalised earlier. Instead, a single very large client project tied them up for a year or two.
One example shows what it buys them today. For an optician and hearing-aid group, they built an app that regional managers use to document their store visits. On Pylo, it took roughly a third of the time it would otherwise have needed.
What Pylo Actually Is
Leon calls it an operating system for your company. Technically it is a backend-as-a-service platform: data storage, permissions, APIs, plus a flow builder and a forms module. The reference points sit in different corners of the market — Firebase and Supabase for the backend, n8n and Zapier for the flows, Tally for the forms.
The difference from conventional off-the-shelf software lies in the assumption behind it.
“Our basic assumption is that we don’t know what the best system for a particular company looks like, which is why we want to keep our system as flexible as possible.”
Customers use it in very different ways. About half run Pylo for individual use cases, the other half as their leading system. Some push millions of records through it, and a four-digit number of people work with it overall.
Under the hood: PHP with Laravel, a modified Postgres build, a separate database for event data, and a flow service written in TypeScript. The frontend is Next.js, the interfaces are GraphQL. More notable than the stack itself is one self-imposed restriction:
“We don’t access the database ourselves when we build a new feature.”
Their own team uses the same public APIs as any customer. No internal shortcuts, no second layer.
Billed by Usage, Not by Head
On pricing, Okeano deliberately went against the norm. No per-seat price, no artificially crippled feature tiers. They bill for what actually accrues: data volume, storage, executed flow actions. The base price is low.
The reasoning is straightforward. Seat pricing punishes exactly those customers who roll a system out broadly across their organisation — which is the case where Pylo delivers the most value.
Marketing a Product That Needs Explaining
Pylo has three audiences: agencies, in-house development teams, and IT decision-makers. LinkedIn serves the decision-makers; developers and agencies are reached through YouTube and technical content. There is no cold outreach. Agencies are a special case, because they can be competitor and distribution channel at once — Leon clearly sees them as the latter.
The most common objection has shifted recently. It used to be complexity; now it is the claim that you could just build this yourself with AI. Leon’s answer does not target code generation but what comes after it: an agent works far better with data that is already cleanly structured. That is what the new MCP server is for.
Why the Agency Is the Better Investor
Around 80 percent of revenue still comes from services, with roughly 10,000 euros in monthly recurring revenue from Pylo. The team splits its time about 60/40 in favour of the product, so the revenue mix lags behind on purpose.
There have been offers from investors. Leon never thought about any of them for long.
“Our goal really is to build the best software in this space. And we believe that bootstrapping may be the slower and harder path, but the more promising one.”
His argument against venture capital is practical rather than principled: with VC-funded products, what often gets built is not the best product but the one that reaches profitability fastest. Without that pressure, Okeano can stay in closed beta for as long as the product benefits from it.
Team size is a deliberate choice too. Seven people is a size they are comfortable with; headcount growth is not a goal in itself. In Lippstadt, that has a side effect Leon describes with a wink:
“There are good developers in Lippstadt, of course, but they all already work for us.”
What I Learned in This Interview
A product rarely comes from an idea. It comes from a pattern you have seen often enough. Okeano built almost the same thing twenty to forty times before anything of their own emerged from it.
Services and products are not mutually exclusive. Here the agency business is not a transitional phase but the funding — with the advantage that nobody outside sets the pace.
Discipline beats convenience. Denying your own team privileged database access costs speed in the short term and guarantees in the long term that the public interface is actually good enough.
The full interview on YouTube (German):
Learnings for Founders
Watch for repetition in client work. Whatever you build for the third time in a similar shape is a product candidate.
Generalise earlier than feels right. Leon’s most expensive mistake was waiting, not acting.
Check your pricing model for built-in penalties. Seat pricing slows down exactly the customers who benefit most from you.
Treat existing revenue as capital. A running services business funds product development without dilution and without someone else’s timeline.
Treat yourself like a customer. If you use the same interfaces internally that you offer externally, you notice the weaknesses first.
Happy Bootstrapping is a German podcast where I interview bootstrapped founders, indie hackers, and solopreneurs about their startup journeys.
Over the years, I’ve connected with many successful entrepreneurs who have built e-commerce shops, SaaS platforms, mobile apps, content businesses, or hybrid models.
Furthermore I am a bootstrapper myself and growing my DevOps-as-a-Service and Web Operations Company “We Manage”.