When we release a SaaS web application, such as IntuitionHQ, it’s inevitable that there will be two parts that make it up. The main part is the application itself. The second part is the marketing site that goes with it. The marketing site includes the content, and usually a way to sign up. It normally requires some integration with the application.
We choose Radiant for our CMS when working on internal projects. The reason we like it is for it’s simplicity and power. In this post I’ll go through the different ways we’ve experimented with to integrate our SaaS applications with Radiant based websites.
1. Completely separate
The first scenario is the simplest. We just keep the website and application completely separated. When the user clicks to sign up they are taken to a form running in the application.
Example: www.sonarhq.com
Pros
- Very easy.
Cons
- We have to make a sign up form somewhere. In this scenario it’s easier to do that on the application side, but that means getting the design of that page to match with the website. Doing it this way means that you can’t really have the sign up form on the homepage.
- You can’t edit the sign up page content through the CMS.
- Having two separate administrative interfaces, one for editing the CMS and one for the SaaS application. This is okay, but it involves more work setting up. For an application where users sign up for an account it also means having that extra admin layer, which is a bit confusing.
2. Completely integrated
Radiant’s extension system is very powerful. You can actually write a whole Rails application as an extension. This makes it really easy to integrate both the public side and the administrative side of the site.
For some applications this method works very well and reduces complexity.
This recent blog post by Jim Gay, the lead developer of Radiant addresses some of the issues with integrated applications.
Example: www.smartmove.co.nz
Pros
- It’s reasonably easy to set up.
- Everything is completely integrated. You can have the sign up form anywhere you want. You can create Radiant tags to integrate with editable content. You can add tabs to Radiant’s admin interface for your own admin pages.
Cons
- You have to battle with a slightly different setup. It’s not too big a of a deal, but it does have an effect. For example, I’ve found it harder to get the specs running.
- You’re effectively tied to the version of Rails used by Radiant. You can’t upgrade Rails without updating Radiant, and you can’t update Radiant without updating Rails.
- Radiant has built in user and role models, which you have to work around to avoid conflicting with the way you want to set up models for your own application.
- You have to careful that you don’t end up customising Radiant. If that happens you might find yourself in the position of never being able to upgrade it, and being stuck with that version forever.
3. Admin API and Radiant extension
With this method your application exposes a locked down administrative API. A simple Radiant extension uses the API to allow sign ups and perform administration.
While this is a more complex solution, it really provides the best of completely separate and completely integrated. You can maintain different Rails and Radiant upgrade paths, but you can still have all of the administration happen in the Radiant backend. You can even build it out to do other interesting things. For example, having a Radiant website that administrates several applications.
Example: www.intuitionhq.com
Pros
- Separate codebases.
- Single place to administrate both applications.
- Sign up form can be placed anywhere on the marketing site.
Cons
- Complicated to setup.
- You must consider the security of your administrative API.
Conclusion
I would avoid having a completely separate website and SaaS application again – it seemed like a good idea, but ended up not working that well.
Integrating with Radiant is a really nice solution. I would consider it for any application that fits the following:
- Can and will be developed very rapidly
- User/Role system fits in with the one provided by Radiant
For all other cases I would expose an admin API and write a simple Radiant extension around it. This seems to be the most future proof, while not taking away any flexibilty. I’d be interested to hear how other people integrate a marketing site with their SaaS applications.
I’ve been meaning to write a post similar to this for a while. Soon enough, though, there will be a 4th option which will allow you to plug radiant into your app. And coming even sooner, you’ll be able to pull out the entire user system, or layout system, or etc. and provide your own implementation.
.-= Jim Gay´s last blog – Radiant projects and Rails applications =-.
[...] This post was mentioned on Twitter by Boost New Media, jemmyw and SonarHQ, IntuitionHQ. IntuitionHQ said: RT @boostnewmedia Custom application and CMS integration http://bit.ly/byNTzi #radiant #rails #ruby [...]