I’d never skip this (not even in an MVP)
There are many approaches to building an MVP, but one element should always be prioritized: database modeling. And I advocate for doing this early.
After building dozens of apps for clients we found one thing working really well.
My name is Till Carlos and I document how my team builds products. And today we are talking about a why investing time into the database model is important.
Actually it is a high ROI activity. This is why.
Reason 1: It’s cheap, especially early
A lesson from the High Output Management book
“The key to most good decission-making is gathering information early.”
If we find problems: better do so early.
Let’s talk about a simplified process of coding an MVP.
- Know the use case and have customers ready to go don’t code without this
- Define the database model to support this use case
- For all other tables: autogenerate the code in an admin interface
- Code the main use case, and make it nice. the expensive step
Then launch and monitor the data that users process. Learn from them. Then improve.
By moving database modeling early, we gather crucial information and can make important decisions quickly, potentially avoiding costly mistakes down the line.
Reason 2: It’s a basis to talk to the UX
A well-thought-out database model facilitates meaningful conversations with UX designers and product owners.
UX might make something fancy like
You’ll be equipped to discuss the underlying data structures that will bring those designs to life. This alignment between design and data can prevent future headaches and ensure a smoother development process.
Reason 3: It sets the conversation - and we better have good names
There’s 1 thing about software development that’s hard:
- naming
- off by one errors
If this MVP becomes a full-blown software that makes money, you will always talk about this one table you named very early on. Hundreds of conversations will include this name. Better name it right.
Reason 4: There are ways not to waste time
In our MVP stage we don’t want to build a lot. Especially not CRUD controllers for this something trivial that we only use to check, or set up.
Examples:
- Debug API requests
- Set up user accounts.
Solution: install an admin package. Here, I use RailsAdmin. But if you use Django, you can use that.
Some ideas:
- the MVP should only contain the MAIN use case, done really well
- but we still have all these tables, and we want to store data.
Why do you need these tables?
- They are cheap to make now
- You need them for debugging
- the MVP probably needs them anyway
Example: ApiRequest. I want to see them.
But I don’t want to build the whole MVC / CRUD for this.
Solution: install an admin package. Here, I use RailsAdmin. But if you use Django, you can use that.
Why this is important:
Many developers think “it’s easy, just 2h of work to make this panel.” – It never is! It’s never just “an hour” or, “a weekend feature”. These things can take a life on their own.
If you update a relation, then you need to refactor your code.
It’s not worth it. Keep doing the MAIN usecase well, and move everything to a code generator.
Remember: invest in your database model early. It’s a small step that can save you huge headaches down the road.
