The community built for founders

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?

I started the company from my apartment in India. Most of my customers are in the US. On paper, that sounds pretty normal now. The internet makes geography feel irrelevant. In practice, it isn't always. My workday starts when some of my US customers are still asleep. By the time I'm getting into the really important part of my day, they're already finishing theirs. A customer sends a message at 10pm my time and I know that if it's something important, I'm probably dealing with it before going to bed. Sales calls were another adjustment. I initially tried to fit everything around my own working hours. That didn't work particularly well. So I started taking calls much later than I was used to. Some days I'm talking to customers at 9:30 or 10pm, then going back to development afterwards. There are also smaller things. Pricing in dollars while paying most of my expenses in rupees. Understanding how American customers describe problems. Figuring out which holidays actually affect my users. Learning that something I considered a "small delay" can mean a completely different thing when a customer is waiting for an issue to be fixed during their workday. But there's one thing I really like about it. I'm not limited to the market around me. I can wake up in India, build the product here, talk to a customer in California, get feedback from someone in New York and have revenue coming from a market I've never physically visited. I used to think being far away from your customers was a disadvantage. Now I'm starting to think the bigger challenge is simply designing your company around the distance. Different timezone. Different market. Different expectations. Still the same product.