9 years, 6 companies: what makes a data or AI project actually ship

Not long ago I looked back at nine years of data and AI work. Six companies, a lot of projects.

What surprised me: the projects that shipped were rarely the ones with the best technology.

They were the ones with a clear goal, one person who could decide, and a first version small enough to finish.

Nine years, six companies

I started in 2017 at 10Pearls, building Python and Java APIs. I also helped start the company's first data science team.

At Alten I worked as a consultant on data warehouse and ETL projects for automotive clients, including AUDI and MAN. At TrueOcean I worked on service communication with gRPC and task orchestration with Cadence.

At BIT Capital, a fintech, I owned data end to end and built the internal data warehouse with Airflow, Snowflake, S3 and PostgreSQL. At Hella Gutmann I led the BI and data warehouse team, moved pipelines to Databricks and AWS, and built a data mesh across six teams.

Since 2024 I have worked with a VC firm on AI infrastructure, RAG and an internal agent platform. At the end of 2025 I went fully independent.

Different industries, different stacks. But the things that decided whether a project shipped barely changed.

Three levels of lessons

The O'Reilly piece What We Learned from a Year of Building with LLMs sorts its lessons into three levels: tactical, operational and strategic. I like that shape, so I borrow it here.

Strategic is what you build and why. Operational is how the work runs, week by week. Tactical is the code, data and tools themselves.

I go from the top down. In my experience, most projects are won or lost at the strategic level, long before anyone writes code.

Strategic: know where you are going

Pick the right problem. Good projects start from a problem that hurts often and costs real time or money. "We should do something with AI" is not a problem.

A typical good problem sounds more like this: "Our analysts rebuild the same report by hand every Monday." It is small, concrete and someone feels it every week.

Agree what success means, and how you measure it. Do this before any code. A number, a date, and a person who will say "yes, this is done."

For an AI feature, that might be: what share of answers must be correct, and how do we check it? If you cannot measure success, you cannot finish.

Say no to the demo-driven project. With an LLM, a good demo takes an afternoon. A demo shows the best case. Production is about all the other cases.

I have seen teams fall in love with a demo and then spend months trying to make it reliable. The demo set the expectations, and nobody had agreed on the goal.

If nobody can say what "done" looks like, the project will never be done.

Operational: how the work runs

One owner who decides. Not a committee. One person who can say "we do this, not that" and make it stick. Many people can give input. One person decides.

A small first release. Ship something real in weeks, not months. One pipeline, one report, one agent with two tools. Small releases give you feedback while changes are still cheap.

Tests and evals from week one. An eval is a fixed set of test cases with expected results, scored automatically. For data, the same idea means quality checks on every load. If you add them later, you never really add them.

Real users every week. Put the work in front of the people who will use it. Their reactions are worth more than any status meeting.

Monitoring in production. Once it is live, you need to see failures before your users report them. Log every run, alert on broken loads, and watch cost.

Documentation and handover. A project is not shipped if only one person understands it. Plan the handover from the start, not in the last week.

Here is what I got wrong, more than once. Earlier in my career I sometimes built the clever, complete version first and showed it late. It was good engineering. It was also weeks without feedback, and some of it was not what people needed.

Tactical: build things that hold up

Code like it will live for years. Version control, reviews and CI for everything, including SQL, dbt models and prompts. A prompt that changes behaviour is code.

Data contracts. A data contract is an agreement between the team that produces data and the teams that use it: the schema, what each field means, and what counts as a breaking change. Without one, every upstream change becomes a surprise downstream.

Tests that run without you. Quality checks that fail loudly on bad data. Unit tests for transformations. For agents, tools with typed inputs and outputs that you can test without the model at all.

Tools and prompts that hold up. Keep prompts short and curated. Give every tool a clear contract and a clear error. Every change should beat your fixed eval set before it ships.

Boring technology. PostgreSQL, Airflow, dbt, Snowflake or Databricks. Pick what your team can run and debug on a bad day. A new tool should earn its place by solving a problem the boring one cannot.

Shipped vs stalled

In more than one team, I have seen both columns. The stalled projects did not fail because of weak engineers. Often the engineers were excellent.

They stalled because decisions went to a committee, everything waited for one big launch date, success was never defined, or the work was built to impress in a demo.

Look closely and each stalled pattern is the mirror of a shipped one. That is good news. None of these fixes needs a new tool. They need a few clear agreements at the start.

What this means when we work together

These lessons shape how I work with clients today.

Before I build anything, I ask three questions. What problem are we solving? How do we measure success? Who decides? If the answers are missing, finding them is the first piece of work.

Then you get a clear plan with scope, timeline and cost. I deliver in small, visible steps you can see and test early. And I finish with documentation and a handover, so your team owns the result and does not depend on me.