Minimalist design can easily be confused with laziness, and also sometimes hard to tell the difference between minimalist and downright ugly. Here's a quick and probably imperfect example.

I've been working on a lightweight advertising/invoicing/etc design for one of my projects. One of the things I decided to store in the db was a template for what is basically a report (I'll blog on that soon). It went with a particular part of the project, so I had a table with one row that held the template. No plan for history as part of v1, we'd just change the template and move forward. Now the first part about that is minimalist is my total comfort level with the idea that if I wanted to change things later to track all the version changes it would be easily done, and would have no affect on stuff doing prior to that point.

Based on that, I stubbed in a todo item that we would need a UI to allow making changes to the template. Not a high priority item, but I've learned the hard way that if you build a system,you build the tools needed to manage it or you're doomed to only letting power users make changes.

As things evolved I needed a template for a different part of the system, and it was a very similar implementation. I hate duplication, so I stopped and looked some, and saw that I'd need one more template before I was done for yet another part of the solution. Now I could just create three tables, one for each area and let them store one row, or I could make a minor change to the first part of the solution to reference a shared template table. Which to do and why?

For me, condensing it down to one table meant I needed only one UI implemented instead of 3. Yes, they'd be similar, but each would need it's own set of procs and it's own menu item. Do I save a lot by doing that? Maybe I save an hour. Do I lose anything? As far as I can tell I don't, but it's still one table and I'm still comfortable that if I need to change things, the change is isolated to one area and won't require a lot of pain.

Even here you can see that there are some interesting design decisions. I could have stored the template in the file system and just used notepad to edit it (very minimalist), or I could have built a report in Reporting Services but I would have needed three of them, and probably other options I didn't see. The biggest reason to put it in the db is to provide the ability to edit it via the web, and I prefer not to have apps working in the file system for the web.

Regardless of whether you evolve a design my way or another way, you'll encounter a lot of places where you can add/remove complexity. Adding one more table doesn't seem like a lot. Adding 10? Think about how you'll maintain it, index it, build a UI against it, and only build what you need - without being blind to tomorrow.