Transcript: He Built a $20K/Month SaaS From a Weekend Project (No BS Guide)

This transcript was auto-generated from the recording and lightly edited for readability. Speaker attribution is best-effort. It serves as an archival copy in case the original source becomes unavailable.

Gabriel: [00:00] Everyone wants to build a SaaS, but nobody tells you the actual steps that are required to do so. Today, we’ll do exactly that with Lukas, who built Stagetimer, a countdown software for live events, and grew it from a weekend project to now making over $20,000 a month. Today, we’ll be walking you through every stage from finding the idea to actually growing it. Lukas, welcome to the podcast, man.

Lukas: Hey, welcome, Gabriel. Yeah. Pleasure to have you on, man.

Gabriel: So, let’s start with step one. How do you find the right idea? Like, there are a million ideas out there right now, especially now with AI, all these tools. You can build marketplaces, you can build tools, everything like AI wrappers. How do you cut through that and land on something that’s actually worth building?

Lukas: Right. I have worked in a startup that did metal manufacturing, laser cutting. And I just recommend you to go a little bit beyond your immediate contacts and look at the other departments, right? Sit with a salesperson, sit with an operations person, sit with HR. Just make a bit of friends and look over their shoulder and let them explain to you what they’re doing. And you will find that many people

[02:00] are spending a lot of time on tasks that you think, “Man, I could automate this.” And now with AI, even more. Like, with AI, this is like three commands and I could automate this away. This is what you want to look for. These are the really cool opportunities.

In my case with Stagetimer, I was observing somebody who had a recording studio and he was jumping up out of his chair and going to the other room, clicking start, and I thought, “Surely this is not a process that we can’t simplify. We can make something very remote controlled — click here, over there it starts.”

But let me make a very classic, very hands-on example. In that startup, they needed to know the price of sheet metal, right? You have different sheet metals — stainless steel, different grades, copper, and all these materials. And they needed to know the prices of each of these. What is a square meter? And the price is actually not static at all. It goes up and down a lot. So they went to these websites where you can see the price and they would make these gigantic lists and try to keep them up to date every week.

So we got to the point of, “Why don’t we build a scraper for it? Like, surely this is automatable. Some kind of database of prices that is kept up to date.” Classic engineering job. Saves tons of time and is not really that difficult to build. That’s exactly what I mean, right? You look around, especially people who work in other departments than you, and you look at what they spend the most time on, and ask can this be easily automated? These are absolute winners.

Gabriel: That makes sense. So to kind of sum it up — if you work somewhere, or

[04:02] even if you’re not working anywhere, some of your friends are working somewhere. You have the ability to find someone who is working somewhere and just ask what they’re doing on a daily basis that’s taking a lot of time. Some of these manual tasks, like copy-pasting from a website to a sheet — and there’s human error there as well. It’s not just time. People make mistakes and software won’t, right? And try to find these niche ideas that might seem small, but to that certain user or that certain avatar, it’s half of their day, and you can automate it and they will pay for that.

Lukas: Exactly. And then you get to the next step. I think this is already very good to think about — validation. I have been building for five years and countless times I’ve seen people build their tool and then contact me and ask, “Hey, how do I get users? How did you get your first user?” And very honestly, at this point it’s almost a bit too late to think about this. It’s still good to think about it, but it’s a bit too late.

The best ideas — if you have a bunch, if you make a list — are the ones where you can immediately think of somebody who would use it. Let’s say you have this friend who works in a job. Take my example — the guy in operations who needs his sheet metal prices. If I would build this tool, I immediately know that person would use it. Now, I may not know yet how much they’d pay for it. But the first step is: is it useful and do I know people who would use it?

I’m a big fan of just making it free at the beginning, just to get this sense of — do people actually use it? Call it early stage beta, experimental, it doesn’t matter. Just

[06:02] give it a label so people know eventually it may cost something. But if you cannot think of the first person who would use it, it’s already a bad idea.

Gabriel: That makes sense. No need to search for some external validation outside — if you don’t know anyone who might ever use this, or if you yourself wouldn’t use it, it would just be a lot tougher on you. You like the free stuff — make a product for free first, validate it on free, and then of course move from beta or whatever it is. Why is that? Did you find success with that, or is there data behind it?

Lukas: So the honest answer is there are different thoughts on this. Some people put up a fake payment page and see if people actually click through. Some people do a waiting list and get interest that way. I’m not saying any of these methods is wrong. All the products I made, we always did it free first and sent the link to people we knew would need it. And then we observed if people actually used it.

I think this question — does a person use it, and do they come back to use it again? — is part of product-market fit. This is the first question you want to answer. If people don’t come back, you don’t really have a good product on your hands. So you need people to use it, and it actually needs to solve a problem for them so much that they come back. This is when you know you have a winner.

And I just feel like it’s easiest if the product is free. Because then you take away all these obstacles and you can just send out a

[08:02] link and say, “Hey, can you try this? What do you think about it?” It’s very easy to advertise — quote-unquote — free things. For example, if you go to Reddit and look for the specific subreddits about your product, you can say, “Hey, I did something that solves your problem. Do you mind having a look and telling me if it’s good?” It’s kind of an honest question you can post there and it’s not necessarily self-promotion, because there’s no money attached to it. So it gives you a bit more surface to put your tool out and get some feedback.

Gabriel: Yeah, that’s cool. Okay, so we have an idea, right?

Lukas: Yeah.

Gabriel: And we need to do some validation before publishing anything. Then we publish something and then we do more validation. Correct?

Lukas: Yeah.

Gabriel: But how do we publish something? Step two is: how do we build something? Are we doing it alone? Are we doing it with AI? Are we doing it with other developers? I know you built it yourself because you’re technical. But what about people who aren’t technical? Do they just use AI and vibe-code it? Do they find developers? I mean, Gabriel, you’re probably in the best position because you are doing this a lot for other people. What do you think is best?

Gabriel: Yeah, depends on who you are, right? If you are a developer who wants to start an indie company, then do it yourself with AI. Like, my point of view is you can’t be a developer nowadays without using AI. That’s the first thing. You must use it and you must grow as it grows — learn new techniques, try different things, and see what works for you and build yourself a workflow.

[10:02] But if you’re not technical, it becomes a bit harder. You might try Lovable or V0, whatever it is — any tool that can build you an app — and try to vibe-code it. But what we see most with founders is they try it. I’ve seen maybe one founder who successfully validated an idea that way. Like, the codebase was still a mess — it was not usable, we had to rebuild — but they did get some users. But 95%, maybe more, they get into this loop of trying to vibe-code an app, and then telling it, “I want this one more feature,” and then it builds it but breaks ten different things. Or, “Fix me this bug,” and it fixes one thing but breaks others. They get into this loop of trying to get anything working and they don’t get it. And a lot of them — the security is horrible with that, especially if non-technical people are using it.

So what I found works best is: if you’re non-technical, you need to have some budget for a good developer — a good senior developer who utilizes AI and can move fast and doesn’t overbuild. Like you said, you built Stagetimer — it’s one feature. Try something smaller. Try something that solves a very specific problem to a very specific group of people, see how it goes, and then build on top of it. But I still think you need someone technical who can build it the right way. I don’t think vibe-coding is there yet.

Lukas: Yeah, let me actually repeat the problem you described because it’s really true. The problem is, if you build a tool and you start in whatever way — vibe-coding, AI-coding — you will eventually run into this situation where your app has become complex. There’s a lot of code and your AI cannot

[12:03] put it all in context at the same time. So it will start making mistakes at the edges and these will heap up very quickly and become unmanageable. It’s a classic engineering problem.

And your suggestion is right. Let me describe why it’s really good. So what you want to do to validate a product, you want to build a so-called MVP — minimal viable product. What an MVP is: it does the core business. My timer is a good example. The MVP — you click start on one screen and on the other screen it starts a timer. You cannot think of anything simpler than that.

Let’s take the sheet metal example again. The simplest example is an email that comes into your inbox every day or every week with an Excel sheet of prices. That’s the core use experience you want. And now you think, “Okay, how can I build this?” The first answer really is: either you vibe-code it together — and I did this also with products — with the knowledge that this is a throwaway prototype. You code it together, it needs to do one thing, and afterwards it’s going to go in the trash. This has to be the mindset. Or you say, “I don’t need to code this at all. I’ll just do it manually — Excel sheet, I can just write it myself. Or I can ask AI to do it once or twice, or do a workflow out of it. Use Zapier or n8n or something like this.”

You just want to think of the core use experience, build it once, and see if it works — if people use it, come back, do it again, use it again, want it again. And then the next step you described is really important. I think we’ve all seen this: we’ve all built products where we

[14:05] thought it’s great to get a cheap developer — and then you end up with more work in the end. In the beginning it might be nice, but eventually it just piles up more work than it’s worth.

So I want to reiterate: if you find a good developer, a senior one — they may be very costly, right? We’re talking maybe $6,000, $8,000 a month on the high end, maybe even more. But what they can do is think about the system as a whole and use AI like their own fleet of employees, and get to the point incredibly fast. And if they’re really good — and those are the ones you want — they can’t just write code, they can also communicate well. You can tell them, “I need this,” and they ask you really hard questions about it. They can ask you about cases that you never thought about but are really important. If you find someone like this, it’s worth gold.

And this is the next step, right? You validated your idea, you see users come back — time to take some money in hand, or if you are skilled yourself, build it for real. But always: if you vibe-code something at the beginning, vibe-code it as a throwaway prototype.

Gabriel: I think that’s a perfect point you made. And it’s really — right now, one senior developer is equivalent to a team of five from three years ago, literally. Even more, if they’re really amazing. And you’re right — a good developer and a good communicator will challenge you. When you want to build ten different features, they’ll still try to keep it leaner just to get it out, get some users. A good developer

[16:05] will tell you, “That won’t work,” or “We have to slow down,” or “Let’s do it this way.” So I think that’s a great point. Go build your MVP — like the real MVP. People say MVP and then they have 15 features and a whole product. That’s not an MVP. If we think about a real MVP: one feature, something really simple — automate it, or do it manually if you need to for a couple of users to see if it actually works. If it’s needed. And just throw it away. Get a developer if it works, if you get some good feedback. Throw it away, get a developer, build it properly — and don’t cheap out on a bad developer, because then you’re back in the cycle of building something you’ll need to throw away again, but it’s a lot more time-consuming and money-consuming. So be careful there. Really be careful.

Lukas: Yeah. And what you said is really good — don’t build an MVP that has 15 features. This is really important. It is completely underrated. Once you start building a product, you think, “Oh, it needs to be able to do this and this and this, otherwise it’s not worth anything.” If your product is not worth anything with the one core feature, the additional ones won’t save it, or at least won’t save it easily.

If you get venture capital and millions and build a great idea, those companies can do that. They can build a bad product — I’m sorry, but they can — and just load it up with features and press it into the market with marketing. But you’re talking about bootstrapping. You can’t do this. It’s impossible. If your first core feature is not getting users in the door and coming back, your product is likely not going to work.

Gabriel: This is perfect. We’ll quote you on this. This is amazing.

[laughter]

Yeah. Okay, so now we have our idea, right?

Lukas: [18:05] Yeah. We found an idea. We built an MVP — our little small MVP that we threw out, and we rebuilt something proper with developers, and we are getting users in. Yeah. Or at least like we validated it, we built it right. How do we get — so the next step is how do we get actual users that stay here? Like we got some feedback, but how to grow it now?

Gabriel: Yeah, this is probably the hardest thing. It’s often a thing that people don’t actually think about when they build a product, and then they hit this — “I’m launching. How do I get users?”

Lukas: And I’m tying it back to what I said before: if you don’t know a person that would immediately use it, you already built the wrong thing. But once you know a person that would use it — even if it’s just a single person you can picture — in marketing they call this a persona, or an ideal customer profile, ICP. So you think about the person: what are they like? What are they? Where do they go? Where do they look for information? What are they doing all day long? And that’s when you try to understand, how do I get to them? How do I position my product so that they find it?

I made B2B examples, right — business to business. It’s definitely harder in this area. If you do a consumer product, the answer is usually TikTok or Instagram or Twitter or YouTube. But when you are in the B2B area, it’s a bit harder. The answer can go all the way from print media to trade shows. LinkedIn — I feel it’s very difficult when it comes to marketing. But often it kind of boils down to probably Reddit, because Reddit

[20:05] has all these very specific subreddits where people — even if it’s just a few thousand people — have a very specific interest and they gather there. And if these are exactly the people you see as users, this is essentially a goldmine. This is perfect.

Gabriel: And how did you — what did you do for your product? Was it Reddit as well?

Lukas: Yeah, so this is — I say this because this is how I did it, right. In fact I looked on Reddit; it took quite a while for me to find the subreddit that fits with the people that would use my product, that I thought would use my product. I found two, posted there — exactly what I said right here: here’s a free tool, why don’t you try it out, I made it, give me some feedback. And I got 50 answers. It’s amazing, it’s great — 50 people is better than nobody. And it’s actually people that tried it and used it, and some of them came back. That’s why I continued building it.

Now, Reddit is the first step — it cannot be, it’s not a long-term marketing strategy. It’s more like getting the first users, getting the first people that actually use your tool, that you can also approach and interview and ask, “Hey, how do you use it? What do I need to build around it so it’s even better for you?” And then I would say the next step is Google Ads and search engine optimization — or now with AI, building out content pages that describe your tool, not in the way you think it should be described, but in the way it works for the people that you built it for.

Gabriel: This is amazing. Okay, let’s dissect those two, right? Let’s go a bit deeper on Reddit. So you find a subreddit that’s really niche — a subreddit of your

[22:06] users, right?

Lukas: Yeah.

Gabriel: And you would write a post — are there any tips on writing this post? Is it more personal story? Is it actual value proposition — “Hey, I had a friend who had this problem and I built this for him, guys go use it, it’s free, give me feedback” — or is it more value prop? Is it story-driven? Do you try both? How do you go about that?

Lukas: Yeah. I found the best thing is to ask a question — an honest question — or, as you said, tell a story. People love stories: “Here’s what I did, and here’s a friend I had, or here’s somebody I observed, and here’s something I built for my cousin.” This kind of thing works because it’s honest, it’s simple, it’s approachable. People like to help out and see cool things that other people make.

Now, you have to differentiate on Reddit, right? Because there are subreddits called “small business” and “entrepreneur” and stuff — those are a different beast, those don’t count. What I mean is, in my case it was like audio-visual or lighting design or whatever — whatever you would build something for. Like if you do the metal thing, right, you want to find something in like sheet metal, or — I don’t know — these subreddits.

Gabriel: Yeah, something small, something specific. Okay, and then tell a story, ask an honest question, ask for feedback. If your product is actually valuable, people would be more than happy to give you feedback.

Lukas: Absolutely. Especially if it’s free. I think that’s where a big part of what you said before comes in — launch it free, just test it out. Because there is no barrier to entry; they just register and try it, and if it works they love it, they stay. And then maybe if

[24:07] it doesn’t work, they give you feedback, and again, that’s good.

Gabriel: Okay. And from the standpoint of SEO, you said go build pages about your product that other people would search for. In your specific niche, like there are different conferences maybe — I’m not sure what exactly we are serving — but how do I put myself into their shoes? Do I see what my competitors are doing and try to replicate that? Do I ask my actual users? Or again, go to Reddit to validate what they were searching for and then build it on the SEO side?

Lukas: So the king of it is if you can ask your user, “How did you find me?” And if they tell you how they found you, that’s gold — but this is very hard to do, and they very rarely give you the real answer because they just forgot. Like, they Googled something — what did they Google? They don’t know anymore.

So the next best thing you can do is ask them, “What did you do — what did you use instead? What did you use before?” In my case it was, “Oh, I used a Word document and I just edited it and showed it on the other screen.” Like, super stupid answer. But you want these stupid answers because they tell you a lot.

And now in the age of AI, content is cheap — it’s almost free. Everybody can write a page for any search query. If you go on a search engine tool like Ahrefs or SEMrush, you will get these lists of keywords and they tell you the volume and how difficult it is to rank for them. But the trick is that everybody has this information and everybody can target these keywords with their AI-generated content. What they can’t do is find the keywords that are not listed in these lists. And these keywords you only find by talking to your users and asking these questions:

[26:07] “What do you do instead?” And often you find that people search for — in my case it’s like, “How do I show a time to a person on stage?” or “How do I replace this in this software?” or “How do I do a timer with this other tool?” And these are the golden search queries.

So you want to write content that addresses the workflow that people already have. They already have a workflow, they already use some tools and stuff, and then you say, “Okay, position my tool in connection with the other one. How can I use my tool together with this other tool? How can I use my tool in this situation? How can I use my tool to solve this problem?” And this is a bit of work — don’t just throw it into AI and have it generate a page. Actually make sure the page is useful for a human. If they come to the page and read it, it’s almost like a step-by-step guide on how they solve their problem: you start here, you connect this, you do this. You can use these kinds of things to build it together. And in my experience, these are the winners. The trick is they get very low search volume sometimes, but if you’re able to track from them landing on the page to actually using your tool, you’ll find these pages often have very high conversion. Which is worth it.

Gabriel: Specific, very specific. Yeah.

Lukas: Now I talked a lot — go ahead.

Gabriel: [laughter] No, no — this is perfect. I think you nailed it down perfectly. So okay, to recap: we have an idea, we validated it, we built it properly, and now we are getting users in — we are growing. But what I find a lot about founders

[28:09] that we work with is there is a next thing that’s a big problem, and that’s churn.

Lukas: Yeah.

Gabriel: So you grow a lot but you lose more. Or, “We grew 10% last month, which is amazing, but we lost 15% of our users.” How do you keep them glued to your product? How do you nurture them?

Lukas: Let me — you said churn — let’s describe why churn is a problem, because I think when you start out you don’t really realize how big of a problem it is.

Churn is measured in the amount of people that leave you from month to month — that use it and then don’t come back. A high churn, as an example, is 15%. That is 15% of users that used you in January who don’t use you anymore in February. Now 15% sounds small, but it is a gigantic amount of people. Let’s say you have a thousand users — 150 will leave. That means if you want to grow at all, you need to find 150 new users just to break even, and then more than that to grow. And if you are even bigger — 10,000, 100,000 users — you understand how this number of people that leave you is gigantic. It’s very hard.

So in the beginning it’s hard to do this and it’s very difficult to measure if you have very small numbers. But what you want is churn between three and five percent — this is considered healthy.

And how do you do this? So what you do — please interrupt me. I’m talking a lot. Or should I just go on?

Gabriel: No, no, this is perfect. Yeah, I want to hear your thoughts. No worries. If I have something I’ll drop in.

Lukas: Yeah. I think you are more of an expert here than I am, because you’re an actual

[30:09] — I had to fight with that a lot. That’s why I’m here.

So we had exactly this problem. What you want is your user to come back. So even if you get your first 10 users, you want to actually talk to them, write them an email, and ask them, “Hey, how do you use my tool?” You want to understand the usage pattern.

Let me make an example with Stagetimer. People use it in two ways. There’s the company that gets hired by other companies to make their live streaming event. They have two, three events per month. So they get my subscription and they use it all the time — they probably get a yearly subscription because they’re going to use it every month anyway. And then there’s the other kind of user: they have a conference once a year. That’s when they need it, and afterwards they don’t need it anymore. So they get it and they cancel it.

We looked at both and we understood that all our churn comes from the second — the one that uses it once and then doesn’t need it anymore. And not only churn, but also extra work, because they forgot to cancel and then they wrote us and said, “Oh, can you reimburse us? We didn’t use it, can you cancel us, can you do this and this and this?”

So we said, “Why don’t we bake this into our product? You get your yearly subscription for the power user. But then you get a one-time package. You buy it, you use it for a month. That’s it. No subscription, no repeat purchase, no issues for you.” But on the flip side, this one month is incredibly expensive compared to the yearly. I think we calculated that

[32:09] if you run events for 7 months, it’s already worth it to buy the yearly subscription package in our case. So we just made it really expensive. And it worked perfectly. It fit exactly.

People were happy on this side because they said, “Oh, I needed it once — I just buy it and it works.” And people were happy on the other side because they can use it cheap, use it all the time, wonderful. And additionally, people still say, “This is great. I buy it, I put it on the expense report, I don’t have to break down some subscription fees. Ideal. Exactly what I needed.”

Our churn fell to 3%. Our growth slowed down, of course, because we now only had the yearly subscription — we took away the monthly. But it was really healthy growth. The curve is really nice, very smooth and growing slowly. And with the one-time packages, we still got the money — it was still coming into the account, it just didn’t count as subscription revenue.

Gabriel: Yeah, and all this extra work that you had to do just went away, right?

Lukas: Yeah. So you could say, “Well, you just shifted some pricing around.” No — we made our users happy. We structured it exactly how they needed it. And this is the key: the happier your user is, the more they come back, and — this is very important for B2B especially — the more they recommend it to others. They say, “This is so simple, it’s cheap, it works — use it.” And the earlier you can build this and fix these problems, the more, long-term, you just get this growth engine and it goes rocket ship.

Gabriel: Yeah, makes sense. And I think the big trap that a lot of founders find themselves in is they see a big churn and they immediately think, “Oh, my

[34:09] users must be wanting these five features. Let’s build them.” Maybe that’s true. Maybe. But the chance of that being true is very slim.

So, to sum up your advice — if I understand it correctly, please let me know — is: don’t rush into thinking you know why people churn. Actually email your users. Ask, ask, ask until you find out — maybe there is a new feature they’re missing, maybe they found a better tool, maybe something is annoying them, maybe it’s a bug you don’t know about, maybe it’s like in your case, restructure your pricing, create a new plan for this specific type of user. Actually ask your users, find out what it is, and then solve it one by one. It may be multiple things. You don’t know.

Lukas: It sounds so simple and you would be surprised how few people actually do it. Mostly the answer is, “Oh, we need three more features to compete with this big guy who’s doing this.”

Gabriel: Yeah.

Lukas: No. Ask, ask, ask. And to say something about the big guys — it’s often actually the opposite. Often people come to you because you are not as complex as the other guy. Yours is simpler to use, it fits. Sure, it doesn’t fit all the people that use the big tool, but the ones that like your tool better, they come exactly because it is more perfect for their situation.

Gabriel: That’s 100% right. And right now I have one founder — a recent client — they are building their internal tool. We are building it for them, like the internal software, because they are so tired — there is no perfect solution for them. All the other softwares have 10 different features, it’s confusing their employees, it doesn’t make any sense. They need only one specific thing and we are building it for them.

Lukas: Yeah. So if you can also find these kinds of deals — like go build it, make it into SaaS [36:09] Right? Because there are actually people there. Okay, cool. So we have an idea. We validated it. We built it properly. We got some users. We decreased our churn. What’s next? Like what do we do now?

Gabriel: I think that’s like — you kind of just maintain it, and do you — on your product, do you have other features, or is this like, point blank, this is what we do? Are you growing it a bit? How are you trying to maybe make it bigger, or are you fine where you are at?

Lukas: So what you will find, when you are at this stage — let’s roughly define it — let’s say you have like 3,000 users, $5,000 monthly revenue. That’s kind of, you know, this is like the first push. When you get there, your tool has arrived, usually, at a certain market level. Like, “Okay, it is a tool. It’s useful.” At that point, what you will find is that not only do you get the customers that you first envisioned, that you first targeted, that you first thought, “This is my customer” — you will get more and more customers that come from odd angles. Let me give some examples. For us, this would be like a horse racing course. They say, “Oh, we’re using you to time our horse races.” It would be a nightclub that says, “Yeah, we — you know, I have no idea how they use it, but somehow we have a nightclub.” Or that would be like a CrossFit training gym. They say, “Oh, we’re using it for interval training.” So suddenly you understand, okay, there are use cases. They use your tool not because it’s perfect, just because they found it and it works well enough and it kind of works for their use case. And now you can

[38:09] think: do I expand my tool? Do I add more features to bring them in? Do I specifically not want to add more features in their direction, but keep it focused? Do I want to make it wide? Do I want to make it tall, in terms of scope? Do I want to add a second product that kind of reuses most of the code and is perfect for this other group of people? And then on the marketing side, you can think about the same things, right? You can say, “Okay, now I targeted my main user — what about this other guy? How can he find me? What do I need to write on my website so that he also finds my tool? Do I need to extend my documentation? Do I need to use simpler language?” In our case, our target customer is a technical person — they’re probably not afraid to use a little bit of scripting, so we can expect some technical expertise from them. That’s how our documentation is written. But once we got the horse race and the nightclub, we understood: “Ah, maybe let’s extend our documentation a bit and also reach the people that have never used an API, that have never used this kind of interface before.” And describe it for them too — what are the principles, what are the ideas behind it, how do you build a show, what is important in a show that you’re running. So this is really the next step. It comes from the users that you get, and then you understand, okay, this direction, here I can expand, here I can expand. And then you have to make decisions — here I don’t want to expand, right? Here I want to stop, otherwise I become Photoshop and get every function, every button, and nobody understands how it works anymore.

Gabriel: Yeah, I think if I can pull out one line from this: always go back to your users.

Lukas: [40:09] Especially if you are at this stage it becomes simple — not easy. Not easy, it’s hard. It’s a lot of work, you need to be calculated. Like you said, you can’t take every opportunity. You have to know what you’re doing. But it’s simple in a way: if you’re stuck, go ask the people that are using your app. You are probably not a core user yourself. So go ask people who are. See what they are doing, see what kind of companies they are running, and see if it’s a fit.

Gabriel: Maybe it’s not — maybe someone fluked in, like the nightclub guy, maybe that’s one and that’s it, right? Maybe you don’t want to expand there. But horse races — that sounds perfect, right? So maybe you expand there. But ask your users. Ask your users again.

Lukas: Exactly. And I would add one other topic that kind of weaves through everything we have been talking about, which is the idea of pricing. How do you charge? We have kind of skipped over it because pricing is often, you know, monthly subscription — bam, done.

Gabriel: Yeah.

Lukas: But it’s not like that. I think of it differently. I think of it in two ways. One is — I usually use the Dropbox example. Dropbox is a very old company in internet terms, but for those who were around at the beginning, they did something genius. When they started out, this wasn’t really possible to just pull a file onto another computer easily, and they said, “Here, you get” — I think like 1 GB or 5 GB of space — “and if you share the link with somebody else and they also sign up, you get a little bit more, like 250 MB more.” Huge deal back then. And I love this idea that the product itself kind of gets better when you share it, or

[42:09] that the sharing is built into the product. You upload something, you give the link to someone — “Hey, download my thing” — and then it says, you know, “If you also install it, both of you get 250 MB extra.” And I think when you build something, it’s really cool to think about this: how can I build shareability into my tool? Not just “share on Facebook” or “share on Twitter,” but how can my tool enable other people to see that this person is using it? Spotify did it perfectly, right? They have Spotify Wrapped at the end of the year — it’s just screenshot-worthy and you can share it: “Look at my top songs.” Perfect. In Stagetimer, what I’m using is kind of built in — you send a link to somebody else and they open it on their screen, and there’s my logo. And if you use it for free — that’s why I have a freemium — you always see my logo, and if you pay for it, you can remove it. But these kinds of thoughts — how can I build this distribution of my product into it? I think this is underrated. You cannot measure it, there’s no statistic that tells you if it works, but it does. It does.

Gabriel: Yeah, word of mouth. Word of mouth. Yeah. And sorry — I wanted to ask, for your specific product, what does analytics look like? How many people come from where, if that makes sense? Like are you mostly word of mouth? Is it ads? Is it organic?

Lukas: Yeah, so we do run ads, but [44:09] the pie looks like this: about 30% is word of mouth, people coming from recommendations. And then the other 30% is Google search, and the rest is kind of made up by bits and pieces — a bit of YouTube, a bit of OpenAI, a bit of Claude, and stuff like that. Of that Google portion, there’s a certain amount from search. Our niche is very small, so we found out that if we just put a lot of money into search ads we don’t really get good results anymore — we get people that search for birthday timers and end-of-year timers and things that don’t concern us. So we found out that up to a certain amount of spend it’s good, we get good stuff, and after that it doesn’t really make sense. So that’s why it’s a small percentage, but it helps.

Gabriel: Okay, cool. Oh yeah, if you remember where you stopped, just keep going.

Lukas: Yeah, so I said it’s two things with pricing. You think about your price and you think, let me do a monthly subscription to use my tool. Now when I first built it I thought: we are selling to businesses, how do we get to a big business? How do we sell to a Microsoft? It’s not easy because you start out and you have no reputation — why should a big company use your tool? And my thought was, well, I probably won’t get the big company, but I will probably get a lot of small contractors, small freelancers that just need a cheap tool. But they are the ones that are invited to these events as contractors, as freelancers — “Hey, can you come and do your thing for us?” And they come, and somebody asks, “Do you have a timer?” and the guy says, “I have a

[46:10] timer.” He puts it on screen. And then the big company sees the tool, it works, it does the job, and they say, “You know what? Why don’t we use this next time we have our own event?” So this was my assumption — and this is exactly how it happens. And I said, let me put this into my pricing. Let me have a cheap price that is a no-brainer for these freelancers to pick up if they need it. And then let me have an expensive price that is interesting for bigger companies. Making that cut is incredibly hard — I probably haven’t done it well, like which feature goes into which category. But often you hear the advice: “Just raise your prices, raise your prices.” And in my case I say no, actually we want to keep this cheap price because it is the marketing engine for the bigger price. It’s kind of built-in marketing in the pricing. You get what I mean — I’m thinking about this distribution of my product in every single thing I do. It’s not like, “Here’s pricing, it’s completely separate, it has nothing to do with it.” No, it’s all built in. It’s all one thing.

Gabriel: Isn’t it perfect? And it’s kind of an upsell, right? For people that need more or want more.

Lukas: Yeah, which works nicely.

Gabriel: And are you going to these events a lot? I’m assuming you are, right? Trying to get clients there, or is it more remote? When you say “these events,” what kind of events do you mean?

Lukas: Let’s say your company — someone is using your timer at an event, a conference, or whatever it is. Do you go there actually in person to try to see other people, or no?

Gabriel: So I’ve been to a few events and I’ve [48:11] been to a few trade shows. In our case we kind of drew the conclusion it’s really expensive to go there and do this, and the effect is really small. It’s worth more if we spend our time and money on marketing it online — Google search and better content.

Lukas: Yeah, and you would need to get how many clients from that one trip to make it worth it, right?

Gabriel: Yeah, makes sense.

Lukas: And even observing trade shows, you often see it’s established brands and they often have sales talks, or they make meetings there — they invite their existing clients. It’s not a good tool for finding new customers, we found. It’s more like a good tool to maintain relationships with the ones you have. Maybe it’s different in other cases, but that’s what we observed.

Gabriel: Before we wrap this up — what’s one thing, like the craziest event or anything that your tool was used for? Do you have a crazy story? Something big or something crazy or whatever it is?

Lukas: [laughter] I mean, we have really cool things, but unfortunately I’m not allowed to talk about them, or I shouldn’t, because it involves NGOs and sensitive stuff. I think one of the biggest headlines is that one day I wake up and I see people messaging me like, “Oh, did you see? Your tool was used for the Trump campaign.”

Gabriel: Really?

Lukas: They share this picture — I have the picture on my website. Now, I’m not endorsing Trump or anything, but I just found it interesting. They share this picture and it shows somebody speaking and there’s a gigantic screen, there’s my timer, and it says, “Trump is waiting, please get off stage.” And my logo is right above it, and I just thought, you know, that’s kind of cool.

Gabriel: That’s insane. Yeah. You’re not even — you don’t even know how many people it affects, and then when you see something like that, it’s

[50:11] like, oh, nice. This is big.

Lukas: And I do remember I was just curious, so I checked out the Reddit threads where this was posted. And some people were asking what kind of timer this is, and then other people answered, “Oh, this is Stagetimer, I use it all the time.” And just this — I had nothing to do with it, but just people organically knowing my logo or my tool and speaking about it — it’s a validation, right? It felt good.

Gabriel: Yeah, I can imagine. That’s awesome. Look, this was really helpful, and I think the audience will find it really helpful as well. Thank you for coming on. We must do this again sometime. If you have anything to plug — your Twitter, your website, whatever — feel free to do that right now.

Lukas: Yeah, so Twitter has kind of turned into a lot of opinions. I try to be a bit more real. I hope it works. So if you want to follow me, it’s _lhermann — “Hermann” with one r, two n’s. Happy to see you there. Happy to engage.

Gabriel: Perfect. Thank you very much, man. This was awesome.

Lukas: Thanks.