Could you share some/all of your "never do again" and "needs to be done before launch" lists?
* Have a testing framework in place (you don't need 100% of tests written during dev, but make sure your shit is testable and written with tests in mind)
* have a deploy plan that is one step
* have a rollback plan that is one step
* have backups running way before launch
* have one-step restores from backup running before launch
* make sure your restores make their own backup before running (yeah... that day sucked)
* write enough documentation that someone not involved in your project can setup a dev environment and make simple changes/deploys/rollbacks
* document your production system setup and make sure you can reproduce a production system from your documentation alone (this WILL bite you in the worst possible time if you need it!)
* make sure you have a plan for database migrations and it works 100% of the time (and in both directions! Have a "deploy" migration as well as a "rollback" migration for every single change!)
* Have someone that is not a developer use the app without any documentation (this is huge)
* Have a lot of logging and a way of easily viewing them (you can always turn logging down fairly easily, but adding it after the fact is a lot more work)
* build a lot of "support help" tools in from the start (things like the ability to see errors that happened from a specific user, or at a specific time, or in enterprise applications the ability to grab screenshots from the device that is being helped, or built-in remote desktop if applicable)
* Get a bug reporting system in place so users can easily send you problems and issues with as much information as they are comfortable with
* make sure you can deploy hotfixes easily and at any time even if the live version of your app is months behind master
* plan to have more developers at some point. Even if you don't now, even if you can't fathom having more than a few people, just keep it in the back of your head that there's a chance that 10+ people could be working on this code, so maybe that cute one-liner shouldn't be used here...
* stick to a style guide
* put a version number somewhere visible in your app (even if it's REALLY small) so when people send you screenshots you can instantly tell if they are behind or up-to-date or if they got yesterday's hotfix, etc...
And a lot more i'm probably forgetting...
I will give one warning that a lot of what I really learned is when to prioritise one of these things and when it's okay to let it slip.
Like should I push the launch date back 2 weeks to implement bug reporting? Is it okay to launch even though I don't have 100% test coverage? When should I prioritise writing tests for the remainder of the code? How much time is too much time to test a particularly difficult to test portion of code?
I don't really have answers or rules for those, but after living through each of them, I have a much better feel for what to do. And as always, shipping is better than not shipping. Code that you never release because you are always trying to make it perfect doesn't help anyone. At some point, good enough just needs to be good enough.
Quite honestly, I wish more tech interviews would focus on this kind of stuff rather than language trivia and "stump the chump" algorithm questions. It's 100X more important to the success of a project than how you would implement quick sort.
But at the same time, most of those things on that list many people would consider "obvious", but when the deadline starts getting close they start slipping (because shipping on time is more important than some stupid logging shit!).
Then before you know it you are a month after launch and you are drowning trying to figure out what the damn emails mean when they just say "The app won't work" and your boss is still pissed from the deploy you did a week ago that ended up taking over an hour because you never tested the restore system, and every few days you get a report of the whole thing crashing but you have no idea where, why, on what platform, or anything about it.
That's the kind of "lesson" that I ended up learning. Pushing the ship date back a week or 2 isn't really that big of a deal in 99% of cases. And having good ops in place, a healthy amount of testing and support code, and some nice documentation doesn't take that long if it's done at the start, and can save you a LOT of time and grief in the not-so-long run.
You say it like a joke but its actually very good advice. If you have a working app break over the weekend, it could be a disaster.
There's a similar axiom an old surgeon told me: if you can help it, never plan a surgery that will end when the working day closes.