the marc lou drama and security lessons

Lucas Chitolina - Oct 26 - - Dev Community

People are canceling Marc Lou on the internet.

In recent days, one of the most influential figures in the indie hacking community has been facing harsh criticism over security vulnerabilities in his product. To summarize, Marc’s product is Ship Fast, a SaaS boilerplate with the promise of "Ship your startup in days, not weeks."

Some of the main vulnerabilities include: a lack of validation in the email API, username validation only on the frontend, and, most critically in my opinion, a method that allowed users to bypass payment and access the product for free.

All these vulnerabilities have raised doubts about the product's capabilities and the philosophy behind "Ship Fast."

In this post, I want to defend this philosophy and clarify that it isn’t about launching things hastily or irresponsibly but rather about delivering only what’s essential as quickly as possible (and yes, security is non-negotiable).

The essence of "ship fast" is to get feedback in short cycles, where the primary goal is to validate acceptance and functionality with agility. For example, when launching something new, it’s not crucial to include email integrations, mobile versions, reports, or platform integrations right off the bat. The focus is on launching the core version first and then adjusting, optimizing, and improving based on user feedback – and doing so in a safe and responsible way.

I don’t believe Marc acted in bad faith; I just think that security was underestimated. Given his considerable revenue across products, he could have easily hired a security consultant, which would even be a smart strategic move.

Ultimately, I think we’ve all learned something from this whole ordeal: security and quality should not be sacrificed for the sake of speed. At the end of the day, people are using your product, and the weight of a security guarantee is far greater than a feature you’re not even sure anyone needs.

What do you think? Tell me in the comments

. . . . . . . . . .