Questions for SaaS founders

I'm working on TinyVoicemail right now. I've found something that works great for me since it's the early days:

TinyVoicemail is a Rails app. It's a monolith.

My site (www.tinyvoicemail.com) is as minimal of content as possible. I just wanted to get the point across and give people a place to sign up. There are other relevant links as well, but they are the bare minimum.

My app (my.tinyvoicemail.com) is the actual app. It lives alongside the site.

The admin side (***.tinyvoicemail.com/not-admin-path) sits alongside all of them.

Alongside all this, I have a shorter domain that I use for SMS. It's tnvm.io. It doesn't have a service setup for it, I merely use CloudFlare's page rules to redirect.

I structure this within the routes of my application's MVC architecture.

My actual config/routes.rb (removed some stuff for security and brevity): https://gist.github.com/joshmn/1317d2ccf0c22f33d2074585a943a4a8

If you're not using Ruby, or Rails, yours will look different. But the same idea applies.

Down the line, I'll move the site off and probably sit it atop a lightweight CMS or do a static site. But right now, with a solo developer (me) and being a solo founder, it's okay to be really slim. Premature optimization is the root of all evil.

I'll keep the admin stuff where it's at. It's just what I've always done. I use ActiveAdmin, for those wondering (and I very much prefer it to RailsAdmin or Administrate).

I'm founder and crypto fund manager at coinbakers.com. We have a SaaS dashboard and everything is separated. Our separation includes web, app (dashboard), api, admin, fetcher (fetching data from exchanges), trader (does actual trades), and a separate strategy runner.

I'm also founder of a well known community site with 14K visitors per day, which runs everything on one domain.

If I have to choose, I'd like separation best for but it has definitely cons. The best thing I like is that if we are working on landing pages, it can have 0 effects on our other more critical services. Other pros are faster loading times and if you're are getting hammered with an influx of visitors, it will not affect your customers on dashboard.

SEO wise our web domain should be optimized for this by hosting all our marketing, blogs, resources there. Search engines have no businesses in our admin or dashboard so it doesn't matter there.

The con is that I use Mission Control on the Mac with 9 separated desktop, so that each environment has it's own desktop. Managing this has been challening as it can become real messy when you have everything on one desktop. This is however more of a full-stack dev issue.

It is also a bit more time consuming to set up and more costly, for example you need a wildcard SSL for subdomains.

My advice is if you are not a dev, I would refrain from making this decision and let it up to your devs. You can always change it later. The downsides for scaling in terms of users is minimal imo unless you are a household brand.

Good luck with it!

One thing to consider is SEO. If SEO is not a critical component of your growth strategy, or if your SEO strategy does not require content rendered dynamically from your platform, you can ignore all the rest of my points, and keep your marketing site totally separate from your app. Host your marketing site at www.mysaas.com on Ghost or WP, and host your app at dashboard.mysaas.com, and build it in [insert buzzy web framework].

But sometimes SEO is critical and needs to be dynamic. For example, let's say you are making SaaS for realtors. You plan to have millions of houses in your database as part of your platform, and part of your growth strategy is indexing all of those houses on Google. In that case I recommend building your marketing site and your app as a single project under a single subdomain. My understanding is that Google still distinguishes domain authority by subdomain, so you'd be "splitting" your juice (and building a jarring UX) by splitting your SEO content across multiple domains.

My site consists of:

• the marketing front end, a nuxtjs app on the www.* subdomain

• the actual app front end, again nuxtjs on app.*

• the backend, built with Django+DRF, on the all.* domain

Each 3 of these components has a GitLab repository with CI pipeline and is deployed to it's own aws ec2 instance using docker machine. With this setup, everything is separated so only the components that have changed get built/deployed. I have both production and staging environments for testing

On top of all this, I have a single aws load balancer which redirects to the relevant subdomains for both the staging and production environments.

Finally, my documentation site is a sphinx app deployed as a static site in s3, which uses cloudfront to provide ssl (I have a .app domain which means I have to use ssl for everythibg)

My deployment process could probably be speeded up by using Kubernetes but there's a bit of a learning curve for me so I haven't had time for that yet

For Trolley I've got

• a Single Page App for the dashboard, on https://dash.trolley.link

• API on a separate subdomain

• a separate subdomain for the embeddable payments widget on widget.trolley.link

• marketing site on https://trolley.link (with redirect from www on http/s)

Everything except the API is a static site, S3 + CloudFront + SSL.

The API is on Heroku.

Caveat, I'm a Rails / Ruby guy.

www.mysaas.com is the marketing site and for this I just use a static site generator like Middleman (https://github.com/middleman/middleman) and push to Netlify.

app.mysaas.com is the Rails app where users log in and do what they need to do.

Personally I've never needed more than that.

Basic admin functionality with Rails is just a gem away (https://github.com/activeadmin/activeadmin) which is more than good enough for MVP and beyond.

We have app.accelerlist.com and then blog.accelerlist.com; app. points towards a Heroku server and blog. is on WordPress.

I think you're pretty spot on, but it might be worth considering if it's premature optimization. SaaS/business is really hard, and you should consider the shortest path to getting it up so you can focus on the hard part: attracting users.

I've built 3 apps that were fully hosted - site, dashboard, and admin - within a Rails app. As long as your static/landing content is responding quickly, that's not a major problem. My admin tools were just regular users with an admin flag that gave them access to a /admin section (I added an additional layer requiring an admin pass, so if a user was accidentally flagged as an admin, they couldn't access the tools without knowing a second pass).

This never became a problem because I never had success attracting users. But if I had, it would've been easy to separate tools out as necessary.

I use static sites hosted on netlify for the www and root domains as the sales site/landing page site. I use app or similar subdomain for the user application. The admin depends on the site. I have done it a few ways, admin as a separate application, admin as a folder in the site like /admin, admin as a separate subdomain and panel and using domain based routing.

Separate application always ends up being a pain since you either have to move a lot of your data layer to a separate library or struggle to keep it aligned with the client app so you end up with 3 applications or 2 possibly out of sync ones. Unless you're using something like elixir umbrellas the 3 app route is usually more trouble than its worth.

Sub folders are good for systems where your staff will want to use the actual application itself so you can add a link to the admin section into the interface when you detect an admin user.

If there is no reason for the admins/staff to access the user interface then keep it separate but in the same application so you can start the data layer.

Following because this is important and something always interested in seeing. Helps to understand how different types of apps are structured.