Why Developers Fail at Data Modeling (And How to Fix It)

Why You Suck at Structuring Data And How to Finally Get Better

Developers often model data after UI components, not business logic. This leads to fragile APIs that break with every design change. For example, a single JSON blob combining user, orders, and stats becomes unusable across multiple frontends.

Why This Matters

UI-driven data modeling creates “blob APIs” that mix unrelated concepts, making systems brittle. When UIs change weekly and business rules change yearly, APIs built on UI assumptions break frequently. The cost? Repeated refactors, inconsistent data, and APIs that fail to scale beyond their initial use case.

Key Insights

• “UIs change weekly. Business rules change yearly.” – Cédric Pierre, 2025
• “Entities = truth of business. Projections = reshaped data for use cases”
• “Flat, normalized data outperforms deeply nested structures in all frontend frameworks”

Working Example

{
  "user": {
    "id": 123,
    "name": "John Doe"
  },
  "orders": [
    {"order_id": "A1B2C3", "amount": 99.99}
  ],
  "permissions": ["read", "write"],
  "stats": {"total_orders": 5}
}

(This “blob API” fails when used in mobile apps or analytics pipelines.)

Practical Applications

• Use Case: A SaaS company using normalized entities and projections for mobile, web, and partner integrations
• Pitfall: Merging user profile, permissions, and analytics data into one response causes duplication and fragility

References:

• https://dev.to/cedricpierre/why-you-suck-at-structuring-data-and-how-to-finally-get-better-1k1d

---