This is probably the worst advice for a young founder.

Had a client who was a 24-year-old startup founder, one of his investors got me involved to help him hire some folks and help define project process.

We hired a great developer, who freaked when he saw how sloppy the code was. Rightfully said, "We can't maintain this..."

Anyway, the founder had written a lot of it, so it wasn't a shock to him that the code was bad and needed to be re-done. Hew knew it was all quick and dirty and hacked together. By the time I got inovlved, we had issues doing deployments (deployments would take half a day and a lot of stress around testing once code went live), we had issues around infrastructure being unstable (lost 2 days worth of customer data once after a bug caused the DB to crash), and of course, nothing would have scaled. No code review, not much of a QA process, just a million things that needed to be done better -- you can cut some corners as a startup, you can't cut every corner.

There were a handful of paying clients, but most had been sold a promise of feature A-through-Z, and really the tools did like A-through-C... the moment one of them complained the young CEO lost it because he hated criticism, especially from customers, and he didn't want people to think he had lied to them... even though he had pretty clearly over-promised.

The dev I brought on wanted to re-do a lot of things, write unit tests, set up a CI / CD process, proper backups, basically do all the stuff that should have been done day one to ensure we could work fast and have confidence the wheels wouldn't come off. The founder had been on board with trying to reduce outages and crashes, but about a week into it, when one of the customers complained about something, the young CEO freaked when he couldn't simultaneously have new features and a re-done core codebase on the schedule he wanted.

So even though a week before he had said that he liked the idea of reducing a lot of our technical debt, and giving the new dev a chance to work on clean good code... since he was young (not sure if that's the best excuse) he flip-flopped. And three weeks into the overhaul (that was supposed to take 5 weeks), he was furious. "This dev is costing us time and just doesn't get our culture and isn't aligned with our goals and just isn't working out!"

I got called in, looked over what the dev had done. Nothing short of a miracle he had accomplished so much so fast. I said as much. Later that day I get an email from the founder, "I had to let [the dev] go, he just wasn't working out." I left the project shortly after, and the founder burned through another $300k in seed money (his parents') before shutting down.

Anyway this whole "trust your gut" thing... and "don't ask around before firing" -- that's only good advice if you've got some experience and a cool temperament.

If you're a new CEO, ask around. Figure out what's going on, and if you tell people to zig, and they zig, don't get mad at them for not zagging -- they aren't mind-readers. Flipping on decisions like that are extremely demotivating to everyone who works for you, and flipping on a hire (firing someone) is the potentially most demotivating thing you can do if it's not done correctly. You hire smart people, if you can't trust their expertise, don't hire them. Since you trust their expertise, don't micromanage them, or expect the impossible from them.