Marketing Site: Integrated or Stand alone?

Discussions
#1

Hi all,

This is a bit of an implementation detail, but I find myself kicking different approaches back and forth. I have my product, a Django app. I’m currently design/writing the marketing site, and am debating whether I should implement the marketing site as static pages (via Pelican) or integrate it as a part of my Django app (using Mezzanine or something). There are pros and cons to each approach:

Pros for static site

  • Very fast for users
  • Secure and simple to maintain.
  • Completely de-coupled from app, can launch now without having to make a separate deployment

Cons for static site

  • A/B testing could prove tricky
  • Anything else dynamic would also be an issue

Pros/cons for the integrated site are pretty much the reverse of those for the static site.

What are you guys doing? Do you view your marketing site as a totally separate app, or do you bake it into your main product? Feels like a trivial thing, but I’d like to get things right. Looking forward to hearing what you guys have to say.

#2

For Rallypoint we went with the stand alone approach, however the marketing site is not completely static. The reason comes from the world of programming and is just basically a matter of separation of concerns. We don’t ever want to have the risk of breaking the app because of some marketing site changes, or the other way around. They’re even hosted on two different platforms as well (and even written in two different programming languages, Javascript (Node) / PHP), just to make sure that when the one goes down, the other isn’t affected. Especially once you start to do more than just marketing, i.e. showing the status of your app, this is quite advantageous. Any communication between the two will require an API, but luckily we already had those in place by design :smile:

#3

@JaapRood Thanks for sharing your insight. Good to see how you are handling this and why. I’m interested on what others say.

#4

When they are at the splash page stage I use just static pages. But once I start to have a real product I use Django. I want control and if it’s template driven I might use of the static generators.

#5

I actually have gone with both approaches, but overall, I have found that if the Marketing site has access to the application database (through signups or whatever) you will have to address many of the same vulnerabilities that you will have with a fully integrated solution.

Therefore I usually will go with a integrated solution where the marketing site is in its own module/namespace. This allows me to keep everything under one roof, but if I need to sub-contract or give one part of the app to a developer I can just give them access to “Marketing”.

#6

I vote for standalone.

Remember, just because the marketing site is standalone doesn’t mean it has to be static, per se. You can make it dynamic using WordPress or some other CMS that’s decoupled from your Django app.

That said, my marketing site is purely static. I haven’t run into any issues. A/B testing is easy with something like Visual Website Optimizer, which works beautifully with static sites.

The only thing that is a bit of a pain is updating the header and footer manually on every page when I make a change. But that makes me want to keep my site small, which is a good thing. I’ve considered using server-side includes to work around this, but it hasn’t been a bid deal (find and replace is nice).

#7

Stand alone all the way, hosted on different infrastructures. Our marketing site was under DoS a couple of years ago, having in run on the same infrastructure would have brought down everything. If you don’t plan on doing regular updates to the content or you don’t have somone non-technical doing updates i’d go with a static site.
Why would A/B testing be difficult with static?

#8

Simple A/B testing (i.e. button colors, small bits of copy) should be easy enough to handle on a static site, but testing major changes (such as entirely different versions of the page, different design, different copy) would be trickier.

However, I’ve decided I’m going to push my static splash page online here shortly, and worry about switching to a CMS type system (on separate infrastructure) later if I need to. Thanks for everyone’s advice!

#9

There is a bit of a different solution as well. Have the same codebase, and just DNS and have routing rules. Maintainable, shared DB infrastructure for stats and sign ups.

I lied a bit saying that everything is shared with my service. I do handle my blog and CMS on a separate DB connection from my application - though it’s on the same instance… I would suggest this separation of concerns: there’s no reason that refreshing the blog article you accidentally deleted should risk client data when you do DB backups.

#10

If you use something like Visual Website Optimizer, testing different versions (or designs) of the same page is simple. You just make index2.html and tell VWO to do a split URL test. It really makes A/B testing on a static site a complete non-issue.

There are non-A/B testing reasons to use a CMS, though.

#11

Just to throw my 2¢, every project that I’ve been a part of has had a separate CMS-driven marketing site. I’ve grown fond of ExpressionEngine, but any will do. I like how a CMS is going to have everything you would ever want for a marketing site, in the form of plugins, so I don’t really have to think much about the implementation of the marketing blog, email signup services, contact form, etc, most are just plug-n-play. The branding, ux, and strategy of the marketing site is what matters, not so much the back-end programming, so I don’t want to spend any more time on it than is necessary…on to the good stuff!