Lone Star Media
We needed session replay. The invoice disagreed.
When you run products of your own — and when you support clients who ask "what did the user actually do?" — session replay stops being a nice-to-have. We looked at the usual vendors, including FullStory, and did the boring spreadsheet: seats, session caps, retention, and what we would actually use day to day.
The math did not make us feel thrifty. It made us feel like we were about to rent a feature forever. So we built SessionFYI for ourselves first. This is the build-vs-buy story without the victory lap.
What we actually needed
Our list was shorter than a sales deck:
- Watch a session when a bug report is vague
- Keep data practices we can explain to clients
- Avoid per-seat pricing that punishes the whole studio for peeking at a recording
- Ship something our own apps could embed without a procurement subplot
We did not need every heatmap widget on the planet. We needed a trustworthy tape of what happened.
What FullStory (and friends) optimize for
Enterprise replay tools are excellent at a job we respect: large-team analytics, mature privacy controls, integrations, and support. If you are a big product org with budget and a compliance checklist that already names the vendor, paying is often the rational move.
We are a senior Austin studio that also ships its own products. Our usage pattern is spiky, investigative, and shared across a small team. Vendor pricing aimed at growth-stage product companies is a mismatch for that pattern — not a moral failing on their side.
Build-vs-buy is not "are we clever enough?" It is "will we still like this invoice when the novelty wears off?"
The risks we accepted by building
Building your own replay is not a weekend toy if you do it honestly.
- Privacy and redaction — inputs, personal data, and client content need careful defaults.
- Storage and retention — recordings get big; deletion policies have to be real.
- Performance — the recorder cannot become the bug customers feel.
- Opportunity cost — every week on SessionFYI is a week not spent on something else.
We accepted those because we wanted the learning inside the building, and because the alternative was a permanent line item for a workflow we could not turn off.
What "building in public" means here
SessionFYI is in quiet beta. We use it on our own work. We are not pretending it replaces every enterprise feature tomorrow. Sharing the decision is useful for other studios and founders facing the same spreadsheet: sometimes the product you need is narrower than the category leaders sell — and narrower is what makes a build rational.
When we still tell clients to buy
If a client's security team already standardized on a vendor, if they need battle-tested compliance paperwork yesterday, or if nobody on their team wants to own recording infrastructure, we say so. Dogfooding our own tool does not obligate every client to use it.
Agency craft includes talking people out of our toys when the fit is wrong.
The takeaway
We built SessionFYI because our usage pattern and our tolerance for rent disagreed with the market options we evaluated. We gained a tool shaped like our work, and a sharper sense of what "good enough replay" means when you are the one on-call for the recording pipeline.
If you are staring at a similar build-vs-buy sheet, write down the three jobs you need this quarter — not the feature matrix from a homepage. Decide from the jobs. The invoice will make more sense either way.