Runway? Check. Users? Check. I still killed my startup

I closed down my startup, Dasht, earlier this month.

We had 10 months of runway and a healthy pipeline of users. We had passionate backers – early users who believed in us so much that they turned into our first investors. In June, we even had an offer to be acquired – albeit via acquihire – that I turned down.

Despite all that, shuttering was still the right move even though it was a tough decision. Why? Let me explain.

Photo credit: Kenneth Tan

Jack of all trades, master of none

I launched Dasht with my co-founder Hassan just over a year ago, envisioning that it will become the back-end operation system for small to medium-sized businesses (SMBs). This meant we had all sorts of products planned: customer relations management, scheduling and invoicing tools, and even a form and a website builder.

However, I learned the painful lesson that we were positioning ourselves against every single software-as-a-service tool for SMBs out there, including HubSpot, Jotform, Squarespace, Calendly, and more.

This might have been fine if we were able to identify why Dasht was superior to existing tools. But our core value proposition was “Dasht is an all-in-one platform,” which basically meant we were an inferior version of these tools.

This showed me that users find more value in one thing done very well than many things done at a subpar level. You don’t want to be a jack of all trades but a master of none.

Stuck in the dead zone

The key to making a business-to-business SaaS company profitable is striking a balance between user lifetime value (LTV) and customer acquisition cost (CAS), including onboarding costs.

While acquisition essentially cost us nothing, onboarding was just too expensive, leaving us in the dreaded “dead zone.” Despite experimenting with various price points, we were just unable to get LTV to exceed CAC.

The takeaway here is simple: unit economics matter from day one. It’s important to always ask how you’ll reach your target market with the least amount of resources.

Demand vs. demands

“Users first” has always been a core approach of mine in business building. And in that process with Dasht, many user-vendor relationships ended up evolving into personal friendships.

That’s certainly not a bad thing, but perhaps it was part of why we started mistaking customer demand with customer demands. When customers want shiny new features or bells and whistles, those are customer demands, and they aren’t necessarily good for the product.

It is more important to focus on meeting customer demand than satisfying customer demands, as good as the latter may feel in the short term.

Falling in love with the solution