Building a Profitable Startup Without VC Money

Cantoo was never supposed to be a venture-backed company. Not because we could not have raised money, but because we did not need to. We built a cloud telecom platform, made it profitable in under two years at 400,000 euros per year in revenue, and sold it to 42com. All without a single round of funding.

Here is how we did it, and more importantly, the decisions that made it possible.

Starting With Revenue, Not Growth

The first decision that shaped everything was choosing to optimize for revenue from day one. Not user growth. Not market share. Revenue.

This sounds obvious, but it goes against almost everything the startup ecosystem tells you. The conventional wisdom is: grow fast, worry about money later, raise a round to buy yourself runway. We did the opposite. Before writing a single line of code, we had conversations with potential customers, telecom operators who needed hosted voice and messaging services. We validated that they would pay for what we planned to build. Then we built it.

Our first paying customer was on the platform within three months of writing the first line of code. Not a pilot. Not a free trial. A paying customer with a signed contract and monthly invoices. That changed our psychology completely. We were not building a product hoping someone would eventually pay for it. We were building a product because someone was already paying for it.

What We Said No To

The most important decisions at Cantoo were not about what we built. They were about what we refused to build.

We said no to a beautiful dashboard. Our operators wanted API access and raw data. A polished UI would have been nice, but it would not have generated a single euro of additional revenue. We built a functional admin panel that did the job and spent that engineering time on the billing system instead.

We said no to supporting every protocol. The telecom world has dozens of protocols and standards. We picked the ones our target customers needed, SIP for voice, SMPP for SMS, and did those well. A competitor of ours tried to support everything. They are no longer in business.

We said no to hiring. For the first eighteen months, the engineering team was just two people. My co-founder and I did everything: architecture, development, operations, carrier negotiations, customer support. Hiring would have increased our burn rate and slowed us down. Every new person needs onboarding, management, and alignment. At our stage, speed mattered more than capacity.

We said no to office space. We worked remotely before it was fashionable. No lease, no commute, no coffee machine budget. This saved us tens of thousands of euros that went directly into infrastructure costs and carrier deposits instead.

The Economics of Bootstrapping

Let me be specific about the numbers, because vague bootstrapping advice is useless without context.

Our initial investment was close to zero in cash, just our time and existing equipment. The major costs were infrastructure (servers, Kubernetes cluster, monitoring tools), carrier interconnection (deposits required by telecom carriers to start routing traffic), and regulatory compliance (licensing fees for operating as a telecom operator in the UK, France, and Germany).

The carrier deposits were the biggest upfront cost. Telecom carriers require deposits before they will route traffic through your platform. These are not optional. Without them, you have no product. We funded these from personal savings and early revenue.

Revenue came from per-minute and per-message fees charged to our operator clients. The margins in wholesale telecom are thin, typically 5-15% depending on the route and the volume. But they are predictable. Once an operator integrates with your platform, they do not switch easily. The switching costs are high enough that customer retention is built into the business model.

By month twelve, we were covering all operating costs. By month eighteen, we were profitable. By month twenty-four, we hit 400,000 euros in annual revenue. Not venture-scale numbers. But real money that belonged entirely to us.

How Constraints Helped

The conventional view is that constraints limit what you can build. I found the opposite. Constraints forced us to focus, and focus is what made us successful.

Without venture capital, we could not afford to build features speculatively. Every feature had to justify its existence in terms of revenue impact. This meant we never built anything that did not directly serve a paying customer or reduce our operating costs.

Without a large team, we could not afford technical debt. There was nobody to hand messy code off to. Whatever we built, we had to maintain ourselves. This created a natural incentive to keep things simple and well-documented.

Without a marketing budget, we had to rely on the quality of our product and our carrier relationships to grow. Our operators recommended us to other operators because the platform worked reliably and the pricing was transparent. Word of mouth is slow, but it is also free and high-trust.

The Decision to Sell

The acquisition by 42com was not driven by desperation. We were profitable and growing. But 42com offered something we could not build alone: scale.

As a wholesale telecom provider, 42com had carrier relationships and traffic volumes that would have taken us years to develop independently. Joining forces meant our technology could serve a much larger market while benefiting from their commercial infrastructure.

The negotiation was straightforward because our numbers were clean. Profitable companies with predictable revenue are easy to value. We did not need to convince anyone about future potential or market size. The business spoke for itself.

I led the full technical integration post-acquisition, merging our platform into 42com's infrastructure. This is where the clean architecture paid off again. Because our systems were well-documented and modular, the integration took months, not years.

What I Would Do Again

If I were starting another bootstrapped company tomorrow, I would keep the same playbook.

Validate with money, not surveys. Do not ask people if they would pay for your product. Find someone who will actually pay for it before you build it.

Optimize for revenue per engineer. The metric that matters most in a bootstrapped company is how much revenue each team member generates. Keep the team small and the output high.

Pick a market with recurring revenue. Telecom worked because operators pay monthly for ongoing service. One-time sales are harder to bootstrap because your revenue resets to zero every month.

Say no more than you say yes. Every feature you build has ongoing maintenance costs. In a bootstrapped company, you cannot afford to maintain features that do not generate revenue.

Keep your costs visible. I tracked every euro we spent, every month. Not because I am cheap, but because understanding your cost structure is the only way to know when you are actually profitable versus just feeling profitable.

What I Would Do Differently

Two things.

I would have invested in sales earlier. We relied on inbound interest and carrier referrals for too long. A part-time sales effort starting around month six would have accelerated our growth without significantly increasing costs.

I would have built better monitoring from day one. We added comprehensive monitoring retroactively, and it was painful. In telecom, where uptime is everything, monitoring should be the first thing you build, not an afterthought.

The Bigger Lesson

Bootstrapping is not for everyone. If you are building a product that requires massive upfront investment, a marketplace that needs liquidity on both sides, or a hardware company with manufacturing costs, venture capital makes sense.

But for B2B software with clear unit economics and willing customers, bootstrapping deserves serious consideration. You keep control. You keep equity. You build discipline. And if it works, the outcome is entirely yours.

Cantoo proved, at least to me, that you can build something real without permission from investors. The constraints are not a limitation. They are the strategy.