TL;DR
Before writing a single line of code, take one day to model your data.
Find the central entity that drives your system — everything else will naturally revolve around it.
This simple discipline turns chaos into clarity, prevents endless refactors, and keeps your logic aligned with real business needs.
Modeling isn’t bureaucracy — it’s efficient laziness: thinking once, well, so you never have to redo the same work.
Before diving in, a quick nod to a great post I read recently: These 5 Coding Habits Separate a Good Developer from a Great One.
It starts with a truth I fully agree with: great developers think “why” before “how.”
That mindset is exactly what this story is about — modeling before coding.
Why I Spent a Few Hours Modeling Before Writing a Single Line of Code
There are two types of developers: those who open their editor and create tables as needs arise, and those who first pull out paper and pencil.
I belong to the second category. Not out of dogmatism, but out of pure laziness: I hate doing the same work twice.
Modeling before coding is like reading instructions before assembling IKEA furniture: it takes 5 extra minutes at the start, saves 2 hours of frustration later.
Recently, I developed a GDPR training management application for SMEs. Strong constraint: Regulatory Compliance certification, meaning total traceability required. No room for shortcuts.
Result: one day of modeling, 25 structured tables, and since then... zero refactoring, zero side effects, zero headaches. Here's why this initial discipline changes everything.
1. The Context: A Real Business Need, Not a Style Exercise
My client manages GDPR training for small and medium businesses. Their needs:
- Track training sessions (dates, locations, statuses)
- Manage client companies and their trainees
- Generate and archive mandatory documents (agreements, attendance sheets, certificates)
- Track business referrers
- Collect post-training evaluations
- Be compliant with Regulatory Compliance regulations
In short, a niche CRM with strong regulatory constraints.
Everything hinges on the rigor of initial design. Without it, the project quickly becomes an intractable puzzle.
And most importantly: a project where the client didn't have the budget for a complete refactoring 6 months after launch. It had to work right away and for the long haul.
2. The Game-Changing Question: "What Is My Central Data?"
Before touching any code, I asked myself THE question: what drives this application?
Not "the company," not "the trainee." No: the training session.
It's what triggers everything:
- A company purchases → session created
- Trainees enroll → linked to the session
- Documents are generated → attached to the session
- A referrer is credited → on the session
- Evaluations are collected → for the session
Once this pivot entity was identified, everything else organized naturally around it.
Why Is This Crucial?
Identifying the central entity means:
- Clarifying priorities: what needs to be 100% reliable?
- Simplifying relationships: everything revolves around one clear point
- Avoiding chaos: no tables created "on a whim" without an overall vision
In your project, it might be an order, an appointment, a file, a project... But there's always an entity that drives the system. Find it first.
3. From Paper to Schema: How I Structured the Database
Before Paper: The Right Questions
Before even pulling out the pencil, I spent time asking questions. Lots of questions.
Because I've seen specifications that didn't match the real need. The client asks for A, but digging deeper, they actually need B.
Some questions I systematically ask:
- "Can a company order multiple sessions over time?" → Yes → 1-N relationship
- "Can a trainee attend multiple training courses?" → No, never → no intermediate table needed
- "Which documents must be automatically generated vs manually archived?" → Direct impact on structure
- "Who should be able to view/modify what?" → Anticipate access rights from design
Result: A few scribbles, but no discarded code, and zero refactoring.
Efficient laziness also means never drawing the same diagram twice.
I spent a few hours with paper and pencil.
At the Center: training_sessions
One row = one specific session (date, location, price, status)
Around It, Satellite Entities:
Entities directly linked to a session:
- trainees (N-1: directly attached to a session, because for this client, one trainee = one training)
- documents (1-N: agreements, certificates, attendance sheets...)
- evaluations (1-N: quizzes, feedback...)
Reference entities:
- companies (1-N: a company can order multiple sessions over time)
- referrers (reference table)
The Principle: Each Table Answers a Business Question
- Who buys? → companies
- Who participates? → trainees
- Who brought the business? → referrers
- What documents? → documents
- What results? → evaluations
Result: 25 structured tables in one day.
No redundancy, no ambiguity, everything logically connected.
Why This Simplicity Works
Because I stuck to the business logic:
- A trainee only takes one training → no need for complex intermediate table
- A company can order multiple times → obvious 1-N relationship
- All documents are linked to a session → no "this PDF, what's it attached to again?"
The structure fits the business. It doesn't force unnecessary complexity.
4. What This Rigor Saved Me (and Will Save You)
Classic Pitfalls:
- Creating tables "on the fly" without overall vision
- Duplicating data (company name in 3 different tables...)
- Struggling to add a feature ("where do I put this info?")
- Emergency refactoring because the structure no longer holds
What Initial Discipline Brought Me:
Clear queries: 'Give me all documents for session X'" → simple join, no workarounds
Easy additions: "We need to manage certifications?" → new satellite table, zero side effects
Regulatory compliance: everything is tracked, timestamped, linked (Auditor-smiling traceability)
Immediate reports: "How many trainings this month?" → already structured for that
Zen maintenance: no surprises, no "hey, why is this data duplicated?"
A Concrete Example
My client asked me three months after launch: "Can we add payment tracking by installment schedule?"
Answer: "Yes, give me 2 hours."
Why? Because the structure was already there. Just add a payments table linked to training_sessions. No existing tables to touch. No side effects.
If I had hacked it together at the start, it would have been 3 days of refactoring.
5. Why This Approach Is Rare (But Should Be the Norm)
Let's be honest: most developers code first, model later (when they model at all).
I've always done the opposite. Not out of virtue, but out of pure efficient laziness: I hate doing the same thing twice.
My Philosophy: "Never Do Twice What Can Be Done Once"
- Spend a day modeling vs spend 10 days refactoring? Obvious choice.
- Think for 2 hours before coding vs debug for a week? No debate.
- Structure cleanly from the start vs drown in technical debt? The answer is clear.
This "laziness" has always saved me time. And energy. And peace of mind.
Why Is This Rarely Taught?
- Pressure to deliver fast: "We'll see about that later" (spoiler: we never do)
- Belief that "we'll do it properly later": we never do, we just pile on
- Lack of training on modeling: many tutorials show how to make it work, not how to structure
But What About Exploratory Projects?
Fair question. "What if I'm building an MVP and the business model changes every week?"
Here's my take: even a 30-minute napkin sketch forces you to ask the right questions. Can a tool be rented by multiple users simultaneously? No. Then your Rental needs start and end dates.
Without this quick modeling (even on a napkin), you code "by feeling," and that's where waste begins—even in exploration phase.
Modeling isn't the enemy of exploration. It's what makes exploration efficient instead of turning it into procrastination. It's "efficient laziness" applied to uncertainty.
Even if you throw the schema away in two weeks, it validated part of your hypothesis. That's not wasted time—that's rapid learning.
In a Professional Context, Especially for SMEs:
- You can't afford mistakes (compliance, traceability)
- You can't afford to refactor every 6 months
- You need to evolve the app without breaking everything
Investing one day at the start to avoid 10 days of struggle later: it's just common sense.
6. The 4-Step Method (Applicable to Any Project)
Step 1: Identify the Central Entity
Ask yourself: "What drives my system?"
- For a shop: the order
- For a medical practice: the appointment
- For a project manager: the project
- For my client: the training session
Step 2: List Satellite Entities
Around this central entity, what revolves?
- Who?
- What?
- When?
- How much?
- What result?
Step 3: Draw on Paper
No need for expensive tools. Paper, pencil.
- Central entity in the middle
- Satellites around
- Arrows for relationships
Step 4: Normalize Without Dogmatism
Avoid redundancy, but don't over-normalize either.
If your business dictates that a trainee can only take one training, no need for an intermediate table.
Stick to the business logic, not a theoretical model.
Conclusion: Invest One Day to Save Months
The secret to a sustainable application doesn't lie in the technology used. It lies in a question asked at the right moment:
What is my central data? What drives my system?
In my case, it was the training session. In yours, it might be an order, a project, an appointment, a file...
But once this question is answered, the structure almost draws itself.
And this small initial effort—pulling out paper, drawing, thinking—saves dozens of hours in development, maintenance, and evolution.
For Developers:
Adopt "efficient laziness." Never code the same thing twice. Think once, well, and move on.
For SMEs:
If you're looking to digitalize a business process, ask yourself this question before coding. Or better: work with someone who asks it for you.
Because a well-structured application from the start means:
- Fewer bugs
- Less maintenance
- Less "sorry, we need to redo everything"
- More scalability
- More peace of mind
And above all: an investment that lasts.
The efficiently lazy developer never codes the same thing twice. Their motto: think once, well, and move on.
Top comments (5)
This article is a masterful case for prioritizing database design based on core business logic (the 'central entity') before touching any code. It perfectly validates the principle of 'efficient laziness,' proving that a day of upfront modeling saves months of painful refactoring.
Appreciate it!
You summed it up perfectly: a day of modeling for months of peace of mind.
Curious to hear how you approach this in your own projects - do you start from business logic too?
I’m curious: how do you apply “efficient laziness” in your daily workflow?
This was a really good read.
I really like the "efficient laziness" mentality!
Taking the time to model before coding makes the difference between rushed development and scalable architecture.
Thanks a lot! I'm glad the idea of efficient laziness resonates with you - it’s really about slowing down at the right moment to move faster later.
Taking the time to model upfront is what turns a quick fix into something that can actually scale and last.