Subscribe
Share
Share
Embed
Founder Reality with George Pu. Real talk from a technical founder building AI-powered businesses in the trenches. No highlight reel, no startup theater – just honest insights from someone who codes, ships, and scales.
Every week, George breaks down the messy, unfiltered decisions behind building a bootstrap software company. From saying yes to projects you don't know how to build, to navigating AI hype vs. reality, to the mental models that actually matter for technical founders.
Whether you're a developer thinking about starting a company, a founder scaling your first product, or a technical leader building AI features, this show gives you the frameworks and hard-won lessons you won't find in the startup content circus.
George Pu is a software engineer turned founder building multiple AI-powered businesses. He's bootstrapped companies, shipped products that matter, and learned the hard way what works and what's just noise.
Follow along as he builds in public and shares what's really happening behind the scenes.
New episodes every Monday, Wednesday, and Friday.
George Pu (00:00)
Hey guys, I've done some deep research and also deep reflections. And I think personally, it's much easier to start with principles of what type of products we actually want to build. Right. And then actually building the product and not the other way around, you know, so I personally think in the past couple of years, I've been building this product. It's the other way around. I came up with the idea. We started validating. We started getting the market out, you know, the product out to the market and then whatever our customers tell us and they will build it. Right.
At some point, I feel like our sprints, our bio-wiki sprint has just became basically customer requesting features. So we're just blindly taking them and putting them on our market. And today I want to share with you why I made the decision, what specific reasons are for the product to fail. And you know, we can all reflect together about, know, why I can do differently moving forward and what you can potentially learn from my experience.
So the real cause of attachment is something I want to talk about first. I've been building this product for the past five years. It started when I was still at the university of Waterloo. I was still a bachelor's student, ⁓ you know, in my second year and moving forward to today, I think, you know, I obviously have gone very, very attached to the product. I've seen the early days, I've done it with different teams, you know, who came and go. And I basically took out the product and say, I really want to do it again. That's pivot. Let's do it again. Right. However,
It has continuously run into different issues and every time I think I was just trying to convince myself, you know, there's another way around. There's another way to it. Even earlier today, before I send the chat message to my team announcing that will be sunsetting some product financing, we still, I still had a hope that this product will work out. However, I think there's also a lot of opportunity costs for having that sort of attachment as a founder. And I personally know many founders actually have that sort of attachments.
For example, there's obviously this need of opportunity costs, right? When you get super attached to the product that you have, and frankly, I've seen founders who were working on their startups when I was just a college student, I saw founders spending four or five years on a product just because that's their initial product, that's their baby, you know, and obviously no one else's thoughts or mind can change their mind about it, right? And I slowly became that myself. And I think that creates an opportunity cost for you as a founder because
Many founders who didn't succeed in building their products. I've known so many of them. They're very, very good people. They know exactly what they're doing. They have great skills, execution, technical skills and business mindsets. Right. And the reason that didn't work out is not because there's something wrong with them, right? Obviously there's something wrong with the product with something wrong with the business model, but the opportunity costs they have that they're not spending elsewhere building other products. That is a huge cost.
And second, I think there's also a team confusion about the company's direction. think as we're building SimpleDirect, I've seen that problem firsthand as well. We started realizing that we actually don't have a concrete product roadmap in place. And our roadmap is essentially just doing whatever our customers want us to do, right? Instead of actually having a product vision, having a roadmap, having a clear mindset about where this product is going to go in three months, six months, nine months a year.
Right. I actually don't know anything about it. I don't know where the product is going to go in three months, six months and more. So these are all the things I think as a family, if you get attached, it becomes super, super draining and it can easily take three, five or even more years of your life. And I think when I started simple drag financing, I was looking at intercom, I was looking at Asana, was looking at monday.com, I was looking at all these different tools and how they're messaging, um, towards their customers, right. Without realizing a, they're venture backed, they are a different stage.
as opposed to where I am at the moment, right? B, I thought that was called business success. They've made it. So whatever they're doing must be correct. You know, so those are all the mistakes I've made. So instead of sticking through, you know, at this time sticking through the mistake I made five years ago, I think it's much easier to kill it, phase it out and, you know, work on something new that's actually more aligned with our values. So
With that all being said, I do want to share exactly what went wrong and there are actually a few things that went wrong fundamentally. And sooner or later, I guess I realized that instead of working hard on realizing, on figuring out this, this issue, even though I have the best team in the world, right. It's probably not possible because Peter Tio once say when the startup, it was just started. If something went wrong when it was just starting up, right. It is impossible to fix after. So I kind of realized that with SimpleDock financing and
Here are the main issues I think has been bugging me. So the first thing is we do not control the end to an experience. And this is something I've also shared on Twitter. So what is end to an experience? And end to an experience means that you control when the customer actually first got to know you until the time when the customer stopped doing business with you, right? Or the customer exits. So from endpoint to endpoint, you control the entire experience, right? Think about some examples of how, how it is. So for example, notion is quite end to end.
Right. Google doc is quite end to end, right? They don't have to like rely on any single integrated partners. They don't have to, you know, rely on any single APIs to be able to deliver the experiences. Whereas I guess modern founders, you know, it's still, I think it's still okay if you are integrating with, let's say Sendgrid or Mailgun, right. For your technical APIs for delivering emails. You might need Stripe APIs to integrate payments, so should take payment. Those are, think still fine.
However, for SimpleDirect financing, the premise was that we want to enable businesses to be able to offer financing, right? While not being a financing company ourselves. So what we did instead is that we actually integrated with over 13 different lending partners and we integrated with each one's each one of their APIs instead. Right? So what happened is, you know, our customers, businesses use us to offer us to the customers, to their customers, which we call it end consumers. And when the end consumers actually use SimpleDirect's product, the main issue is
We don't control the experience as soon as we send the customers off to the partner's API side. Right. And that created many issues. First of all, we're not aligned with what the customer is experiencing on the other side. We don't control the customer experience. We don't know exactly what lender will do. We'll ask, right. We don't know if there's going to be surprise, like, you know, surprise, know, are, uh, loan origination fee, something like that. And we've have, and I think the majority of our support ticket, 99%, uh, close to 99%.
of our support ticket. It's actually because the end consumer went to the other side to the experiences that we do not control with the lenders and they're having trouble there. So we've had so many of that different issues and I started to solely realize that it's not something that can be actually fixable, right? If we cannot control the end experience and that's rebugging us, that's created 99 % of the support ticket, maybe it's better to actually just cut it, right? So that's a huge lesson I've learned of not to be overly reliant on any single APIs.
And that cash should be applicable for many startups here. ⁓ you know, I was actually recently being pitched an idea about, basically using the Stripe slash bridge API to build a stable clean rails, you know, for customized lending, right? So that was someone, know, someone I know put this in my head, which is, which is good for the idea. However, one of the problem is that we will be relying entirely on Stripe or bridges API. And that is not something I think I want to do definitely again, right.
And with all that's being said about Basecamp, think about, you know, Basecamp basically is a project management tool that I also talked about in last episode. They actually were able to control the engine experience to a point that's actually admirable, right? They're not just saying, okay, we're the project management tool and we're going to connect with Google calendar. We're going to connect with Notion. We're going to connect with Gmail, right? Instead.
They kept everything in house. They build their own calendar. They build their own Gmail. They build their own different, you know, tools and product management tools. And even, even their internal quote unquote Slack. It sounds an intuitive, counterintuitive, but actually that's like, personally believe A it protects your piece because they don't have to be stressed out when there's another, you know, API went down from external partners. Right. And B this keeps your customer in your ecosystem, actually made it harder for customers to switch. Right. So actually long-term that's good for business. So.
I've learned, you know, technical sophistication doesn't always match customer preferences. I was basically building what I thought was impressive, but I wasn't building what the customer actually wanted. Right. And the external API dependency risk is just too big. And, know, I, I never want, if you're building a business, never base the success of your business based on external APIs and try to minimize the number of external APIs that you use as much as possible.
I understand why modern founders, especially after 2010s are using so many APIs and so many packages and PMs, different things, but there is a huge issue with it. Right. And, and for my company moving forward, we're going to try to build everything in house. And also, if not, we're going to try to use some of the open source project for the non important work, but for essential functions, we're definitely going to build in house and we're not going to, you know, we're not going to use any external APIs. And also, ⁓ there's a second.
issue, related issue I wanted to confess, which is basically, think we had the wrong customer product fit. So I also talked about this in an earlier episode. So I'll just go fast on this. Essentially we were targeting home improvement contractors who want sophisticated, you know, web-based financing tools, right? That's what we assumed. We assumed home improvement contractors who are fixing roofs, you know, who are doing HVACs or doing garage doors and repayments. We assumed they will be using web-based tools. So.
Now I obviously sounded very, very stupid, but at a time, you know, we thought this is something that customers will want it. And, and we also do have customers actually using them. So that justified our belief that everyone is going to be like that. But in reality, most, think more than 70, 80 % of the people using it don't want to actually install a mobile app. They don't want to use a web app. They just want simple phone calls and text messages. Right. And they just want us to know, you know, when my customer got funded, can you send me a text message automatically? Okay. Send me an email about it.
I just want to be informed. want to leave the end experience to the end consumers. And I don't really want to be part of, you know, using an app and trying to learn how to use it. So that's another lesson that I have learned. That's which is like, there is obviously a problem solution fit, but there's hardly any product market fit because when you use the word product market fit, means that the product is meeting the need of the market, which is partly true, but also the customers don't use the product, which I think in this case, we're not actually reaching product market fit. Right. So.
That's the lesson I think second lesson I have is try not to build complex solutions for customers who actually prefer simple ones, right? See if you can match the product sophistication to customers preferences. For example, if your customer is really easy and simple and they don't really prefer using something more difficult. Try to build something as easy as possible, right? If you have customers like I had with something like financing, obviously try to build something with Zapier, try to do something that's nice sitting alone and Twilio, you know, Syngrid.
And use that to inform the customers to remove your authentication modules, right? Just to make it simple. So that's the second lesson, which is like not having customer solution fit. And third lesson that I had is basically the revenue model vulnerabilities, right? Which is basically the business model that I have that's A, very hard to scale. So it's not scalable. And B, it's controlled by external partners, right? So basically what happens is like when we do sell a loan.
We do get paid 1 to 2 % over it, right? So our learning partner will pay us 1 to 2 % for selling the loan. However, that revenue is very dependent on external parties, our learning partner's policies and commission structured. So they can easily change that, you know, without giving us notice or giving us like very minimal notice. For example, a few months ago, one of our biggest learning partner reduced their commission by between 40 to 50 % with no warning, right? And that
actually broke our revenue model, our unit economics overnight and we can't do anything about it. Right. So when your revenue depends or at least part of your revenue depends on external partners, you're not really building a business, right? You're running a hope, unfortunately. And if you look at a company like Basecamp, which is starting in 1999 and they're still alive today and you know, 280 million revenue, 60 to 70 employees and profitable for over 25 years. So they have taught me quite a lot about how to run a company.
And I have to admit that I, there was a time between 2021 and 2022 as the market was ballooning in a tech side, genuinely doubted their approach because everyone else was doing so well, raising millions, auto-thinging air. But fundamentally, you know, after gaining clarifications of how it is and what I want, I think their approach on post-trapping is exactly the one I want to adopt. Right. So, and this is what they said about their principles. Start with principles and then build a product.
And the Jason was the founder said it would never work the other way around. they actually, so in terms of their approach, they actively fight feature bloat because complexity kind of violates their principles. And they said that they have customers writing over a thousand times from different customers about we really need this feature. And they're very clearly saying no, because we want to say to our principles. And I think that's really admirable. And that made me actually rethink about.
I woke up this morning and I got ready and I started writing about the principles that I have with Simple Direct with everything I've shared with you guys here and also I post on Twitter and also lessons I've learned, which I'll share in a moment about my principles. So they've been saying no to obvious money for decades and they killed products that doesn't align with their core values. He said he launched many products, many of them didn't work. The one that did work is their flagship product Basecamp.
And a customer request does get filtered through the principles list. So whatever does filter through at the end, they build that. So with SimpleDirect, I want to conclude by summarizing what I already did wrong. I built things first with an idea and validated it, but I built things first and I figured out principles later. You know, and the later part was a problem because then I started to realize that my principles are in conflict with what I'm building right now with my bare hands or with my team.
That's the first problem. The second problem is that I added all the complexities to look sophisticated. try to use the startup language I learned from different websites and successful startups out there, except that's not my voice, right? Except that's not the things I really believe in. I think if you're a startup founder, really need to deliver your values very, very clearly and make sure that they align with your strength and align with your values. And lastly, you know, I think I chased a little bit of market opportunities because I was thinking about building simple direct chat.
which is obviously something to do with AI and you know, like trying to catch up the AI hype train, right? Except realizing that's not a pro guy I should want to build. So these are all the things I have made mistakes on and that's costing me time obviously to trying to change everything. So I think I'm trying to chase opportunities that didn't align with my strength. I was just trying chasing hype and that didn't align with my values. And I made decisions based on competition and not customer value. I made decisions based on what I think is right, not what I think deeply by principle.
what is right and I will start in the future by starting with clear principles and adopting this framework where I will ask myself a few questions, you know, you know, for example, does this create external expenditures? that, I actually control the end to end experience for this product or do I not have any control or does someone else's failure on the third party side will implode my product experience? Second, I will ask about anything I want to build.
does this align with our value and is this just like adding unnecessary stuff? Third, you know, are we building for things for our customers and our values, or are we just building it because we think this sounds right, you know? And lastly, I will be very careful about the revenue model and making sure that our revenue model is long-term sustainable and not again, not dependent on external third parties. Right? So in conclusion, think dear founders, think about these things when you do build if whenever possible.
Try to have end to end control. Don't depend on any other APIs. customer experience will start to end. And if you're a technical founder, this is your expertise and definitely don't give up experience. I can, think, with your principal first design and customer first design, ask your customers what they want and do it that way. Right? Remember my mistake with the text messages is what customers want, but we built an entire app for it. That's not called for. And third is to look into your revenue model and business model.
Make sure that you earn the revenue directly from the customers ideally, and you don't depend yourself on third parties or just like concentrating your revenue on a few parties. Also, obviously select the markets where you have unfair advantages, Select markets where only you can do the real things. And five is like build really simple things. I talked about in an early episode about keeping things simple, and I'm starting to adopt that to every facet of my life and including the work I'm doing with Simple Direct. And I realized that simplicity does win.
Whenever you focus on making things simple, you win. Your customers win. And as a result, you win more because you own the value. So moving forward, these are the things I'll be thinking about consistently. And I have actually two upcoming products that I will be launching in a wake of phasing out Simple Direct financing. And that is the part of being a founder. I always learn, I always reflect, and I always learn something new together with you, the community. So obviously if you have any thoughts.
or any lessons or any comments, feel free to write to me at the George Poo on Twitter. You can also see all the shows and show notes, scripts and everything on foundryreality.com. So this is George Poo and I'll see you next time.