> The message is: create something of value.

I've learned that lesson when working on a $100M ARR product that was basically thrown together PHP spaghetti code that was launched as a prototype and never was refactored again. Most terrible code I've ever seen, yet made a LOT of money.

If it makes sense to you, and you don't expect to grow an engineering team - go for it.

Some of my best stuff was built by embracing "done beats best practice."

Correct me if I'm wrong but he's also not an experienced engineer (or at least wasn't), he was self/google taught and focused on just making the vision he had, copying copious amounts of code from places like SO.

So it completely makes sense in his context. How was he ever going to focus on the other code qualities?

If on the other hand you're experienced it's probably about finding that trade off between perfectly orchestrated software and having something that delivers your vision in an acceptable amount of time.

The best language to use is rarely the hot language at the moment. You have to choose if you want to learn a business or learn a stack.

Not using php or something simple for you it will hold you back. Setting up a top of the line container devops system will slow you down and gives you a false sense that you are doing anything.

It is nice to start with the cleanest best office with a desk but if you spend your time focusing on making your office better you never focus on the actual job.

Years ago I worked for a guy who fell into this. Successful career in insurance industry but going through a failed mariage he pivoted and quit his job and started a recruitoring firm. The office he rented was near my college and he offered me a job.. I was employee #1. First day we decided to skip work and we went on a bonding trip playing golf and go by his exes house to steal a chair. Everyday he would find something to do from making business cards, to buying office supplies to going to colleges to randomly meet people and tell them what we did. He hired two more college students to make a website. Everyday he found something to do.. but he never sat in the office and made the calls he needed to. There was always something else to do. When the money ran out (very soon) and he crashed his car drunk. No one got paid (aside from me) in the backrupacy. In the end he ended up back in insurance in a new relationship he found along the way.

He was playing CEO. Don't play CEO or CTO. Sit down and make the difficult calls.

> How was he ever going to focus on the other code qualities?

Even if you can, you shouldn't expend a non-trivial amount of brain cycles on that, especially early on.

> If on the other hand you're experienced it's probably about finding that trade off between perfectly orchestrated software and having something that delivers your vision in an acceptable amount of time.

Don't.

As someone who built (and sold) a business before and is building a new one, I'd say it really doesn't matter before you get traction. Just ship the damn thing however you can!

The chance of a first-time founder succeeding is incredibly slim anyway. So, you're better off spending your time figuring out distribution and finding a good enough market.

I think engineers gonna engineer though, even if it's subconsciously or small stuff, hell it might be half the fun.

You could ask me to build a project with no trade offs regarding time to deliver, it's still not going to be in one single file, primarily because it's one of many "quick wins".

The key is not to go overboard. As a first-time founder, you don't know when to draw the line and focus on valuable stuff. It's very, very easy to get sucked into minutiae that don't matter at all (been there, done that). That's why I think first-time founders should ignore most engineering best practices and ship the prototype as fast as possible.

> primarily because it's one of many "quick wins"

Be careful with that, though. You might have an illusion that you're making progress, while in reality, you aren't.

I'm with you on having the fun part!