Ship Now, Deal With Consequences Later

You'll run into default problems, like missing deadlines. Or features that grow into a separated project over time & budget, a client that can't pay for code quality, code that won't be tested appropriately, etc.

It should work, but with a few "small" add-ons that will force you to redo your DB architecture.

We all know how hard it is to support an old code. It's always easier to start from scratch and spend a lot of time while building complex and custom solutions.

I'll say it again and again, you or your team should take responsibility for project competition. What steps should you take that will simplify your work and help you to avoid a bad experience? Not an easy question, I admit.
But it is necessary to mention that we all should understand that the market will dictate terms on how to deal with the old codebase.

Depending on market, development speed can vary. A complex fintech project will be pretty hard to update and support. Security, and working with financial transactions are not simple. This is why banks and healthtech companies usually have huge teams.
It is much easier to update "an ordinary dev project". Yes, the project type will reflect the costs of the upgrade.

Documentation should be prepared and approved by executors and decision-makers. No, you can't start coding without it. Even if everyone knows what he or she is doing. Would you undergo surgery without having a thorough examination?

(Hint: NO, you wouldn't; and this is why someone should play a bad cop with a pessimistic attitude. It's part of a leadership role.)

It can't be a manager or developer that doesn't give a f. I mean, besides shareholders, someone in your team should be your "product manager."
And don't forget to provide him with a bonus. If you don't, you're just stupid.

Documentation Must Be Created!

Not just for fanciness. It should be your main document, a roadmap that everyone will always have at hand and can navigate it pretty quickly.
It's easy to test if you have created a great resource: people have stopped asking questions verbally. I'm not against that, but it is always better to keep everything in a written form.
Everything can be missing after having a quick chat. And it will be gone in 1 day.

Welcome Heroku, today`s newsletter sponsor. Heroku Code[ish] is a podcast where real developers talk about different aspects of their work and life, even behind the laptop screen. Dive deeply into the tech debt problem with professional developers.
If you think that something is not covered in your project, then don't think you are better than others. This attitude will help you avoid any further problems.
Do you know the Sydney tourist attraction, the Opera House?

This project is a playbook story for project managers. It was a PM disaster.

They spent three times the budget and missed all their deadlines. I think software developers may have been involved, because we are pretty good at missing our deadlines.

Are you sure that your clients or shareholders are ready to deal with the same kind of situation? Usually, they don't, and they WILL Blame You even if your intentions were good. So be careful with the old code that has a lot of tech debt.
There is a reason why it is better to fix it during the development phase, not after. This is why I'm using the CodeClimate Quality tool for my small code projects. It shows me how bad I'm at coding.

I know you have something to share with us. We're waiting for your story. 😍