I've built a few products before and everytime I was took the following steps:
- Start the app/product.
- Shit, I need to make a marketing site too.
- What about the blog?
- Maybe I need a coming soon page first (if the product's development isn't going to take under a month).
- Now I have an app/marketing site/blog all in one. Maybe I should split it up?
That's all probably familiar to you if you've ever launched anything.
In the end, I decided to split up the app and the marketing side of things. I figured that while there was the obvious overlap - that it was all stemming from the same product - they both served completely different purposes and there weren't a lot of benefits to bundling them into a single site.
I first needed to choose a subdomain for the app. If metorik.com would be the main site trying to sell people on the product and where the blog would live, the actual app needed to live elsewhere. I was very inspired by the approach Jonnie Hallman took for his own app, Cushion. With Cushion, he chose my as the subdomain, which makes sense. Cushion is an app for freelancers; individuals. I considered doing the same, but while Metorik does cater for individuals, I place a heavy focus on the benefits it provides to teams (unlimited team members, integration with support systems, etc.).
As you can see, I went for app.metorik.com. It made the most sense, both to me and to users (quite a few other SaaS apps have made the same choice).
I didn't want to delay launching Metorik for weeks due to a marketing site. I definitely see the value in it, but I also see the value in moving fast and putting the product first. I threw together a single home page with a summary of Metorik's core features, a blog to host WooCommerce & Metorik-related content, a couple standard pages like 'pricing' and 'about us',
Update - August 2018: I rebuilt the marketing site using Statamic, an incredible modern CMS perfect for a site like this. I'll write about it in the future.
For building metorik.com, I went with Laravel, but WordPress would have worked too. I felt like Laravel gave me a bit more control over what I wanted to create and would allow me to create it faster. I used Vue.js for the UI but didn't really need it, as there isn't much interactivity. It did help me make the UX a bit smoother and of course, it's quite fun to use.
I used a great service called Prismic to handle a lot of the content on the site. It gives you a UI and place to create content from and provides an API to get the data out of it. This made creating the primary blog easier, but also provides me with the flexibility to use it for various other parts of the site, like the very part of the site you're reading on now (Metorik's Behind the Scenes blog). A better option may have been to use the WordPress REST API, but I didn't want to the baggage of having to maintain and host another site and wanted to get up and running as quickly as possible.
I did run into a couple issues along the way. The biggest hiccup was with SEO. The blog's content was being loaded dynamically - including both what the actual content outputted and the title/description/meta in the head. This made it difficult for search engines and social media sites alike to scrape the content for outputting previews.
I tried some of the solutions available, like Prerender, but could never quite get it to work. I ended up changing it from a single page application with JS routing to use standard PHP routing, so it wasn't as smooth as before, but the HTML was rendered on each page load - thus avoiding the meta issue.
I made sure from the start that I was tracking all activity on the site, so I was able to see how long it took for a user to go from visiting the site to signing up, or what path they took (read a blog post on conversion rates, viewed the pricing, then signed up?). I went with Mixpanel for this, as it was for my needs - free, familiar and easy to setup.
It's only natural to ask questions. Often while I'm browsing an app's site, I find myself faced with a question or two that I need to spend the next 5 minutes trying to answer by looking around their site.
I wanted to make signing up to Metorik as smooth as possible, so I added live chat to the site. I'm not always around to speak with users, but in those situations, they're asked for their name and email so I can get back to them later.
I use Chatra for this (affiliate link) and I love it. It does one thing truly well - live chat - integrating seemlessly with all of the other services I use to run Metorik.
This site is far from what I want it to be, and I have a comprehensive list of features and ideas to get through as time goes on. For example, this behind the scenes blog itself was only added a couple weeks ago, months after the site originally went alive.
I've started work on feature pages, like this one about Digests, with many more planned. I also plan to write more on the general Metorik blog, elaborating on certain features and ways Metorik provides value to users, like my article about combining Google Analytics & WooCommerce. Following that, I hope to get some customer stories and case studies published. Clearly, the focus is on content. Why? Well, content is king.