Suhas Darsi

I'm Co-Founder of SuperAlign. We are an AI security company focused on building secure AI for the world.

Latest posts from Suhas Darsi

• Efficiency through Self-Hosting: Strategic AI Cost Management

  Jan 29

  Early in our journey, we noticed a trend many growing companies face: as our team expanded, subscription costs climbed rapidly. Monthly overhead no longer made sense for our bottom line. This realization shifted our operational philosophy. Instead of defaulting to a 'buy' decision for every software need, we decided to prioritize self-hosting our internal tools. Today, we host almost everything ourselves, from task managers and engineering notes to internal hosting environments. We only rely on the cloud when absolutely necessary. Even for our GPU cluster, we avoid direct API calls to services like Gemini. Because we handle high-volume risk intelligence and AI processing, relying solely on external APIs would be prohibitively expensive. By managing our own infrastructure, we gain a clearer understanding of our costs and better monitoring capabilities. Beyond the financial savings, self-hosting has become a massive learning engine for our team. It gives everyone a deeper perspective on what it takes to build and maintain a system. When you manage the infrastructure yourself, you learn how systems work under the hood, what makes a product feel 'good,' and how to build for true reliability. It turns our internal operations into a training ground for engineering excellence. I want to be clear: I am against building tools from scratch if they do not align with our company's core vision. We do not want to reinvent the wheel. However, we will almost always choose to self-host an existing open-source solution before we consider a paid subscription. So many talented people build incredible products and release them as open source, and we believe in leveraging that innovation. We have integrated several powerful tools into our workflow that I highly recommend for any business looking to take more control over their tech stack. We use projects like Plane for project management, Fizzy, Docmost, and NocoDB. We also previously used GetOutline for our documentation. These tools are robust, reliable, and have allowed us to scale efficiently without the "subscription tax" slowing us down. In my next post, I will delve into the tools we use and share our experiences of what worked and what did not.

• The Cost-Per-Use Revolution: A Smarter Way to Spend Your Money

  Jan 29

  In our consumption-driven world, the difference between financial stress and financial freedom often comes down to one question: "How much will I actually use this?" The cost-per-use formula offers a refreshingly practical answer, turning vague spending guilt into clear decision-making. The math is beautifully simple: divide what you pay by how many times you will use something. A $200 jacket worn twice a week for five years? That is roughly 50 cents per wear. A $50 trendy piece abandoned after three outings? Nearly $17 each time. Suddenly, the expensive choice becomes the bargain, and the deal reveals itself as waste. This mental shift changes everything. Financial experts at The Financial Diet and minimalist advocates like The Minimalists have long championed this approach, recognizing that true value lies not in price tags but in utility. When you calculate cost per use, you no longer compare products—you compare how they will actually fit into your life. Take your daily essentials. That well-constructed leather bag might cost three times more than a trendy alternative, but if it lasts ten years instead of one, the investment pays for itself many times over. The same principle applies to quality tech gadgets, durable footwear, or kitchen tools you will reach for countless times. The focus shifts from logo appeal to construction quality, from aesthetic trends to timeless functionality. The beauty of this framework extends beyond clothes and gadgets. Even major purchases like vehicles benefit from this analysis. A car sitting unused in your driveway represents a terrible cost per use, while a modest but frequently driven vehicle—or even forgoing car ownership for rideshares and rentals—might deliver far better value depending on your actual transportation patterns. What makes this approach transformative is how it filters noise. Marketing whispers that you need the latest release, that status symbols matter, that more is always better. Cost-per-use cuts through the chatter with a single, clarifying question: "Will this genuinely serve my daily life?" Items that pass this test become worthy investments. Those that fail get left on the shelf, saving you money and mental clutter. Financial planners consistently recommend this strategy because it rewires spending psychology. Purchases become less about momentary desire and more about long-term satisfaction. You are not denying yourself; you are becoming more selective, ensuring every dollar works harder for you. The ripple effects compound over time. Fewer impulse buys mean less buyer's remorse. Prioritizing durability means less replacement shopping. Focusing on actual needs rather than manufactured wants creates breathing room in your budget for experiences and goals that genuinely matter. This isn't about deprivation or endless spreadsheets—it's about alignment. When your spending reflects your real priorities rather than retail algorithms, satisfaction naturally follows. You surround yourself with possessions that earn their place in your life through consistent usefulness, not fleeting excitement. As evidence across personal finance communities confirms, mindful spending rooted in cost-per-use analysis does not just save money—it builds a more intentional, less wasteful existence. In a marketplace designed to encourage overconsumption, this simple formula hands you control, one thoughtful purchase at a time.

• Stop Building Features. Start Solving Problems.

  Jan 27

  Here's how most product teams operate: Someone has an idea for a feature. It gets added to the backlog. The team plans it during sprint planning. The designer mocks it up. The PM writes the specs. Engineers build it. They ship it, celebrate, and move on to the next feature. Rinse. Repeat. Forever. The problem? Nobody stops to ask: What problem are we solving? The Feature Trap We have become obsessed with features. New buttons. New workflows. New integrations. The roadmap is packed, the team is busy, and everyone feels productive. But are we building the right things? Usually, the responsibility for "taste" and direction falls to a designer or product manager. They decide what gets built and how it should work. They are the gatekeepers of value. While they might be brilliant, this approach has a fatal flaw: it starts with solutions, not problems. What If We Started With Problems Instead? Here is the radical idea: What if we flipped the entire process? What if instead of asking, "What feature should we build next?" we asked, "What problem is our customer actually facing?" When you start with the problem, everything changes. Take Fizzy by Basecamp. At first glance, it is almost comically simple—just lists. That is it. But look closer, and you will see something brilliant: they are not trying to build every Kanban feature under the sun. They are solving specific problems about how ideas resurface when ignored, how priorities naturally shift, and how work actually flows without the artificial constraints of sprints. They did not reinvent project management. They just thought deeply about real problems and built exactly what was needed to solve them. Nothing more, nothing less. The Sprint Problem Nobody Talks About Let's talk about sprints for a second. The original Sprint framework—Jake Knapp's book—was five days. Five focused days to go from problem to tested prototype. Fast, intense, and purposeful. Now? Most tech companies run 14-day sprints. Nearly three weeks of planning, building, reviewing, and retercting. We have taken a rapid problem-solving framework and turned it into another way to organize work. This drift did not happen by accident. It happened because we stopped focusing on problems and started optimizing for features. We needed more time to build more elaborate features, so we stretched the sprint. The framework became the goal instead of the tool. A Better Way: Problem-Centric Product Development Here is how we do it differently. At the close of every quarter, we stop building. The whole team comes together to take stock. We pull up customer complaints, support tickets, and platform issues. We list everything broken, frustrating, or confusing. Then we categorize ruthlessly: P0: This is broken. Customers are hurting. Fix it immediately. P1: This is a real problem we need to solve this quarter. P2: Important, but not urgent. We will tackle next quarter or beyond. That's it. No feature roadmaps. No "wouldn't it be cool if..." discussions. Just problems, prioritized by impact. This approach—inspired by Railway, an infrastructure company redefining how developers deploy—is deceptively simple. But simple doesn't mean easy. It requires discipline to say no to shiny features. It requires humility to admit you do not know what customers need until you ask them. It requires courage to delete the elaborate roadmap deck and start from scratch. The Shift That Changes Everything When you build from problems, not features, something remarkable happens: You stop arguing about implementation details and start discussing customer pain. You stop celebrating shipped features and start measuring solved problems. You stop building what is easy and start tackling what matters. Your backlog shortens, your sprints become clearer, and your team becomes more focused. And most importantly, your customers get products that actually work for them. So here is the challenge: Look at your roadmap right now. How many items on it are features you want to build versus problems you need to solve? If you cannot answer that question, you might be in the feature trap. It is time to flip the script.