The bottom line is a balance of functional requirements (e.g: user facing features) and non-functional requirements (e.g: maintainability, performance). Software that doesn't implement non-functional requirements has a name: a functional prototype.
Bad engineering feels like taking a loan of technical debt to pay your manager, so customers can be scammed receiving a half finished product for the price of a finished one.
In the other hand, when you do good engineering you can proudly stand behind your work, be motivated and engaged.
You can sell a functional prototype for a while, until customers start massively reporting bugs, someone finds a severe vulnerability, or you end up with a 1000 developer payroll to compensate for low maintainability and people getting checked out.
Sometimes it's better to invest a bit in other aspects as well. Of course, you don't protect a $100 bike with a $1000 lock. There are tradeoffs.
Bad engineering feels like taking a loan of technical debt to pay your manager, so customers can be scammed receiving a half finished product for the price of a finished one.
In the other hand, when you do good engineering you can proudly stand behind your work, be motivated and engaged.