The community built for founders

Here are 6 traps I’d check before launching an AI-built app: Signup doesn’t ask for age If your app collects data from children under 13, COPPA can create serious compliance obligations, with civil penalties that can reach tens of thousands of dollars per violation. Google Fonts are loaded directly from Google A German court once ordered a website operator to pay €100 after a visitor’s IP address was transmitted to Google through remotely loaded fonts, raising GDPR concerns. Session replay is enabled by default Some session-replay tools can capture sensitive user interactions. In California, certain recording practices have triggered wiretapping claims under CIPA, with potentially significant statutory damages. Your marketing emails have no unsubscribe link CAN-SPAM requires commercial emails to include mechanisms such as an opt-out method and a valid physical postal address. Violations can carry substantial penalties. Your subscription checkout hides the renewal terms Automatic-renewal laws can require clear disclosures and consent before charging customers again. California has particularly detailed requirements. You accept user uploads but haven’t registered a DMCA agent If your platform hosts user-generated content, failing to follow the DMCA safe-harbor requirements can leave you with less protection against copyright claims. The scary part? These risks can scale with your users, sessions, emails, or individual violations. Your app can make $0 and still create a legal headache. So before you launch, paste this into Claude: “Audit my app for these 6 legal risks and identify exactly where my implementation creates exposure. Add an appropriate age gate, self-host fonts where appropriate, disable session replay or implement consent and input masking, add compliant unsubscribe and postal-address information to marketing emails, clearly disclose subscription renewal terms before purchase, and walk me through the requirements for registering a DMCA designated agent. Flag anything that requires review by a qualified lawyer.”» Save this before you launch your next vibe-coded app. And honestly, anchoring me might be the cheapest co-founder you’ll ever hire. 😅 Not legal advice. Laws vary by jurisdiction and situation. Talk to a qualified lawyer about your specific app. #vibecoding #buildinpublic #indiehacker #saas #startup

I keep noticing how many business problems technically have “solutions” already — yet people still lose money or patch things together manually. So I’m curious, what’s something in your business you already pay for, but it still sucks? Not looking for startup ideas or “I wish AI could do X.” I mean something concrete: you’re already spending money on it, using a workaround, or accepting the loss because the existing options aren’t good enough. What is it, and what specifically is still broken?

I learned this after spending almost three weeks improving a product that barely had any active users. At the time, I thought I was making progress. I added a better dashboard, redesigned the settings page, introduced a few customization options, and started working on a feature I was convinced would make the product feel more complete. Every time I finished something, I felt productive. Then I checked the analytics. Almost nobody was using the new features. The people who were already using the product were still doing the same three things they had been doing before. One of them had even sent me a message asking why I hadn't fixed a small issue in the existing workflow. I had spent weeks making the product bigger while ignoring the parts people were actually touching. That was a difficult realization. When you're building an MVP, adding features feels safer than talking to users. You can sit alone, write code, redesign screens, and convince yourself that the next improvement will finally make the product click. But sometimes you're just avoiding the uncomfortable work of finding out whether anyone really needs what you're building. I eventually stopped adding new features for a while. I went back through user feedback, watched how people used the product, and focused on fixing the problems that were already showing up. The product didn't suddenly become successful. I just stopped confusing activity with progress. An MVP doesn't need to impress you with how many things it can do. It needs to solve something useful for a small number of people, well enough that they have a reason to come back. Everything else can wait.

At first, I almost said yes immediately. He's been using my product for a few months, pays every month, and is one of the few customers who regularly sends me feedback. The kind of customer you don't want to disappoint when you're still trying to grow. The feature he wanted wasn't unreasonable either. It would make his workflow easier, and I could probably build the first version in two or three days. So I opened my code editor and started thinking about how I'd implement it. Then I stopped. Because I realized I wasn't just building one feature. I'd need to add a new setting, change part of the existing workflow, handle a few edge cases, and eventually explain to other users why this option existed. And honestly, I wasn't convinced this was the direction I wanted the product to go. I spent the rest of the evening going back and forth. One part of me was saying, "He's paying you. Just build it." The other part was asking, "What happens when the next customer asks for something completely different?" The following day, I didn't reject the request. Instead, I asked him to show me exactly how he was working around the problem. That conversation changed my understanding of what he needed. He wasn't really asking for the feature itself. He was trying to solve a much simpler problem, and there was another way I could potentially handle it without introducing the whole workflow I had imagined. We haven't settled on the final solution yet, but I'm glad I didn't rush into building what he asked for. I'm learning that customer feedback isn't always a product specification. Sometimes the customer knows the problem better than you do, but the feature they're requesting is just the solution they've already imagined. How do you handle this in your own product? Have you ever said no to a paying customer's feature request and later realized you made the right decision?