Building a data platform successfully: Why “use case first” almost always leads to value faster

You want to build a data platform and are faced with what seems like a big fundamental question: first infrastructure, then use cases. Or first use cases, then infrastructure. Many teams reflexively choose “infrastructure first” and months later wonder why the platform exists but no one is actually using it. The hard truth: A data platform is not an end in itself. It is a product that must deliver measurable benefits. And the fastest way to get there in most companies is consistently “use case first”.

Here's the gist: When you develop your platform around real use cases, you automatically build what is needed. On the other hand, if you try to define the perfect target architecture in advance, you are optimizing on assumptions. This costs time, money and trust.

Use case first as the primary principle when building a data platform

“Use case first” doesn’t mean that you start running without a plan. It means: You start with a concrete problem that has a clear business owner, promises benefits and generates data requirements. You derive platform capabilities from these requirements.

Why is this so effective?

• You get immediate priorities. A use case forces you to make decisions: Which data sources first? What topicality? What data quality? Which access rights?
• You reduce architecture debates. Many discussions resolve themselves when the use case makes it clear what is really necessary.
• You build trust. A platform gains acceptance when it visibly helps within a few weeks.

Important: Use case first does not mean “quick and dirty”. It means “minimal but resilient”. You build from the start so that you can expand, but you only invest in complexity when it is justified by real-world needs.

This is how you choose the right start use cases

Not every use case is suitable as a platform starting signal. Good candidates typically have:

1. Clear decision or process improvement as a goal (e.g. forecast, anomaly detection, reporting automation).
2. Tangible data needs, but no exotic special curls.
3. An owner who invests time, gives feedback and approves results.
4. A measurable value, ideally in euros, time or risk.

Here’s the point: your first use case is not so much “the most important” but rather “the best lever” for sensibly enforcing platform fundamentals.

Which decisions lead you to a data platform in the first place

Many companies start with individual BI reports, Excel exports or one-off ETL jobs. This works until it doesn't work anymore. A data platform becomes necessary when recurring patterns occur that you can no longer manage properly with individual solutions.

Typical triggers:

• Multiple teams need the same data but in different forms.
• Data quality becomes an issue because definitions vary (e.g. “active customer” depending on department).
• Time-to-Insight is too slow because data acquisition and preparation starts again every time.
• Compliance and access control must be traceable.
• Scaling: more sources, more volume, more users, more use cases.

Why is this important? Because these triggers directly determine which platforming skills you need first. If your main problem is governance, your start will look different than if your main problem is performance or data integration.

The crucial question before selecting a tool

Before you think about products, it's better to clarify three things:

• Which data products should be created in the next 3 to 6 months (named specifically)?
• Which user groups are they consuming (analysts, departments, data science, external partners)?
• What operational requirements are non-negotiable (e.g. data residency, role models, auditability)?

If you don't answer that, every tool discussion becomes a question of faith. With answers it becomes a purchasing decision.

Infrastructure first: When it makes sense and when it slows you down

There are situations where “infrastructure first” is justified, for example:

• You must establish mandatory security and compliance standards before anyone is allowed to work productively.
• You're migrating from a legacy landscape and need a stable target environment to even start.
• You already have several use cases in the pipeline and need a common basis so that teams don't create sprawl in parallel.

But: In many medium-sized businesses and product organizations, infrastructure first is sold as “we do it right”, but in practice it means “we don’t deliver anything visible for a long time”. This is dangerous because data platforms need trust. Without early successes, the platform will quickly be perceived as a cost block.

A pragmatic middle ground: platform skeleton plus use case rhythm

If you don't want to go to extremes, this approach often works:

• Minimal Platform Core (Identity, Access, Basic Logging, Standard Storage, CI/CD Foundation).
• A use case as a clock that enforces the next capabilities (e.g. ingestion, transformation, data model, serving).
• Each expansion is based on a real need.

This creates a platform that is both secure and useful, without requiring months of upfront investment.

Managed solutions like Databricks: When they give you speed and when you have to be careful

Managed platforms (e.g. Databricks in the cloud) promise: faster start, less operating effort, modern components from a single source. This can be a real advantage, especially if your team is not primarily responsible for running a platform, but rather for delivering data products.

What managed solutions are often particularly good for:

• Fast go-live for analytics, engineering and machine learning.
• Scaling without your own cluster tuning.
• Standardized environments that get teams up and running faster.
• Built-in governance and catalog features (depending on setup) that make it easier to get started with data products.

But there are two typical stumbling blocks:

1. Cost Control: If you don't establish a FinOps mindset early on (budgets, alerts, cost centers, usage policies), the convenience will eat you up.
2. Lock-in and architecture discipline: Managed does not automatically mean “good architecture”. You still need clear data product standards, ownership and interfaces.

Here is the key question: Does the managed solution give you measurably more delivery speed than a self-operated setup, for your specific use cases? If so, that is often the better decision. If not, you are buying complexity that you don't need.

Think of the data platform as a product: ownership, standards, data products

A data platform rarely fails because of technology. It fails because of a lack of clarity: Who decides what is “right”? Who operates? Who prioritizes? Who is responsible for data quality?

If you run your platform as a product, you need at least:

• Product responsibility for the platform (prioritization, roadmap, stakeholder management).
• Clear standards for data models, naming, versioning, testing, documentation.
• Data product ownership in the functional or domain teams (who is responsible for definition and quality?).
• Easy onboarding for new users, including templates and happy path.

Why this matters: Platforms are quickly becoming “everybody owns a little bit.” Then it really belongs to no one. And then it becomes expensive, slow and political.

Minimum standards that you should set early on

You don't have to sort everything out at the beginning. But these standards almost always pay off:

• Definition of “Source of Truth” per core entity (customer, order, product).
• Roles and rights concept (who can see what, who can change what?).
• Quality checks for critical tables (nulls, duplicates, value ranges).
• Versioning and deployment process (also for data pipelines).
• Documentation as part of Done (short but mandatory).

The goal: less friction, fewer discussions, fewer surprises.

The practical setup plan: 6 steps to a viable data platform

If you had to start tomorrow, this process is a robust plan that works in many organizations:

1) Start with a use case that creates pressure for results

Choose a use case that delivers visible benefits within 4 to 8 weeks. No “let’s build the foundation first”.

2) Define the data product

What exactly is the result? A table? A dashboard? An API? A feature in the product? Who uses it, how often, and what for?

3) Make the ingestion minimal but repeatable

It's better to have a clean standard pipeline for 1 to 2 sources than five special solutions.

4) Set up transformations with testing and ownership

Build transformations so that you can change them without fear. Tests don’t have to be perfect, but they do have to exist.

5) Establish governance where there is risk

Start with the sensitive data, the important key figures and the widely used tables. Governance paralyzes everywhere all at once.

6) Repeat the cycle with the next use case

Each new use case specifically expands the platform. You build capabilities because they are needed, not because they look good on the architecture diagram.

What you should do differently from now on (specifically)

• Formulate your data platform as a value proposition: Which 2 to 3 decisions or processes will improve in 90 days?
• Set a use case as a pacemaker and only plan platform work if it makes that use case faster, safer or cheaper.
• Introduce platform ownership (one person or small team with real decision-making power).
• Set minimum standards, especially for source of truth, quality and deployment.
• Check managed options like Databricks based on one criterion: How much faster do you deliver data products without sacrificing costs and governance?

If you follow this approach, your data platform will not become a major project that is supposed to be finished at some point. It becomes a system that continually delivers value and gets better with every use case.