DevTool Case Study

Problem

The assignment: find 10 companies that could use the product, explain why they fit, and design a landing page.
The promise was clear on paper: unify ingestion, orchestration, transformation, and quality. Whether customers cared was unknown.
The riskiest assumption: that a unified data platform would matter as a category-level promise.
So before any design, I talked to people doing the actual data work.

What I did

Structured the interviews around current workflows, breakpoints, tools, and workarounds.
Ran 5 interviews with data engineers, data scientists, analysts, and product/data team leads.
Checked the patterns against 5 more companies, using LinkedIn, websites, product pages, and public positioning.
Turned customer language into positioning, messaging, and landing page UX decisions.

Devtool research process from customer interviews to positioning and landing page decisions — From interviews to pain clusters, ICP segments, and positioning decisions.

What the interviews showed

One data engineer described their stack as custom ingestion plus Airflow plus dbt: three tools, three maintenance burdens, three points of failure.

Three pains kept repeating:

Fragmented infrastructure. Ingestion, orchestration, transformation, and quality stitched together across separate tools.
Reactive data quality. Bad inputs found only after they reached dashboards, customers, or production analysis.
Custom code overhead. Bespoke ETL and transformation logic for each client, schema, or workflow.

Four segments, four stories

The same product was relevant to each segment, but not through the same story.

Mobile Gaming. Lean teams need production-grade analytics without hiring more data engineers.
FinTech and RegTech. Reliability, governance, lineage, and blocking quality controls matter more than speed.
AI and SaaS. Custom ETL, mixed SQL/Python workflows, and schema changes create repeated bottlenecks.
E-Commerce and Logistics. Fragmented tools, manual exports, and inventory sync delays drive urgency.

Six page decisions

Lead with the outcome.

Reliable data, faster deployment, less operational complexity. Not product mechanics.

Devtool landing page hero section focused on reliable data and reduced complexity — The hero leads with customer outcomes.

Use specific numbers.

Cost reduction, faster insights, less tool sprawl. Not vague speed and reliability copy.

Devtool landing page quantified claims section with cost reduction and faster insights — Specific numbers are easier to evaluate than generic benefits.

One tab per segment.

FinTech sees compliance, Gaming sees analyst enablement, AI/SaaS sees mixed workloads, E-Commerce sees reliability and cost.

Devtool landing page sector-specific personalization tabs for different customer segments — Same product, different proof and language per segment.

Simple first, depth on request.

A simple top-level story, with technical detail for buyers who want it.

Devtool landing page progressive disclosure section showing simple steps with deeper technical detail — Simple at first glance, deep for technical buyers.

Name the broken workflow first.

Describe the current pain before introducing the product as the fix.

Devtool landing page pain point empathy section describing fragmented tools and maintenance burden — The page mirrors the broken workflow before the solution.

Put proof where the doubt is.

Trust signals answer specific buyer concerns: compliance, quality, operational reliability.

Devtool landing page footer trust signals for compliance, quality controls, and reliability — Proof points answer the concerns the research surfaced.

Where it stands

This was an assignment, not a live client engagement or a shipped product. The interviews, synthesis, and positioning work are real. There is no launch, adoption, or usage claim.

Email me →What I am open to →

All work →