Why we didn't raise money
In 2022, when Jordan and I started DataLynxr, the data infrastructure market was in a particular moment. Databricks had just raised at a $38B valuation. Snowflake was trading at multiples that made the entire industry look like a gold rush. Every week there was a new announcement of a "lakehouse" or "data mesh" or "data fabric" startup that had raised $30M to build something that sounded like what we were building.
We talked to a few early-stage investors. The conversations were fine. The thesis made sense to them. But the pressure was immediate: how fast can you grow ARR, what's your land-and-expand motion, when do you raise your next round, what's the path to 10× revenue in 18 months?
Those are reasonable questions for a VC to ask. They're not the questions we wanted to build a company around.
We wanted to build a platform that a data engineering team at a 200-person company could rely on for five years. That requires a different calculus than a platform optimized for demo-ability and top-of-funnel growth. It requires depth over breadth: fewer integrations, done correctly. It requires honest benchmarking instead of marketing claims. It requires pricing that doesn't punish customers for scaling, and a support model where the engineers who built the thing answer questions.
None of that is incompatible with VC funding, in principle. In practice, the funding cycle creates a clock that makes depth hard. We chose not to start that clock.
What bootstrap discipline changes about product decisions
The most concrete effect is prioritization. When your revenue pays your salaries directly, there's no ambiguity about what matters: does this feature help existing customers get more value, or does it help us win new customers in a segment we're not in yet? The answer shapes almost every product decision.
Early in 2023, we spent three months improving Iceberg partition evolution support instead of building a Salesforce integration that a prospect asked about. The partition evolution work made three existing customers significantly less likely to churn. The Salesforce integration would have helped us sell to a different kind of buyer — a business intelligence user, not a data engineer. That's not our customer. We passed.
DataLynxr is not a BI tool. It is not a no-code data pipeline builder. It is not a "modern data stack" platform that tries to do everything from data ingestion to dashboard. Those products exist and some of them are excellent. DataLynxr is specifically for data engineering teams who need a unified compute layer for SQL, streaming, and ML against their existing lakehouse storage — and who want to understand what that compute layer is doing, not hide it behind a wizard.
Denver's data engineering community
We didn't start DataLynxr in San Francisco or New York, and we haven't moved there. Denver has a meaningful data engineering community — Confluent, dbt Labs, and several large enterprise data teams have significant presences here. The Rocky Mountain Data Science meetup has run monthly for years. We've hired engineers who didn't want to relocate to the Bay Area but wanted to build serious data infrastructure.
There's something clarifying about building outside the Bay Area bubble. You talk to data teams at energy companies, healthcare systems, and mid-size manufacturers — not just venture-funded SaaS startups. Their problems are less trendy and harder. A 15-year-old Oracle data warehouse migration to a lakehouse is not a TechCrunch story, but it's real, common, and DataLynxr is useful for it.
The tradeoffs we've accepted
Bootstrapped companies grow slower. We didn't sponsor conferences in 2023. Our docs are better than our marketing. We don't have an SDR team calling every SaaS company with a data team. We've grown primarily through word of mouth among data engineers — someone uses DataLynxr, it works, they tell a former colleague.
We have accepted that we won't capture every part of the market that a better-funded company might. We are not trying to replace Databricks. We are not trying to compete with Snowflake on their home ground. We are solving a specific problem — the ETL copy-job tax for teams running SQL, streaming, and ML on the same lakehouse — better than anyone else, and doing it in a way that doesn't require you to trust us with your data or lock you into our storage format.
That's enough. It's sustainable. And it makes us better at the product.
What's next
We're working on partition evolution improvements for large Hudi tables, a Nessie catalog connector, and better observability for streaming ingestion (live lag metrics, per-partition throughput dashboards). None of these are press release-worthy. All of them will make existing customers' lives meaningfully better. That's the roadmap.
If you're a data engineer at a company with 50TB+ in S3 and you're tired of maintaining ETL pipelines, talk to us. Ryan and Jordan take every intro call directly — no BDR involved.
