Every application I have worked on collected more data than it used. Orders, events, sensor readings, logs, the result of every decision the software already made. Most of it gets written once and read never.
The gap between what a business collects and what it understands is where a lot of its value sits unused. What decides whether that gap closes is not ambition. It is tooling.
For the better part of a decade, the tools that closed it were Python tools: notebooks, DataFrames, a deep ecosystem of connectors and plotting libraries. That is not a complaint about Python. It is an observation about where the work went, and why it went there.
The detour I kept taking
I have spent years building data products for other people on .NET, and the same thing happened on every project.
The application that produced the data was written in C#. It was fast, typed, tested, and already running in the place where the data was born.
Then somebody needed to understand that data, and the work left the application. A Python script in a sidecar container. A spreadsheet exported out of a report. A warehouse owned by another team with its own backlog.
Every hop out cost something. Types turned into strings. Business rules got written a second time, slightly differently, in each place. And every hop was one more reason not to look at the data at all.
LINQ is wonderful, and it is where most of us stop. It handles a filter and a sort. It does not give you a moving average, a pivot, a join across two files of different shapes, a grouped percentile, or a pipeline of twelve steps that somebody else can read next month. So the analytical work went elsewhere, and .NET stayed the language of the application without ever becoming the language of the data inside it.
I think that is a tooling problem, not a platform problem. Tooling problems get fixed when somebody sits down and fixes them.
What the company is for
Datafication exists to build the data tools .NET never shipped. We are starting at the bottom, with the layer everything else needs: an analytical engine that feels like .NET instead of a port of something from somewhere else.
In practice that means a column-oriented table type with the operations analysts actually use, so filtering, sorting, grouping, joining, computed columns, and window functions, behind a fluent API that reads top to bottom and compiles. It means connectors for the formats data already lives in, so loading a CSV, a Parquet file, or a query result is one line. And it means having an answer ready for the day the data stops fitting in memory, one that does not begin with rewriting your pipeline.
The engine comes first because nothing else stands up without it. Once there is a good place to hold and shape data in .NET, two more problems get easier: a fast loop for exploring that data without leaving the platform, and a way to check what the application finally puts in front of a person. I intend to build toward both. For now, the engine.
How I want to work
Datafication is small, founder-led, and based in Pennsylvania, and I would like to keep it small enough that the person who writes the code is the person who answers the email. A few rules follow from that.
Native to the platform. A tool built for .NET should install with dotnet add package, run inside your process, debug with your debugger, and deploy with your application. No sidecar runtimes, no bundled binaries borrowed from another ecosystem.
Honest about what is open. Some of what we build will be commercial, and it will say so up front. Some will be open source, and when it is, the license will not change under you later.
Built for my own use. Everything we ship will be something I needed first. That is the quickest way to find out what is wrong with it.
Documented as it is built. The guide ships with the feature, not a release behind it.
What to expect from here
Not much noise. A working engine before a marketing site, packages before promises, and release notes that explain the reasoning and not only the change. When there is something to try, it will be on NuGet, and this blog will say what it does and what it does not do yet.
If you have been leaving .NET to look at your own data, I would like to hear what that detour costs you. Write to support@datafication.co. It reaches me.