Hey there, Allan here.
I think that one of the best parts of being a web software developer is the power you have over your application. In an offline product you need to care about older versions and compatibility issues, and it’s really challenging to find a good development pace.
(I know, if you build an API, you must take some of these in account too, but you still have full power over how you deal with it)
With this in mind you can find a good development speed and put things in production while they are still under heavy development. This way you can build an initial “user base” and see how your product/service behave in the real world. And this is what all we do is about.
Note that your user won’t know what he wants (even if he thinks he does), but analysing his data and his behaviour can (and should) influence your next steps. Therefore, put things in production should be you main goal. Focus on your “main functionality”, and when it’s working nice and easy, it’s production time.
I know that this sounds too agressive, or to crazy to actually work, but as some smarter folks stated, it works. Otherwise you will find yourself with a big frankenstein that tries to do everything everywhere.
Also, lookout for premature optimzation: sometimes we spend days trying to improve some routine without even knowing if it really needs to be optimized. And, in the end of the day, your customer doesn’t care if your code is extremely elegant, or just plain simple, as long it does what it needs to be done, and within the expected time.
Of course it’s no excuse for you to write shitty code and say “you have to be fast!”. In my experience, yes, you have to be fast, but fast in the long run. If you code bad, you might be able to put first in production, but will make maintenance harder… and, as we know, maintenance is where we will spend most of our time as software developers.
To be short, your job shoud be: analyze user behaviour/needs, define feature, code right, test right, put in production, repeat