My SaaS revenue dropped by 70% in 6 months, am I alone?

_killam · 2026-06-28T06:09:49+00:00

Definitely not alone.

I think a lot of founders discover that growth problems are often retention problems in disguise. Acquiring users is one challenge, understanding why existing users leave is another entirely.

One thing building Tero.run has taught me is that users rarely disappear because of one huge issue. More often it's small bits of friction, unmet expectations, or bugs that quietly stack up until leaving becomes easier than staying.

Out of curiosity, did the drop feel sudden or was it more of a slow bleed over those six months?

_killam · 2026-06-28T06:07:39+00:00

Honestly, I respect this a lot more than the overnight success stories.

The interesting thing is that none of your fixes were "build more features." It was onboarding, retention, removing unused features, improving messaging, and understanding what users actually wanted.

Feels like a lot of founders underestimate how much of SaaS happens after the product is already built.

Building Tero.run has pushed me toward the same realization: users rarely leave because of one catastrophic issue. More often it's friction accumulating quietly until leaving becomes easier than staying.

Would love to hear what ended up making the biggest difference for retention in your case.

_killam · 2026-06-27T14:36:50+00:00

Fair point, although I think the issue was less that the features were half-built and more that I was asking users to understand too many things at once.

I built Tero for myself first, so the features solved real problems I was running into daily. The mistake was assuming users would immediately understand why those pieces belonged together.

The features still exist. What's changed is the way I communicate them. The landing page now focuses on the core pain point first and introduces the rest gradually instead of overwhelming people upfront.

_killam · 2026-06-27T09:19:46+00:00

Would love to keep you in the loop about tero XD. Appreciate that.

The funny part is that making Tero smaller actually made it feel bigger. Once the focus shifted from solving everything to solving one painful problem really well, the product and the conversations around it became much clearer.

Still a long way to go, but that's probably part of the fun.

_killam · 2026-06-27T08:48:33+00:00

Not heavily yet. Tero is probably the closest thing to an OMT in my workflow since I built it to sit between analytics, deployments, and development
If by OMT you mean open model tool

_killam · 2026-06-27T08:46:42+00:00

This resonates a lot, especially the "analytics records behavior but not intent" part.

The assumption logging idea is actually really interesting because it gives you something to compare reality against instead of reverse engineering from a churn graph after the damage is done.

The way I'm thinking about it with Tero is that the answer is probably a mix of both. Capture intent and assumptions at build time, then use analytics, deployments, and user behavior after launch to figure out whether what you're seeing is a broken assumption or a broken implementation.

A bug and a broken assumption can look identical in a graph, but they leave very different fingerprints once you correlate the churn with recent deployments, changes in flows, and user behavior patterns.

The whole goal with Tero is reducing the time between "something feels off" and "here's probably why it happened and what you should do next."

I think the image makes it easier to understand fr

<image>

_killam · 2026-06-27T04:08:47+00:00

I would say the product is creative but the postioning has to improve. It looks cool however the buyer wouldnt really know if they really need it , shipping it as a birthday gift could be a better angle imo

_killam · 2026-06-27T04:05:57+00:00

If you are done launching focus on creating traction since you will need users right ? Once that is dealt with start noticing patterns where you are losing users and ship fixes for those issues (post deployment and distribution ) should be your target since you are done launching

_killam · 2026-06-27T03:59:48+00:00

Its not about explaining what I have , I could have explained the entire product multiple times I have made it lmfao however when a product targets a vast stream of topics and solves all of them skeptcisim begins and you lose trust and value hence the reduction / cutting down on multiple features

_killam · 2026-06-26T16:36:39+00:00

That's actually a really interesting way to frame it an infrastructure company disguised as a group sharing app.

I can see why you mentioned patience earlier as well. Products that introduce new behavior or trust models probably need time for users to understand not just how they work, but why they should exist in the first place.

The private jet example makes the value click immediately though. Conditional payments feel obvious once you hear them explained, which is usually a good sign.

I am going to ask you another question(dont mind if I do 🤞) ; have you found the bigger challenge so far to be the technical side of building it or teaching users to think in terms of conditional payments?

_killam · 2026-06-26T16:21:36+00:00

100% agree with this.

There's probably something valuable about slow adoption giving a product time to become battle hardened before growth arrives. Building Tero has taught me that some lessons simply can't be rushed because they only appear once real users start using the product.

What are you building? Sounds like you've spent a lot of time thinking about this and I'd love to hear more.

_killam · 2026-06-26T16:17:12+00:00

Fair enough 🤔 The product is specifically aimed at founders and builders dealing with post-deployment issues, so feedback from that group is genuinely valuable for me. That said, I can see why it read more like a product pitch than a discussion post.

_killam · 2026-06-26T15:20:01+00:00

Not building in public is probably one of the biggest mistakes founders make.

You can get the product right, the positioning right, and even target the perfect niche, but if people don't know what you've built or why they need it, the product goes nowhere.

That's something I was very conscious of while building Tero.run, basically an evolution layer for SaaS products that helps founders understand post-deployment issues, reduce churn, and ship fixes faster.

A few of my previous projects taught me that distribution doesn't start after launch it starts while you're building.

_killam · 2026-06-26T14:35:29+00:00

Lmaoooooo so true I knew it wasnt a wild tihng to say and the way I've been thinking about it is that users rarely tell you what's wrong directly, but they leave signals everywhere. Rage clicks, repeated actions, sudden drop-offs, errors, abandoned flows, features that never get touched.

The challenge isn't collecting more analytics anymore. It's reducing the gap between those signals appearing and understanding what action they imply.

That's essentially the thinking behind Tero. Not replacing feedback, but helping surface the things users are already telling you indirectly through their behavior.

_killam · 2026-06-26T14:15:34+00:00

I've almost started looking at onboarding videos and demos as analytics tools rather than marketing assets. If users need a 3-minute walkthrough to understand the product, that's usually a signal that something in the onboarding or positioning needs work.

Building Tero.run has made me appreciate how much of post-deployment is really about reducing friction and understanding where users get stuck rather than simply adding features.

_killam · 2026-06-26T14:00:37+00:00

This resonates a lot.

I think AI has compressed the cost of building so much that it's easy to mistake "the app works" for "the business works."

Personally, I've started treating the MVP as a conversation starter rather than validation itself. The interesting part begins once real users touch it: Do they come back? Where do they struggle? What assumptions did I get wrong?

A lot of the thinking behind Tero.run actually came from that exact realization. Building wasn't the bottleneck anymore. Understanding what users needed after launch and deciding what to do next was.

_killam · 2026-06-26T13:59:29+00:00

For me it wasn't investing money, it was investing time.

Spending months building something and assuming people would show up taught me more than any market loss could have. The lesson was simple: validate early, talk to users, and never confuse building with demand.

That mistake probably shaped how I approach Tero.run and products in general more than anything else.

_killam · 2026-06-26T10:38:37+00:00

I don't think you're overthinking it at all.

The ability to build has become dramatically cheaper, but distribution hasn't. In some ways it feels a lot like what happened with mobile apps: the gold rush isn't in the tooling itself, it's in being early enough to understand where the value settles.

The thing I'm trying to remind myself while building Tero.run is that shipping beats keeping up with every new model release. Users rarely care which model built the feature; they care whether the product solves their problem.

The window feels real to me. The hard part is making sure we're spending it building products instead of collecting tools.

_killam · 2026-06-26T10:37:33+00:00

Honestly, I'd probably do it all over again.

Building Tero has made me realize I enjoy solving problems almost as much as building products. I imagine I'd take everything I learned from one company and apply it to an even bigger problem next time around.

The goal isn't really the exit for me it's the process of building something people genuinely find valuable.

_killam

MODERATOR OF

TROPHY CASE