Back
Question
Asked

Do you separate app & marketing sites?

As an employee of startups, it was like a written rule to have an example.com for marketing and app.example.com for the app itself. IMO, this mostly due to burning VC money on ads which is not the case when you go solo.

What’s your take for solo/bootstrapped projects? Separate domains or same?


I don't understand what this has to do with VC money/don't get your point. This is all about SEO.

You separate marketing vs. app when you have different rendering concerns.

If you're not using a SSR framework like Next.js or Nuxt, you don't want to client render your marketing site for performance reasons and because certain client rendered elements are not visible by search engines.

My setup is:
- Marketing/landing page: Astro.js (with Vue components) which renders everything to static HTML at build time. SEO is relevant here.
- App: plain JavaScript + Vue.js which is all client rendered, backend is Go which just returns JSON. SEO is irrelevant here as there isn't any searchable content and everything is behind an authentication guard.

Thank you for the response! :)

I don't understand what this has to do with VC money/don't get your point. This is all about SEO.

I want to use a single Rails app that will serve both the app & marketing site to keep it simple from the start. As it is a Rails app, it will be pricer compared to having a static page as a marketing site. In my experience, burning thousands of dollars for marketing makes running the marketing pages on the Rails costly.

Basically, I couldn't decide if it is worth separating from the start or should I worry about that later on as I don't have a marketing budget that's even close to hundreds of dollars.

I would just start with known tools (sounds like you like rails, so use rails), with the caveat being that you should keep SEO in mind. However, if you're using rails on the backend to render everything, that should not be a problem.

Yes, rails consumes more resources than other technologies. But if you're starting from scratch that doesn't matter. Many successful companies (worth billions) started on things like Django, Rails, etc and then later moved to other tech when it was clear it wasn't worth the cost. But not before then.

If something isn't scaling, fix it later and optimize for fast shipping

A separate page / subdomain can make your analytics easier to understand.

Yes, separate: rails for the app and statically generated site for marketing. It's generally a good practice (easier to change one without affecting the other, easier to give access to repos separately etc.)

But ultimately your decision should be based on development speed rather than cost when starting out. If you can ship faster with a single rails app, then do that. If you ever get to the point where you get so much traffic that cost becomes a concern, it's a good problem to have and easy to solve.

I think the main reason it works like this is because you need the marketing team to be able to edit the website without having to rely on the engineering team.

This is not a concern for solo/bootstrapped projects, and it's way more convenient to have everything at the same place imo.

The second reason is the marketing website needs to be more optimized for SEO, so if what you're using to build the app has no SSR support it might not be the best choice.

Yes, I have dash.screenshotone.com versus screenshotone.com for marketing.

Basically, I did that because the marketing site is just a static HTML site. But the dashboard is a full-stack application.

But at the beginning for a new product, I probably won't separate them.

Agree with Ben here. Marketing site is for SEO and building persona-specific landing pages, among other marketing-specific purposes. So whatever you use to accomplish those goals is A-OK.

Since you're in Rails land, any method you'd use to render HTML is probably good.

I'm a Laravel guy, and for mine I use a combination of FilamentPHP + Folio + some hand-written data models to create a very simplistic blog. It gets deployed the same as my app server since it's part of the app.

I separate mine for proper management, and housekeeping.

Landing page (website.com) is always changing (refining value proposition, marketing experiments, pivots, etc.). Also with VA/marketer in mind, easy for them to manage. I play around with both code and no-code. So it won't touch the app side of things.

And it can be the other way round as well. I might want to experiment with different middlewares or backends.

At least you don't have to change the whole thing.

I always separate them to app.*.com and *com. It makes things much easier to maintain and is a common approach.
Plus, my landing is usually Next.js on Vercel, and my app is Rails on Heroku, so I cannot really make them on the same domain.

The only downside is analytics; you have them separate. But I use Plausible, and after some tweaking, you can find a pretty good approach and see the user journey.

I don’t have strong opinions at this point, but I’m beginning to move everything under a single domain.

Im doing this because it makes more sense to have both the app and the content on the same domain to me.

Separating the app and marketing site simply means I have to write twice the amount of code - especially for the styles - when a single layer is sufficient.

It also helps if the app can be exposed to get SEO, which is generally what I do at this point.

I think separate sites makes sense if you have separate teams working on it. That way your marketing team can use a tool they are familiar with (e.g. Webflow) to create landing pages, run marketing experiments, etc. Without having to bother the engineering team working on the app.

If it's just you or a small team, I don't think it's worth the overhead of having to manage two apps, duplicating some of the styling, etc.

Separate sites makes the most sense when you don't want your app's functionality to be hindered by your marketing site's experience and vice versa.

I usually build on framer for the marketing site, then next for the app.

e.g.

brand.dev vs developer.brand.dev vs world.brand.dev haha