Atrie

The problem

I was targeting organizations that did not yet have a data team. Their data lived across CRM, product, finance and other SaaS tools, but building and maintaining a data warehouse required data engineering they did not have the capacity to take on. Atrie was meant to let them start with a warehouse simply by connecting their SaaS tools, while Atrie handled ingestion, transformation and ongoing pipeline maintenance. Bringing that data together was only the first step: someone still had to define what counted as a customer, how revenue was calculated, and how records related. Without that foundation, dashboards disagree and AI agents have to reconstruct the business every time someone asks a question. I wanted to make that underlying model persistent, so people and agents could work from the same definitions.

The approach

Atrie would own the pipeline from source systems to answers. It would ingest a company's data into its own warehouse on a schedule, maintain shared definitions of entities and metrics, and let agents query that model. Metrics would be defined once and versioned, and answers would cite the queries behind them so users could inspect how a conclusion was reached. Reporting, explanations and eventually automated workflows would all use the same foundation.

How it worked

The architecture had three layers: ingestion into a managed warehouse; a semantic layer defining the company's entities, relationships and metrics; and applications that used that model for reporting, analysis and agent workflows. I built a working pre-MVP covering part of that architecture. It brought Attio CRM and Amplitude product data into PostgreSQL through an ingestion, validation and computation pipeline, calculated business metrics, and exposed them through reporting and AI-assisted explanations. The interface demonstrated what users could do with the data; the larger product was the infrastructure underneath it.

Key decisions

• Start with European Seed and Series A B2B SaaS companies, where fragmented systems were already creating operational problems but dedicated data teams were uncommon.
• Make the warehouse and shared business definitions the foundation, so every dashboard, answer and agent workflow could use the same model.
• Start with reporting and explanations about individual customers and deals, then add agents and earlier warnings as the product developed.
• Test both direct sales to founders and partnerships with venture capital funds.
• Stop before fundraising after deciding not to continue as a solo founder and concluding that the available evidence did not justify the technical and organizational demands of the product.

Outcome

I stopped work before fundraising in November 2025, after more than 50 discovery conversations, a working pre-MVP, discussions with a potential design partner, and a signed letter of intent from another prospective customer. I had demonstrated part of the product, but had not established repeatable use or paying demand.

What I learned

Seed-stage startups were too early: the underlying data problem becomes more acute from Series B onwards, when companies begin building data warehouses. I focused on non-technical operators who would consume the output, when the more important buyer was likely the CTO or technical leader making the company's data decisions. I am also less convinced that an opinionated semantic layer was the right product choice, or that solving this problem alone supported the scale of company I wanted to build.

I was also the wrong CEO for this particular idea. A product built around data infrastructure required a technical CEO who could own its architecture and judge the engineering decisions. Without that capability myself or a committed technical co-founder acting as CTO, there was a fundamental gap. Hiring a founding engineer (which was explored) would have added execution capacity, but would not have filled that gap in founder-level technical ownership.