The idea of a modern web application can vary greatly - but at MakerKit, we have a good idea of what it looks like.
Most SaaS companies use different codebases (or many) for the marketing website, the product application, and the documentation website. The marketing website usually is the top-level domain. The application gets hosted on a sub-domain (such as app.example.com), and the documentation at (docs.example.com)
Historically, there have been good reasons for doing so, such as:
- Deployment: separate deployment means less risk of breaking one or the other parts of the stack
- Engineering Time: having its dedicated marketing website (typically using a CMS such as WordPress) means that your company won't need to involve the engineers in technical aspects, saving costly engineering man-hours
- SPAs: the growth of client-side SPA (Single-page Applications) frameworks in the past decade made it impossible to achieve the decent speed and SEO needed for any marketing website
- Concerns: better separation of concerns; the marketing website needs to be an SEO beast, the product a fast and secure application
- Analytics: separate and more straightforward analytics tracking
As you can see from the above points, many would argue that having a separate codebase can be advantageous in many aspects. But it's not black and white, and for many reasons, we at MakerKit think that a portion of websites would instead benefit from having a single codebase.
Technical Progress with SSR and SSG
While not anything new, it's only recently that SSR (Server-side rendering) and SSG (Static-site generation) have been popularized and democratized for Product applications.
Technical progress from frameworks (React, Next.js, Svelte, Vue, Angular Universal, etc.) and PaaS (Vercel, Firebase, etc.) have been outstanding and made it easier than ever to ship a full-stack application.
MakerKit uses Next.js and makes the most of its incredible hybrid SSR and SSG to ship dynamic pages for the product Saas, and static, SEO-optimized web pages for the marketing website's content and documentation.
Branding and Styling
One of the most challenging undertakings for companies using separate codebases is delivering unique and consistent branding and styling across all the codebases. This is especially hard when outsourcing the marketing website to external companies or when built by a different internal engineering team.
One of the ways this can be solved is by using internal UI Components systems built with Web Components that you can reuse across various applications and websites. The downside to using Web Components is the added engineering cost of developing and maintaining the code necessary to deliver the needs of all the consumers involved.
A unified codebase means a more consistent styling/branding, more reusable components, and fewer costs associated with outsourcing your technology stack.
Seamless Navigation and UX
Another issue with having separate codebases is that, in many instances, the navigation between the Marketing website, the SaaS application, and the documentation website happens across different domains and technologies. From a UX perspective, this is far from ideal.
The navigation will be slower, and the UI less consistent. Furthermore, it can be harder to deliver delightful experiences for your user, such as persisting the authentication, ad-hoc and personalized content to your visitors, etc.
A unified codebase means a more seamless and much faster navigation and User Experience, the ability to deliver personalized content (for example, providing an API key for users navigating through your documentation), and ultimately happier users.
When not to use a unified codebase?
It's undeniable that, despite the solutions listed above, a unified codebase is not the most viable solution for every company.
It's not something we'd recommend in the following situations:
- Company Size: if your marketing speed and team outpace your engineering team, it's clear that having a codebase that needs development work and maintenance can hinder and slow down both your teams. Having a website that the marketing team can maintain is the best decision.
- Mission-Critical product: if your SaaS product is mission-critical (for example, a bank), it's clear that you will want to reduce any risk to your clients; in this case, a separate, ring-fenced codebase can be the right solution
When should you use a unified codebase?
In our opinion, smaller companies, startups, solo developers, and indie hackers would benefit significantly from having a unified codebase. SaaS starters such as MakerKit would be the best way to kick-start products and ship them quickly to your customers.
These developers are the most likely to build all in-house and are usually more technical and agile.
Does it sound like you? Contact us, and let's find out if MakerKit can be the starter for your next SaaS.
