A freelance data engineer, who writes the code, the guides on this site, and the reply to your email. Everything here comes out of building data platforms for clients.
One person: a freelance data engineer, founder, and the only one working on the product.
Freelance data engineer. Client data platforms on Azure and Databricks, infrastructure in Terraform.
The same person. Every guide on this site is written from that delivery work, not from a survey of other articles.
The product
Datadef draws architecture diagrams for data and cloud systems. You describe a system in plain English and get a diagram you can then edit on a real canvas: typed nodes, tables with their columns, zones, labeled edges, column-level lineage, and provider icons that are the actual AWS, Azure and GCP marks rather than lookalikes.
The other way in is a repository. Connect a GitHub, GitLab or Azure DevOps repo, read-only, on the branch or tag you choose, and Datadef reads the files that define the system to produce a diagram and an architecture.md that regenerate daily. Terraform repositories go through a parser that reads the .tf files directly, with no terraform init, no state file and no cloud credentials handed over.
It is not a whiteboard and it is not a general drawing tool. The vocabulary is data-shaped on purpose, and the parts that matter to a working team are the boring ones: a commit with no structural change does not redraw the diagram, a node you moved by hand keeps its position across syncs, and one markdown line embeds the current diagram in a README or a Confluence page for readers who have no account.
The person
The person behind Datadef
Freelance data engineer. Founder, and the only one working on the product.
[email protected]The client work is designing and building data platforms: ingestion, storage, transformation, and the infrastructure underneath, mostly on Azure and Databricks, with Terraform describing what actually gets deployed. Datadef came out of that work and has one person on it.
That is where the opinions on this site come from. The guides here are not a survey of what other articles say about data architecture. They are written from the same decisions a delivery forces: which layer owns a transformation, what a lineage claim is worth when it is derived rather than observed, why a diagram of every resource in a Terraform repository is unreadable and what to roll up instead. When a page here says an approach costs more than it looks, it is because it did.
It also sets the limits of what he writes about. Azure, Databricks and Terraform are first-hand. Areas he has not shipped are written from the primary documentation and say so, and a number attributed to someone else on this site carries a link to the source or gets deleted.
Origin
Every platform handover needs an architecture diagram. Every one of those diagrams is wrong a few weeks later, because redrawing it is work nobody schedules and no client pays for. Datadef started as an attempt to stop doing that by hand, first as a way to get a first draft out of a description, then as a way to keep the drawing attached to the code that defines the system.
The repository side was built and tested on his own client repositories rather than on a demo repo, which is why it behaves the way it does. The platform that shaped most of the rules is a real one: 123 Terraform resources across 5 stacks, 11 modules and 3 environments. A node per resource is a wall of boxes nobody reads. Getting that down to 36 nodes in 12 module zones, with repeated resources rolled up and their per environment counts kept, is what taught the parser what to keep and what to summarize.
The same loop applies to the writing. The product facts stated across this site are checked against what has shipped, not against a roadmap, which is why you will find sentences here naming what Datadef does not do.
One person
Being a one-person company cuts both ways, and you can see both sides before you sign up rather than after.
Product questions, a bug, a feature that would decide it for your team, or a page on this site that is wrong: [email protected] goes straight to him. Corrections are welcome and the review date on a corrected page moves with the fix.
General enquiries also reach the shared inbox at [email protected].