I'm doing this one thing differently next time I build a SaaS product

#devjournal #productivity #architecture #startup

As one does the further they progress in their career, they develop wisdom based on their experiences and apply it with future opportunities. When it comes time for me to build my next SaaS product, one piece of wisdom I intend to apply is to host my SaaS Product and Marketing Website on separate domains. Seems simple enough, but why is this a wise piece of advice? As products scale and businesses mature, the necessity to demonstrate the integrity of your product becomes more paramount.

Since Information Security falls under my domain as Director of Infrastructure for four B2B enterprise SaaS products, I regularly have to interact with external stakeholders: Customers, closing deals (sales), auditors, and even insurance providers. At least once a month, someone will conduct a due-diligence task on their end by publicly scanning my domains and confront us with the findings.

While I think it's important to address vulnerabilities, not all vulnerabilities are the same:

Some vulnerabilities are benign because your use case is not applicable
Some vulnerabilities cannot be reconciled as they were past decisions that are unable to be changed
But most importantly, some vulnerabilities create a liability for customer data, and others do not.

In my context, 99% of public probing does not identify vulnerabilities that meet the third point, but it's the only reason why the feedback is being given. And because people think they've identified a risk to their data, they're often times unwilling to accept the simple answer, instead sucking up my time through multiple interactions to effectively communicate our integrity. If I separate the marketing website from the actual SaaS product, I'm better positioned to deflect these reports, as I can instead encourage them to rescan the domain where the customer data is accessible.

So, for my next SaaS product, expect the following: