What Most Technologists Get Wrong About Revenue Streams
The patterns from 5 brainstorm sessions, and how to fix them
Cristian Lascu
March 19, 2026
Last week I released the interactive Business Model Canvas and offered five free brainstorm sessions to walk through it together.
All five slots filled within 48 hours. I spent the week on calls with technologists, each with a different idea, at a different stage, in a different industry. But the pattern that emerged was remarkably consistent.
Almost everyone had a similar recurrent concern: Revenue Streams.
And the ones who had filled it in? Most of them had written something that wouldn't survive ten minutes of honest scrutiny.
The Pattern I Keep Seeing
Here's what a typical canvas looked like across those five calls:
Customer Segments: filled in, usually well-defined. Technologists are good at identifying who they're building for.
Value Propositions: filled in, often strong. The problem being solved was clear enough.
Key Resources, Key Activities: detailed. This is the building part. Most people are comfortable here.
Revenue Streams: one of three things:
The block was blank. Not "I haven't decided yet" blank. More like "I've been avoiding thinking about this" blank.
Or it said "subscription" with no further detail. No price point. No reasoning for why subscription vs. one-time. No indication of what a customer would actually be subscribing to or at what frequency.
Or it listed a revenue model that contradicted the Customer Segments block. One builder had defined his audience as "solo developers working on side projects" and then written "licensing model" as the revenue stream.
That last one is more common than you'd think. And it reveals the core problem.
Why Revenue Streams Is the Hardest Block
Revenue Streams isn't hard because technologists don't understand pricing. It's hard because it forces you to confront a question most builders would rather not answer:
Is what I'm building valuable enough that a specific person would exchange money for it?
Not "would people find this useful?" Useful is free. GitHub is useful. Stack Overflow is useful. The question is whether someone would pay. And that question requires a level of specificity that the other eight blocks don't demand.
When you fill in Customer Segments, you can stay somewhat abstract: e.g "mid-level developers at startups." When you fill in Value Propositions, you can describe the problem without quantifying the pain. But Revenue Streams forces you to put a number next to a human decision. What would you charge? What would they pay? Why would they choose to pay you instead of using the free alternative that inevitably exists?
That's uncomfortable. So builders leave it blank, or they write down a revenue model they've seen work for someone else without testing whether it fits their specific canvas.
The Three Revenue Stream Mistakes
From the brainstorm sessions and my own experience building, here are the three mistakes I see most often:
Mistake 1: Choosing a revenue model before knowing the customer
"I'll do freemium" or "it'll be a SaaS subscription" are actually statements about pricing mechanics, not revenue strategy. Your revenue model has to flow from your Customer Segments and your Channels. For example, if your customers are solo developers who discover your tool through a GitHub repo, freemium might work. If your customers are engineering managers who need to justify the purchase to finance, you need a different approach entirely. The model follows the customer, not the other way around.
Mistake 2: Pricing based on your costs instead of the customer's pain
Many builders calculate what they need to charge to cover hosting, tools, and their time, then set that as the price. This is cost-plus pricing, and it almost always undervalues your product. The alternative: price based on the value of the problem you're solving. If your tool saves a developer 5 hours per week, and that developer's time is worth €80/hour, you're saving them €400/week. A €29/month subscription isn't priced against your €15/month server cost. It's priced against their €1,600/month in saved time.
Technologists consistently underprice because they anchor to their costs rather than the customer's gain.
Mistake 3: Assuming "I'll figure out monetization later"
This is the most dangerous one. "Let me build the product first, get users, and then figure out how to make money." It sounds pragmatic. It feels like the right priority, users first, revenue second.
But here's what actually happens: you build something people use for free. They develop habits and expectations around it being free. Then when you introduce pricing, they leave. Or they complain. Or you feel guilty charging for something that was free, so you keep delaying the decision.
Revenue isn't something you bolt on after the fact. It's a design decision that affects every other block. Your revenue model shapes your channels (free products spread virally; paid products need sales). It shapes your customer relationships (free users expect self-service; paying customers expect support). It shapes your cost structure (free products need to be lean; paid products can invest in quality).
Leaving Revenue Streams blank doesn't mean you haven't made a revenue decision. It means you've defaulted to "free", which is itself a business model, just not a sustainable one.
What Actually Works for Side Projects
If you're building a side project alongside your career, here's what I'd recommend for thinking about revenue:
Start with "what would I pay?" You are probably close to your own target customer. If you wouldn't pay for it, that's a signal too: either the value proposition is weak or you haven't defined the right customer segment.
Pick one revenue stream, not three. At your scale, complexity kills. One clear revenue model that you can test quickly is worth more than a diversified revenue strategy on paper. You can add revenue streams later. Right now, prove that one works.
Test willingness to pay before building the pricing page. Ask five people in your target segment: "If this existed and cost €X/month, would you pay for it?" Not "would you use it" — "would you pay." . The answers will be uncomfortable and invaluable.
Make revenue visible on the canvas from day one. Even if it says "€9/month subscription, untested assumption." That's infinitely better than a blank block, because now you have something specific to validate.
The Tool
If you haven't filled in your canvas yet, start there. Pay particular attention to the Revenue Streams block. Let the discomfort of filling it in guide your next set of decisions.
And if you want a second pair of eyes on your canvas — especially on the revenue model, I'm opening another round of 5 free 30-minute brainstorm sessions next week.
The One Thing
Revenue isn't something you figure out later. It's a design decision that shapes everything else on the canvas.
Leaving the Revenue Streams block blank doesn't mean you're focused on the product. It means you've made the most expensive assumption in your business model without realizing it.
What I'm Building This Week
This week I started designing the next resource: The Building Loop One-Pager, a single-page reference for the 3-step framework I use for building under constraints: Shape → Validate → Ship.
Each step will have the key sub-questions you need to answer before moving to the next phase. It's the system behind everything I've shared in this newsletter so far, compressed into something you can pin above your desk and reference every time you sit down for a building session.
More on that next week.
What resonated? What did I get wrong? Hit reply: I read everything and I'm building this with you and with your input.
P.S. The Builder's Visibility Audit + the Business Model Canvas + next week's Building Loop One-Pager: three free tools that cover where you stand, where you're going, and how to get there.
P.P.S. Know someone sitting on an idea they haven't validated? Forward this email. They can subscribe at thesovereigntechnologist.com.
That’s all for this week.
See you next Thursday.
