The community built for founders

I know this is probably going to annoy some people, but I’ve been online long enough to recognize this pattern. A simple product appears. Someone posts it on X. A few founders start talking about it. Then the screenshots start. $1,000 bid. $5,000 bid. $10,000+ bid. Suddenly everyone is writing “how did he do this?” posts, people are building clones, and half of founder Twitter wants to launch their own version. That’s basically what happened with Outbid.lol. And to be clear, I think the product is clever. The mechanic is ridiculously easy to understand. Pay more, move higher. The leaderboard itself becomes the content. That is excellent internet product design. But here’s where I disagree with some of the conversation around it. People are looking at the traffic and revenue and concluding that this is some new formula for building startups. I don't think it is, I think Outbid is a very good example of how quickly X can manufacture a temporary market. The product creates competition. Competition creates screenshots. Screenshots create curiosity. Curiosity creates more bids. More bids create more screenshots. And now you have a loop. But loops like this can burn extremely hot, the moment people stop caring who is #1, the reason to visit starts disappearing, that’s the part I’m watching. Not whether Outbid was successful. It clearly was. I’m watching whether people still care about Outbid when there isn't another ridiculous bid to screenshot tomorrow. Because there is a big difference between: “Everyone is talking about this.” and“ People still need this six months later.” I’ve seen enough startup hype cycles to know that founders often copy the visible part, they see the leaderboard, they see the money, they see the traffic. Then they build another leaderboard. What they miss is that the hardest thing to copy wasn't the website.It was the timing, audience, distribution, novelty and social behavior around it. That’s why I wouldn’t call Outbid a bad idea. I’d call it a very good reminder that attention is a drug, and X is very good at giving founders a huge dose of it very quickly. The interesting question is what happens when Twitter finds something else to talk about.

When I was 23, I spent a ridiculous amount of time going to founder events around San Francisco because I was convinced I needed a cofounder. Not just any cofounder either. I wanted someone technical, someone who could think through the product with me, and ideally someone good at marketing. Basically, I was looking for three different people in one person. It didn't work. I met a lot of founders at events, coffee meetups, demo days and random conversations after talks, but I never found the person I was looking for. At some point, I stopped going to these events with the mindset of “maybe I'll find my cofounder tonight.” I just started meeting people. I'd ask what they were building, what they were struggling with, what they were working on. Sometimes we'd exchange numbers and never speak again. Sometimes we'd grab coffee. A few of them became friends. And then something funny happened. Some of the founders I originally thought might become my cofounders eventually became my customers instead. That wasn't even my plan. I had started going to these rooms because I wanted someone to help me build a company. I ended up building three apps and eventually reached around $10K MRR with just 11 paying customers. And those 11 customers weren't random people I found through some complicated sales funnel. They were founders I'd met along the way. Looking back, I think I was approaching networking completely wrong at the beginning. I was walking into rooms thinking: “Who here can help me?” Later, I started walking in thinking: “Who can I learn from, and who can I get to know?” That small change made a huge difference. When you're constantly looking for what someone can do for you, people can feel it. But when you actually take an interest in people, conversations become much easier. You learn what they're building, what problems they have and where you might be able to help each other. And sometimes, six months later, that person is the customer you never expected to have. So these days I try not to enter a room with a selling mindset. You never really know where a relationship is going to lead. The person you think should be your cofounder might end up being your first customer instead.

I spent years as an engineer and later led engineering at Replicate. AI has completely changed how quickly we can build software, but fast code generation doesn't automatically mean production-ready software. These are the five things I check: 1 Can I explain the architecture? I don't need to understand every line, but I should know how data flows, where business logic lives, and how the major pieces connect. Can I break the happy path? I test failed requests, empty states, duplicate actions, refreshes, timeouts and unexpected inputs. AI is very good at making the happy path work. Are permissions actually secure? Being logged in doesn't mean a user should have access to everything. I check authentication, authorization, database policies and whether users can access someone else's data. What happens when something fails? APIs will timeout. Databases will have problems. Requests will fail. I want proper error handling, useful logs and sensible recovery instead of a blank screen. What happens at 10x usage? I look for obvious problems like expensive database queries, unnecessary API calls, huge files and operations that could become expensive as usage grows. I don't expect AI-generated software to be perfect. The real question is whether the founder understands enough of what was built to operate it responsibly. AI can absolutely help you ship production software. But “the AI said it was finished” isn't a production checklist.

I’ve built and scaled my app mostly by myself, and one of the biggest lessons I’ve learned is that there isn’t a specific user count where you suddenly need to hire an engineer. I used to think it would be something like 1,000 users, $10K MRR, or a certain number of daily visitors. It wasn’t. The real signal was when the complexity of the product started becoming more expensive than my time. Vibe coding is incredibly powerful when you’re validating an idea. You can go from an idea to a working product without spending months looking for a technical co-founder or paying an agency to build an MVP. I still think founders should take advantage of that. But there comes a point where adding another feature isn't the hard part anymore. Maintaining everything you've already built is. For me, these were the warning signs: You’re afraid to touch parts of your own code. If making one small change feels like it could break five unrelated things, you’ve probably reached a level of complexity where you need stronger engineering practices. Bugs are becoming recurring problems. One-off bugs are normal. But if you keep fixing the same category of problems, spending hours debugging production issues, or constantly asking AI to patch something it previously changed, that’s a different situation. You’re spending more time maintaining than building. This was probably the biggest one for me. If you’re spending your week fixing infrastructure, database issues, performance problems and deployment failures instead of talking to users and improving the product, the opportunity cost becomes very real. Your users depend on the product. Breaking an MVP that has 20 users is frustrating. Breaking something that 20,000 people use every week is a business problem. The more critical your product becomes to customers, the less comfortable you should be with fragile systems. AI is becoming the bottleneck instead of the accelerator. This is the one I think founders underestimate. AI can write a lot of code very quickly. But when your application becomes complicated enough, you need someone who understands why the system was designed a certain way, what will break when you change it, and how to make the architecture better instead of simply adding another patch.That doesn’t necessarily mean hiring a full-time senior engineer tomorrow. It could mean bringing in an experienced engineer for an architecture review, hiring part-time help, or finding someone who can gradually take ownership of the technical side. I also wouldn't throw away vibe coding once you hire an engineer. AI is still an incredible tool. The difference is that you’re no longer asking AI to compensate for the absence of engineering judgment. My rule now is pretty simple: Use AI to get from zero to one. Hire engineering expertise when going from one to something reliable becomes the actual problem.