Why You Should Keep Your SaaS Installed On A Subdomain
Published: March 29, 2021
Last Updated: October 11, 2021
More than a few SaaS founders start out with a technical background, looking to parlay their coding skills into a product and build a business off it. Their surplus of coding ability and lack of practical business sense can sometimes lure them into a trap though, and that trap is attaching their marketing website to the build of the rest of the SaaS application. In this post we’ll talk about why that’s a bad idea and why it’s better to stand up your SaaS app on a subdomain and integrate later, if needed.
Decoupling and Separation of Concerns.
Decoupling is a term, most programmers should be familiar with but is also one of the main reasons to separate your marketing site and SaaS app. When you have your SaaS app installed on a sub-domain and decoupled from your core marketing website, you have removed their dependence on one other, which allows for separation of concerns (another common programming term). It’s hard to see it has a pre-seed 2 man bootstrapping team but eventually you will have to hire separate teams to build and maintain your SaaS app, and handle the sales and marketing of your business.
These teams are going to have different priorities and needs, and one of the most unproductive things you can do is slow them both down by tieing their release schedules to the same code base. Each team should be able to build, create, design, and publish new changes to their hearts content, independently. Failing to do so carries a risk of building resentment and creates bickering amongst managers and team members as people point fingers across the aisle at one another when one or both teams are delayed and miss key deadlines. Positive culture and team spirit can make or break a startup in the early days so you want to avoid reasons for it to break down as much as possible.
Our marketing website and SaaS product are both under the same domain, however they are hosted separately and routed via DNS. The net effect is the same. Tech stacks are separated, allowing our engineering and revops teams to make progress and publish independently, while collaborating where needed.
Asia Corbett, Director of RevOps at Postal.io
Decoupling Tech Stacks
Many SaaS apps are built on the latest and greatest technology, but that doesn’t mean your marketing website has to be. Technologies like WordPress have an enduring presence in marketing for good reason, they are well known, simple to use for nontechnical folks, and have already solved a lot of the problems marketing teams face around web content creation and distribution. You don’t need a NoSQL database, a Redis cache, and a React front end to create and publish a blog post.
“Our core app is hosted on Amazon Web Services which only allows us to map to a single domain and is on a subdomain. Our marketing website is powered by Webflow and resides on the main brand domain. This separation allows our dev team to leverage all the AWS has to offer with external integrations and reporting features to deliver best in class funnel analytics to our customers, without interfering with what the marketing team is trying to accomplish.”
Matt Volm, Founder of Funnel IQ
This makes one of the best reasons to install your SaaS on a subdomain and decouple it from your marketing website, the chance to choose different technology stacks for each one. That way you can choose your technology stack for the task at hand, rather than having to make considerations for both. Another reason you’ll be glad you did this is that startups occasionally have to make tech stack pivots for one reason or the other. If you decide to scrap your SaaS and re-write from the ground up, you’ll be glad your digital marketing website won’t add to the scope involved in that task.
Decoupling Labor Costs
When you decouple tech stacks of your SaaS app and marketing website you are also doing yourself a favor by controlling the cost of labor. Technologies like WordPress, HubSpot, and other common CMS’s have developers, hosting, and other resources available at more favorable pricing, at least when compared to the cost of SaaS programmers, dev-ops resources, and other higher skilled employees and contractors. This mean you can maintain and control the costs of growth of your marketing functions independently of your SaaS app.
Better Information Security
If you wrap your marketing website in with your SaaS app, this presents an information security risk. This means any marketing related changes are going to be an attack vector for your entire application and will need to carry the burden of regression testing, penetration testing, and other information security related concerns that may be required from your SaaS app, but may not necessarily be as important in a marketing context. Developers that work primarily on front end presentation are likely not aware of backend vulnerability, which means they will be more likely to open your app up to injection attacks. When your SaaS application is on a subdomain with separate hosting, the burden of information security compliance and testing is contained to the SaaS app. With cloud security becoming more complex and expensive to implement by the day, this is something you will thank yourself for later.
Final Thoughts
Separating the concerns of your marketing website from your SaaS product is a decision that can yield many benefits. For some companies their may be a compelling reason for them to be tightly integrated, but in the absence of that, separating these out will eliminate barriers to scalability and allow teams to work more effectively on their respective tasks. Have you installed your SaaS on a subdomain, or have you wrapped it in tightly with your public facing marketing website? Let us know what you did and why in the comments below.Further Reading:
