This isn't a shutdown story or post-mortem. It's a reflection on decisions that made sense at the time, and what I understand differently now.

I recently stepped back from the B2B SaaS company I co-founded, Build Health. The business is still operating today, doing roughly $1M in ARR and running profitably.

Looking back, there are several decisions that made sense at the time, but that I'd approach very differently if I were starting again. I'm writing these down partly for my future self, and partly in case they're useful to anyone else building in messy, real-world conditions.

Lesson 1: Avoid conflating a "whitespace" with a long tail.

I've always been drawn to overlooked, niche opportunities. That instinct led us to build tools for non-English-speaking SMBs (e.g. nail salons, massage spas), a segment clearly underserved by modern software.

What I eventually realized is that the "whitespace" we thought we'd found was, in many ways, a long tail of businesses that were slow to adopt existing technologies for structural reasons. The fact that a group isn't served doesn't always mean it should be.

If I did it again, I would make sure I had an airtight explanation for WHY a perceived whitespace exists. We thought we had this of course, but we learned that our WHY focused on symptoms of the problem rather than the root cause. For example, yes it's true that customer support, onboarding and payment flows, etc. are primarily made for English speakers. But is that WHY these non-English-speaking business owners did not adopt a product? Or did the makers of that product decide (explicitly or implicitly) that these businesses were not viable to support at scale?

Lesson 2: If your plan is to do something manual first and automate later, you better be sure you can automate!

I strongly subscribe to lean startup thinking: test hypotheses quickly, do things manually if needed, and automate later. In theory, it doesn't matter if something that looks like "software" on the front end is manual on the back end as long as you're learning.

In practice, this broke down for our customer base.

We served non-English-speaking SMB owners operating extremely low-margin businesses. Every dollar is important, and they are completely swamped by their day-to-day operations. As such, their record keeping, price lists, policies, online profiles, internal processes etc. are woefully disorganized and/or out of date.

The result was everything took more effort than expected: onboarding required phone calls, simple documentation such as pricelists or loyalty program policies was difficult to collect and often incoherent, payments were surprisingly complex (many customers preferred cash payments due to trust and familiarity concerns), and customers wanted immediate access to a support rep after even one slow day of business.

That's okay, we thought. We'll automate all these challenges later. But as we attempted to do this, we ran into customer behavior constraints. Furthermore, we were using platforms such as WeChat to manage our customers, and WeChat (given the Chinese/American software-firewall dynamic) severely limits what an American company can build on top of it.

If a user base cannot realistically become low-touch, you cannot build a scalable SaaS business for them at modest price points. It seems obvious. If I did it again, I would think about automation constraints much earlier and more aggressively. If something fundamentally cannot be automated, I would either redesign it or not build it at all.

Lesson 3: Charge for your product/service ASAP and push prices higher than you think you can.

Giving something away for free proves almost nothing.

We were actually reasonably disciplined here: we only offered our MVP for free briefly, then began charging ($39/month), raised prices multiple times, and eventually landed at $199/month while still acquiring customers. But even so, we unnecessarily delayed revenue and learning by being overly cautious.

We were afraid customers would say no, or that they'd be unhappy at higher price points. What we learned instead is that pricing is one of the fastest ways to understand how much value you're really providing, and who your real customers are. By far our most time-consuming customers were early users for whom we kept prices artificially low.

Lesson 4: Be critical of your growth channels; do not conflate "growth hacks" with durable channels.

Once we had something resembling product-market fit, we set aggressive early growth goals to reach profitability and unlock hiring and product investment. That pressure forced us to experiment widely with customer acquisition.

Some experiments worked, at least temporarily. In-person sales led to WeChat connections, which led to referrals and affiliate-style distribution via WeChat and later Rednote. For a period of time, this drove meaningful growth.

But in hindsight, many of these were fragile channels, not durable ones. The addressable audience was smaller than we appreciated, and as we scaled the number of affiliates, they began to cannibalize each other. Some early success was driven by unusually strong individual performers whose results were difficult to replicate at scale. When those individuals left, growth became meaningfully harder.

The lesson wasn't that experimentation was wrong. It was that it is every bit as important to understand how you are going to scale an acquisition channel as it is to validate that it works.

Lesson 5: DO NOT lose sight of product experimentation.

It's extraordinarily difficult to maintain a relentless focus on product innovation when your product team is consumed by keeping the current system running: fixing bugs, handling bespoke requests, pulling reports, supporting onboarding, and unblocking customers.

But if you don't make space for continuous discovery — structured feedback loops, proactive experimentation, etc. — you're losing ground to competitors and eliminating any chance at breakout success.

In hindsight, I would have invested earlier in people and processes whose sole responsibility was learning: testing new ideas, validating assumptions, and pushing the product forward independent of day-to-day firefighting.

Lesson 6: Define explicit personal redlines, financially and otherwise.

The business became profitable early, but under a very specific set of conditions, one of which is that founders were significantly underpaid.

That's not inherently wrong. It's part of what many founders sign up for. But I wasn't explicit or quantitative enough with myself about how long that tradeoff was sustainable, or what conditions would force a re-evaluation.

This connects to a broader lesson about redlines.

Some startup decisions are easy: when a company runs out of cash, or when it becomes a clear breakout success. Most decisions live in a large, uncomfortable middle where the business is working, but perhaps not working enough to justify the personal and professional costs indefinitely.

In that middle ground, you're juggling questions like:

  • What is my realistic upside?
  • What opportunity cost am I accepting by staying?
  • Do I have Stockholm syndrome, or am I staying for the right reasons?
  • If I step away, am I a quitter? Do I lack grit?
  • If we make this one change, will the situation improve?

Without predefined thresholds, those decisions tend to drag on far longer than they should. Emotion fills the vacuum: fear of being seen as a failure, sunk cost fallacy, fixation on the possibility that one more iteration might change everything.

If I did this again, I'd define clear personal redlines upfront. Not as an exit plan, but as decision hygiene. Pre-committing to those thresholds wouldn't have made the outcome different, but it would have made the decision clearer, healthier, and far less draining.

Conclusion

Build is still alive and growing. It's a testament to the team that we could step in so many potholes and still build a profitable, growing business with hundreds of customers who depend on it. Hopefully, if you're reading this, you can learn from my mistakes. And if you'd like to talk through your own challenges and how these lessons might apply to your context, don't hesitate to contact me!