@stefano.menci
your approaches and what you already mentioned with “being messy” improve when needed approach reminds me to old Xtream Programming mixed with some other principles
It is definitely not new concept and most of us doing it so.
ie. did you know that in an average software company (including big one like IBM, MS, Google, etc) over 90% of the new code will be deleted completely within 1 year! Yes, imagine tons of work devs doing that ending up in trash bin… still, this is a way to go. It is a very old stats, yet still valid. Nasa did huge effort to try to keep this under control using zero defect programming, (another methodology to good to be familiar with) and they did get around this problem somewhat, but it took another approach which is more suitable for a company, where the goal is clear before they start to make it real. Still, producing many prototype phases, which is almost the same time-effort wise as the 90% code waste…
Zero defect -in a very simplified way to say is: as early you can find a bug as cheaper it takes to fix.
Just think about it if you have a property set to a value which later find out it is not the right one to be used (i.e how many products a user can buy at the same time), fixing this limit has a huge difference based on when are you fixing it, at desing it costs like 10 cents 1 sec, (just write a bigger number) in coding it is not more then $1 and 10 sec , however when it is released it can reach $1000 and months, since need to do the whole cycle from catching the bug, identify the problem, redesign, recode, retest and release & deploy…
So get back to the main point here, being messy - or as I would say start with prototyping phase is normal for most cases. It is a way to go when you are a small team for sure. As you will hit some barrier you might think to redesign it or as we call it refactor it. This is a common way of software evolution, nothing bad about it.
It is a very common mistakes we programmer use to make is to either think too far and try to create an API or function or feature to make it easier to use / change later and adding unnecessary parameters, which might never be used in the hope it might will be needed. On the other side, sometimes we forget that we are not the only one to use this, so there might be a good reason to add a bit more common usage to it…
I think the best way to go is what you feel best at the time. Don’t get too complicate and make it as simple as you can. You can always make it complicated later 
So I can totally understand your point of “being messy” (although it has nothing to do with messy)