Let’s talk about Geebos – Generic Business Objects (GBOs).

Every product has them; they’re the nouns in your system.
For a dead-simple to-do app: User → List → Task – that’s your geebo set.

Getting these right early isn’t life-or-death, but the time you burn on re-engineering scales with the ambiguity in those relationships. Studies put maintenance and enhancement at ≈70–90 % of lifetime cost¹, so vague geebos are literally money down the drain.

Teams still over-complicate: renaming mid-flight, premature abstractions, rabbit-holing edge cases. Gen-AI and schema generators speed up the grunt work (McKinsey clocked ≈2× gains on common tasks²), but humans still own the model.

Principles that keep the chaos away

1. Start with the consumer and work backwards
   Model what your UI / API actually needs first.

2. Keep the data layer boring
   Simple tables or docs beat elegant cleverness you’ll eventually refactor.

3. Mirror the API to the data model (unless DX truly demands a BFF)
   Consistency improves developer productivity and adoption⁴.

4. Add complexity only where it adds value
   Abstractions must pay rent immediately.

5. Name things once, then never again
   Identifiers are ~70 % of source characters³; churn murders comprehension.

When early abstractions do help

Wrangling a pile of third-party services? Steal from a well-architected API (think Stripe). Point an LLM at the vendors’ OpenAPI specs, ask it to emit a unified subset, and let that subset become your geebo. Everything internal maps to it; thin adapters translate to each provider. Clean common language, zero hand-rolled Frankenstein mappings.

TL;DR

Define your geebos.
Write them down.
Respect them.

Your team and your future self will thank you.