> We had a production-ready suite of apps built from the ground up over the past few months, but as we got closer to launch, the incompetent work from other teams started to become painfully evident to proceed any further.

Claiming that software that never saw any real production traffic is "production-ready" is a bold claim to say the least. I dug into the code base and there doesn't appear to be _any_ tests. I really hope no one actually uses this application for anything real. I will say that the code does appear to look clean. But validating its functionality is a mammoth task that probably isn't worth doing when existing marketplaces/hosted stores already exist that undoubtedly do it better.

The author also doesn't seem to have any qualms about burning bridges either.

> Claiming that software that never saw any real production traffic is "production-ready" is a bold claim to say the least.

What is production traffic?

> I dug into the code base and there doesn't appear to be _any_ tests. I really hope no one actually uses this application for anything real.

Why? Plenty of great software doesn't include test files, and that's not a bad thing. Writing proper test files means you'll easily end up spending 2/3 of the time writing test code, and even after you've written all these test files, then you still have to do a lot of external tests as well. For instance, setting up external uptime services to ensure things are running as intended, testing everything is loading properly on multiple browsers + devices, stress test, etc. You seem to assume they've done no tests whatsoever just because they don't bother writing test files.

> But validating its functionality is a mammoth task that probably isn't worth doing when existing marketplaces/hosted stores already exist that undoubtedly do it better.

It's worth doing if you're interested in working with a similar stack. I won't comment on the server code since I haven't worked with Node (and hate JS), but the Vuejs client looks good.

> The author also doesn't seem to have any qualms about burning bridges either.

I agree, but the same could be said about you.

Yeah the tone of that entire article struck me as very arrogant. Even "small" things like "my engineers" -- I don't think I'd want to work with this person.

You obviously don't understand your position in the economy then. As an engineer you are a comodity. As much as you would like to deny this fact you still are. Why do you think that you make a salary and the companies make hundreds of millions or billions!?!?! The tone of your comment struc me as very arrogant.

Maybe it’s cultural differences but in Australia I have never heard “My engineers” and would never use it myself.

A company does not own it’s employees. It simply purchases their labour.

That's a very odd way to view a generic term. I don't own "my friends" but I wouldn't think twice about saying "my friends went to the bar last night". Similarly for "my co-workers", "my manager" or "my uber driver". Just because someone used an uncommon expression, does not mean they have some nefarious intent behind it. Especially when the context is completely innocuous

> I was too mesmerized working heads down with my engineers knocking out features and crunching out thousands of lines of code for a few months

> Why do you think that you make a salary and the companies make hundreds of millions or billions!?!?!

Marx had this neat term "surplus value" to describe that problem.

Calling your coworkers "incompetent" in the second paragraph is.. a look. Especially when talking about false dependencies and over-engineering an MVP. A complete lack of pushback from engineering will lead to teams taking a dependency on engineering building the whole world, but this problem isn't just a "them" problem - pushback on expensive asks is a necessary part of business.

What the article expresses is what I have also gone thru in my personal journey as an entrepreneur as well.

I used to be in love with technology and built stuff in my own bubble. None of it gained traction. Then, I put less emphasis on tech and more on product-market fit and the let the two play off of each other. Obtained much better results!