A year ago, I would have agreed with you. There's nothing stopping you from building a successful product without writing tests. Since I built the habit of writing tests, though, It definitely makes a difference, especially if you're working with a team or contractors.
Tests are a super helpful way to say "See, this works. Make sure it keeps working, everyone."
I would manually test every aspect of it, and make sure there are no known defects. So any defect found by a customer would likely be some obscure edge case.
Data redundancy in multiple locations and good logging can fix that problem better that tests, I think. Most bugs can be found anyways during development without coded tests.
For a very narrow range of software, I suppose. Not for software that has side-effects and actually does stuff in the real world.
What about software that sends emails to people, or places orders, performs billable work, or gives people directions, or supplies them with data that they then carry forward and use in decisions or in other systems?
And are you proposing that instead of writing tests you write a play-back-able-log system that can roll back state and re-apply transformations if a given component did incorrect things?
I think sensible testing is the way forward, where sensible is appropriate to the type of application, language and requirements. 100% coverage is suitable for industrial code and 1% coverage is appropriate for toy projects. But no tests at all seems foolhardy.
Not sure what you mean by "coded" tests, but I agree that most bugs can be found during development - unfortunately, my experience is that that's rarely the case. But if your development team finds most bugs during development, my hat's off to you.
Tests are a super helpful way to say "See, this works. Make sure it keeps working, everyone."