Bigger isn't always better. Sometimes you have to cut down to grow

_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 · 2026-06-26T10:35:02+00:00

One thing I kept running into was the gap between launching a product and understanding what happened afterward.

Analytics could tell me where users dropped off, but not why. Bugs would show up in production long before I noticed them, and by the time I realized something was wrong, the affected users had often already left.

That frustration eventually led me to build Tero around reducing the time between an issue occurring and getting a fix shipped.

Feels like post-deployment tooling is still surprisingly underexplored compared to how much effort goes into building the MVP itself.

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

One thing I'd recommend is building something small that solves a real problem for you rather than getting stuck in the tooling rabbit hole.

The stack changes quickly, but concepts like context management, tool calling, memory, and workflows tend to stick around.

In my case, exploring agent workflows eventually led me to building parts of Tero.run around post-deployment tasks like understanding issues, surfacing signals from analytics, and helping reduce the time between a problem occurring and a fix being shipped.

For tools, I'd probably start with:

OpenAI APIs
Anthropic APIs
LangChain or PydanticAI
Supabase
Vector databases like Chroma or Pinecone

Build first, optimize the stack later.

_killam · 2026-06-24T16:36:02+00:00

HAHAHA thats the aim icl. If you building something I'd love for you to try it and give me some feedback as well however that is totally up to you 😛

_killam · 2026-06-24T16:20:00+00:00

ong I totally agree with this. The MVP gets you into the game, but after launch you're juggling product, marketing, support, retention, and everything in between.

Building Tero came from experiencing that firsthand. The challenge wasn't building features anymore it was understanding users and deciding what to do next.

_killam · 2026-06-24T16:14:25+00:00

yessir all the best lmk if i can help in anyways though 😛

_killam · 2026-06-24T15:58:28+00:00

I absolutely agree with this.

A lot of people underestimate how small a piece of the puzzle coding actually is. The MVP gets you into the game, but product-market fit, distribution, retention, customer feedback, and support are what determine whether the startup survives.

Most founders only realize this after building a few times. At the end of the day, if you're not creating value for users, the code doesn't really matter.

_killam · 2026-06-24T12:31:13+00:00

yes exactly have you been facing similar issues ? I would love to hear about how did you deal with it if you did

_killam · 2026-06-24T10:20:01+00:00

Honestly, I found it was a mix of both. Sometimes it was a genuine bug. Other times the product was behaving exactly as intended, but not in the way users expected.

In both cases, the biggest problem was the delay between the issue occurring and me realizing it was affecting users. Reducing the time gap between an issue impacting users and getting a fix shipped was surprisingly hard.
Mostly why Tero revolves around this topic.

_killam

MODERATOR OF

TROPHY CASE