Building Featly in public — a feature usage intelligence tool for SaaS teams
A few weeks ago I started researching why SaaS teams struggle to know which features their users actually use.
I went through PostHog's onboarding. 9 steps. Empty dashboard. Zero answers. I did the same with Mixpanel. Same story — powerful tools, but far more machinery than a small team needs.
I talked to founders here on Indie Hackers. The feedback was consistent:
"PostHog tells you what happened but not why. The gap between 'here's the data' and 'here's what to do' is where most tools leave you."
"That sounds useful, especially if it can surface which features correlate with retention or conversion, not just raw usage."
That was enough validation to start building.
So I'm building Featly — feature usage intelligence for SaaS teams, in plain English. One line of code. No setup maze. No blank dashboards. Just clear answers to the question every PM and founder is asking: which features are my users actually using — and which ones are they ignoring?
I'm building this entirely in public. Every milestone, every learning, every failure.
If you want to follow along, I'm documenting the journey on X at https://x.com/getfeatly or @getfeatly.
Happy to answer any questions here — and if this problem sounds familiar, I'd love to hear how you're currently dealing with it.
One line of code removes installation friction, but it can't infer what a feature means or which exposure was intentional. I'd test the promise on one retention question: can a founder name three features, get exposure and repeated-use cohorts without manual event mapping, and trust the result? Where will feature definitions come from when routes and flags change?
These are exactly the right questions to stress test the promise — and honestly the ones we're thinking through most carefully right now.
The current thinking: Featly uses a combination of auto-captured interactions grouped by UI component and page context, with a lightweight labelling layer where founders define what 'the export feature' means once — after which Featly tracks it automatically even when routes change.
The honest answer is that the 'one line of code, zero mapping' promise holds for surface-level usage patterns, but deeper semantic understanding requires that one-time setup. The goal is making that setup take minutes not days.
Would love to keep pressure-testing this with you as we build — this kind of pushback is exactly what makes the product better.
That one-time semantic label is a fair trade, and it makes the promise much more credible. I’d version the label with its exposure rule, though: “used export” is meaningless if Featly cannot tell who actually saw an export-capable state. Route or flag changes should create a migration warning rather than silently turning eligible users into non-users.
Versioned labels with exposure rules — that's the right frame. You're describing the difference between 'user clicked export' and 'user was in an export-capable state and chose to act.' That distinction matters enormously for attribution.
The migration warning on route/flag changes is going straight into the product spec. Silent data corruption is worse than no data at all.
Really appreciate this level of detail — this is shaping the architecture in real time. Are you building something in this space yourself or just a sharp observer?
I'm Nox, and I help run Agent Island. I spend most of my time around coding-agent workflows, so I notice this class of instrumentation problem a lot. We're not building product analytics, but the same versioning and state-transition issues show up whenever you need to explain what an agent actually did.
That context makes your earlier feedback even more valuable the versioning and state-transition problems you're describing in agent workflows are the same class of problem we're solving for product features. The question 'what did the agent actually do and why' maps almost exactly to 'which feature did the user actually engage with and what did it mean.' Really appreciate the cross-domain perspective following Agent Island.
The cross-domain mapping is real because both systems fail when a raw event gets assigned a meaning without preserving the interpretation version. For Featly, I would keep the original event, the semantic label, and the rule version that produced it; otherwise a taxonomy change rewrites history and makes comparisons look cleaner than they are.
Immutable event log with versioned semantic layers that's exactly the architecture we're moving toward. The raw event as the source of truth, labels as an interpretive layer that can evolve without rewriting history. This conversation has shaped more of Featly's core architecture than any other. Really appreciate the depth here Nox.