In 2 Months, 2 Core Tools We Relied on Died

2 hours ago 1

First, June — the analytics solution we used since the very beginning. It was acquired by Amplitude, and right after the acquisition they decided to shut down the product. Then Pry Financials, which had been acquired by Brex a few years ago. The product kept operating for a while, but now they’re shutting it down too.

These were two fundamental tools: one heavily used for product and sales decision-making, and the other for the financial side. In our case, the impact isn’t huge. We’re a small company and can adapt quickly. But it’s still annoying, because we’ll have to spend energy on something we didn’t plan for. We’d rather be moving forward on our roadmap. We were happy with those tools.

But this is exactly the kind of risk you accept when you adopt startup products.


This situation got me thinking. We’re also a startup. But most of our customers are large, public companies.

When they face the same kind of product shutdown, what we solve in a week could take them months, maybe a year, to adapt to. It’s a matter of scale and complexity — changing workflows that involve thousands of people is a slow process.

It made me reflect on our strategy for winning and supporting this caliber of customer: how do we get global brands to use our solution? The answer is that this was intentional from the very beginning.

We’ve always thought a lot about how to reduce the risk for companies that bet on us as a startup and adopt our product early. And we’ve put together a set of initiatives to bring concrete risk reduction, not just vague trust.


One of the most important steps we took was to open source our solution.

Not just making the code public, but also building a community around it. We’ve accepted community pull requests. We actively engage with questions and contributions. We dedicate real time to make sure the project keeps improving independently of us.

This means the product is not a black box that disappears if we do.


Another key element is that the solution is, in most cases, 100% self-hosted.

Because of how sensitive it is — it touches critical parts of infrastructure — we deploy it fully inside the customer’s environment. This greatly reduces the risk. There’s no immediate migration needed if something happens to us.


We also invested heavily in packaging and architecture to keep operational overhead low.

The solution is easy to install. Architecturally, it follows 12-Factor principles as closely as possible, even though it’s more complex than a REST API. It’s a networking solution that works with multiple protocols and handles packet manipulation.

Still, it runs as a standard Kubernetes container. Persistence is handled by a simple Postgres database. You can run it like any other deployment. You don’t need a specialized team to maintain it. The tool adapts to your existing environment — your logging, metrics, HA setup. If you change those systems, the product keeps working.

Most competitors ship their solution as a VM image you run internally. That can be cheaper and easier at first, but over time it becomes painful. You have to integrate that black box into your observability stack. You often end up building a mini ecosystem just to keep that one box running. We deliberately chose not to follow that model.


In the early days, we often got the question:

“What happens if your company disappears in two years? If you get acquired and shut it down?”

The answer is simple: nothing happens.

The solution is already running in your infrastructure, self-hosted, with an open codebase. In the short and medium term, the impact is basically zero. Typically it’s deployed internally, not exposed to the internet, which keeps the security surface small. You already have firewalls, CDNs, and the usual protections in place.

This is what allows a big company to adopt a startup solution with low operational risk — even in a disaster scenario.


Of course, there’s also the trust side.

We have strong investors, healthy revenue, and plenty of runway. Interestingly, as we’ve grown and signed larger customers, this “what if you disappear” question comes up less and less. In the beginning it was common, and it actually pushed us to develop this whole strategy.

Today, these measures are so obvious to us that they rarely even surface in conversations. And on top of that, our team has been on the other side — inside large enterprises, buying solutions like this. We bring that experience into the product itself.


The bottom line is that the shutdown of June and Pry was a reminder of the risks we all take when using startup products.

For us, it was a week of work. For a large enterprise, it could easily be months or a year. That’s why, from the start, we built our solution to reduce that risk:

  • Open source with real community involvement.
  • Self-hosted by default.
  • An architecture that fits into existing environments.

If we disappear, nothing breaks.

Read Entire Article