May 15, 2018

5 years, $3M & no investors: Everything we learned building the #1 CMS on Github (AMA)

Hey Indie Hackers! It's been 5 years since Ghost started (Backstory on the IH Podcast: https://www.indiehackers.com/podcast/007-john-onolan-of-ghost ) - and I wanted to take some time to share a bunch of lessons along the way.

I cover the most significant things which influenced our trajectory in the last 5 years in the post, which are fairly specific to the open source market -- but we also covered a ton of questions in a special edition podcast linked at the end.

That said, if there's anything you're curious about - fire away below!


  1. 15

    I'd like to share a handful of the most significant things we've learned from 5 years of building a popular open source product, profitable SaaS business, major hosting platform, productive remote team, and large community.

    The Indiehacker equivalent of slaying a dragon...

  2. 7

    Hi, John. Great job on working on Ghost so passionately!

    I will actually ask something from a different angle.

    My background is strongly related to digital marketing (growth hacking before it became a word). Me and few folks from invitation-only communities have been observing Ghost when it became viral so I have been following your journey from Kickstarter times.

    I have a question regarding one thing I am wondering - pricing. I see constantly people complaining about it - as being expensive and confusing. When you browse the web and see people looking for Wordpress alternatives, often when Ghost appears, someone comes and complains about pricing.

    I personally think that this one bit is really slowing you down. A regular consumer will rather spend $9/mo for some hosting account with Wordpress on it and worry not than spend $19 and wonder if this is what they will pay next month.

    Whats your take on it?

    1. 49

      Love this question. I almost included a section on this in the post, but I removed it because it was getting too long.

      So, firstly - you're right - our pricing slows us down. However, that's 100% intentional. Our pricing is structured specifically to slow us down.

      There are so many different angles to this. I'll try to touch on the main ones:

      Part 1: Generally speaking you should never, ever listen to feedback on pricing. Humans are NOT rational about pricing in any way. People will, in the space of 2 minutes, spend $5 on a coffee while tweeting about what bullshit it is for an iOS app to cost $0.99. People will pass over supermarket jeans for $20 and instead spend $300 on a designer brand - made in the same factory! The examples could go on pretty much until the end of time. People have no concept of what something is worth. So you should never base your pricing on opinions, you should base it on data.

      Part 2: Our data tells us that we are signing up a lot of new customers at our current price point, and we're having no trouble reaching our market. Demand exceeds supply. So people complaining about price doesn't really have any impact on us. Some people may not like it, but more people do like it. So we're growing.

      Part 3: Pricing has a huge impact on the type of user you attract. We launched at $5/month - now our base plan is $29/month. Almost without exception: $5 customers didn't value the product, inundated us with support tickets, and the economics made absolutely no sense. Conversely, $29/month customers are polite, respectful, usually have a much higher degree of technical knowledge and are really looking for a serious platform to work with - not just a consumer friendly toy.

      The best part? We've changed pricing maybe 7 or 8x and our revenue trajectory never changes. If we set our pricing at $5 we get 20 customers, if it's $10 we get 10. If it's $50 we get 2. Revenue is identical in every single case, but it's a lot easier to support 2 customers than 10.

      Part 4: Our overall philosophy on pricing, which I mentioned at the very beginning, is to try and slow our customer growth. We try to keep our total number of customers totally static at around 4,000. Why? Because the more customers you have, the more servers you need, the more ops staff you need to run them, the more support staff you need to help everyone. Sounds like a lot of work.

      So instead, every time our total number of customers starts growing too quickly - we raise prices. We don't want to build an enormous team. What's the point? We can make the same amount of revenue serving a smaller number of people with higher margins. That's always going to be better for us as a company.

      We raise prices inline with growth. If we have too many customers then the price goes up. If our customer numbers dropped too low, we would lower them to incentivise growth again - though this has never happened so far.

      Part 5: Most people are trying to capture their entire market. We aren't. We do not want to host every Ghost site in the world. That's a terrible idea. What we're trying to do is service the top 4,000 customers in the market - and that's all. As the market for Ghost grows, the ecosystem for other people to build businesses based around Ghost also grows. And when other people start making money from Ghost, you know what happens? The economics work out for everyone. The best possible thing for the health of a open source venture is to have multiple commercial ventures invested in its future.

      After all, the app is already free and open source, it costs $0 and you can host it for $10 on Digital Ocean. Ghost(Pro) is the premium offering, it's not the only offering.

      The more we raise our prices and the higher our margins, the more people we can hire to work on the open source product (not the hosting business) - which improves the free software for absolutely everyone. Not just our customers. The primary goal of Ghost(Pro) is primarily, and always will be, to fund the open source software.

      By the end of this year we'll be testing $99/month base pricing. Because the type of customers we're most interested in attracting are the type of users who are more than happy to pay $99 a month for what we do for them. In fact, for business customers charging $5/month is a huge red flag. It screams "we have no idea what we're doing, this platform is not stable, it's amateur" - having higher prices creates trust in those types of customers.

      One of the most important things you can do as a maker or a founder is study economics and understand how all of these different perspectives and systems inter-relate. It's almost never rational. One thing is constant though, throughout every product and every industry.

      Cheap != Good

      Everyone needs to decide for themselves whether they want to create a Michelin Star or a McDonalds. Both are equally valid approaches. Neither one negates the other.

      The only fallacy is the notion that building great products means lowering prices to reach more people. That's almost never, ever true.

      1. 3

        I wish I could upvote this answer SO MANY MORE TIMES THAN ONCE. SO SO MANY TIMES.

      2. 3

        Really appreciate this detailed answer. You've directly helped with my current pricing conundrum - cheers ✌🏾

      3. 2

        Great answer, and makes complete sense.

      4. 2

        This really needs to be its own post so I can share it around when people complain about my pricing decisions!

      5. 2

        murdered it, well put

      6. 1

        Thanks for the detailed answer. Did you increase prices for existing customers too? If yes, wouldn't customer loose trust, especially for early customers as you changed pricing already many times?

        1. 5

          No we always grandfather people on pricing. Always. That's the reward for being an early adopter and getting us to where we are now -- thanks for asking this, I should've mentioned this in the original reply!

          1. 1

            This makes more sense :). But then I do not understand your statement of increasing the price and a resulting decreasing number of customers. Or is this the result of churn vs. less new customers?

            BTW: is the churn stated in the article per year?

            1. 1

              Customer churn is unaffected by pricing changes. Whether new customers pay $10 this month or $100 this month has no bearing on existing customers.

              So if you churn 10 customers paying $10, and add 5 customers paying $50, then total customers went down by 5 and MRR went up by $150. That's exactly how our economics pan out.

              Here's our MRR for the last year: https://www.dropbox.com/s/cj8n1l2xfr6d6ww/Screenshot 2018-05-16 13.12.42.png?dl=0

              and here's our total customers: https://www.dropbox.com/s/4p9qd3q44bap1q1/Screenshot 2018-05-16 13.14.05.png?dl=0

              So compared to 1 year ago we have:

              Revenue: +$208,800 ARR more than before

              Customers: -19 less than before

      7. 1

        Why wait on charging $99/mo. ?

        Why not charge thatbstartikg tomorrow?

        1. 1

          Because changing prices requires a lot of engineering work, and our engineers are in the middle of other projects which are more important than changing our pricing.

          1. 1

            Firstly, thank you SO MUCH for your incredibly detailed and informative answer to this question! We are humbled by it as a community.

            Secondly, I'm curious why/how changing prices requires so much engineering work? (You might guess by this question I'm not as far along on my journey and haven't had the quality problem of having so many customers I need to raise prices just yet, but I'm always deeply curious about things)

            1. 1

              No problem! Changing pricing in SaaS is always kind of an engineering pain. The basics are easy: You create some new plans in Stripe, update your pricing page, and update the plan choices for new customers. All that takes under an hour. Then come the edge cases:

              • An existing customer wants to change plans. What do they see in the plan change dropdown? Old? New? Both? A mix of their old (current) plan and new (updated) plans?

              • Someone's payment fails and their account expires. Now they're trying to reactivate their account - but according to stripe they have no subscription. How do they select a plan to reactivate? Which plans do they see?

              • What about people who are currently on-trial when the new pricing is rolled out? They signed up under the impression it would cost X but now it costs Y. That's not cool. So how do you distinguish "old pricing" from "new pricing" ? And how does that scale when you have 4 or 5 different levels of old pricing? And each level of old pricing has 8 plans, both monthly and yearly?

              Solving these things mostly takes a clusterfuck of engineering, and you still hit edge cases constantly.

              One thing that makes all this stuff a LOT easier is Chargebee.com - which we didn't use - and I wish we did. VERY good product. Definitely worth the money.

              1. 1

                I used to work in enterprise billing on electricity/gas/pay tv. Oh the edges I have seen! Thanks for this recommendation!

  3. 3

    Just popping my head in to say I love this post ;)

  4. 3

    Hey John, this is a great recap!

    I love Ghost. I tried it out years ago (in the Svbtle days) and I'm so proud of what you and your team have been able to do with it. I even gave a little talk on it for one of my senior classes at university. (I loved your sustainable approach to building the company.)

    Good tutorials and documentation is a huge differentiator, and I'm glad you also see the need for it. In my experience, better docs can also lead to less support and more time to focus on the more fun/creative sides of the business. :)

    1. 2

      Hey Mark! Wow that's awesome to hear, thanks so much! Tutorials and docs have def. been neglected for a while, and I fully agree they can lead to many good things. Glad to finally be getting around to doing them properly :) Now we just need to get StartYourBlog.co on board, right?? 💃🏻

      1. 2

        This is good to hear! I was actually taking a look at the docs last week and came across a section that was a bit out of date - so I appreciate the effort being put into it!

        1. 1

          If you know anyone who's particularly good at writing about development and teaching others, we're trying to hire for this position right now :) https://blog.ghost.org/developer-marketing/

      2. 2

        I've been promoting StartYourBlog with some personal connections in the food blogging space, so the vast majority of our traffic comes from food bloggers who need recipe plugins/large recipe-based theme selections/cheap pricing/etc.

        That being said, I think making a separate website for Ghost tutorials sounds really fun! I'm going to look into this.

        1. 1

          Haha, I was mostly teasing - but that's cool!

  5. 3

    Absolutely incredible story!

    I have a few questions:

    1. What were your biggest frustrations running a remote team and how did you overcome them? -- I am also trying to manage a remote team for my current business but I find it incredibly challenging.

    2. How did you know which customers were ideal to target for Ghost? Did you talk a lot to existing customers? Did you cold email companies?

    3. How do you plan on making the right decisions to achieve your goals for Ghost? From your blog it seems you are onto some pretty ambitious things (building the future of publishing), do you use any mental models? What did you feel was the best way for you to come up for a strategy for Ghost? Talking to people? Listening to podcasts? Or just shipping stuff for users?

    Thanks a lot!

    1. 3

      Great questions!

      1. Kind of touched on this in post. Biggest problem is what I generally refer to as "no shared pizza". When a project is behind once in a while, and everyone stays late to get it done, and you're all in the same physical space sharing an experience. At a certain point someone orders pizza. And people bond over that sense of being stuck in a hard place, but at least being stuck in it together. It's near impossible for those types of moments to occur in a remote team spread across many miles and many timezones. I don't necessarily have a good solution to this - except to say that doing regular retreats together definitely helps.

      2. We don't really target anyone. We're pretty fortunate that Ghost has always been an idea which spread pretty rapidly and organically.

      3. Before Ghost I worked as a core contributor to WordPress and a freelance developer building blogs for many, many different people. When you work in a particular space for long enough, you get to know it very well. You know, the old "10 years to overnight success" thing? It's a lot like fitness, in a way. There are all these mental models and 6 minute ab programs which claim to offer shortcuts. In reality though what's behind success most of the time is a lot of unglamorous hard work over a sustained period of time.

      1. 6

        I wanted to give some feedback on "no shared pizza". I've worked on remote teams and had friends who are doing the same thing.

        • I think, first, you should be cognizant of the types of people who are working for you, and what each one of them personally seeks in periods of hard work. I'm an introverted (INTJ) developer and have never had a problem with "no shared pizza". Although I know others who are more extroverted and have a terrible time with it.

        • On stressful days (like launching a new feature), you can leave a Google Hangout open for people to come and go as they please. More often than not, people will stop in for a few hours, talk a bit, and work together. It's fun to read feedback from your customers as it rolls in, and it gets everyone cheering.

        • Digital happy hours are nice. During busy periods, PayPal everyone some money for some food and drinks. Make it a game – post pictures of your food in Slack, and encourage others to do the same.

        • Be a good listener. My girlfriend mentioned that her cat got sick, and her (remote) boss sent us a get-well-soon card along with a little care package. Her whole team wished us well. It meant a lot and we still talk about it.

        • Although it's old fashioned, handwritten thank you notes go a long way. If someone put in a huge amount of effort, take the time out of your day to thank them for contributing to the cause.

        These little things help build a community and make it feel like you're part of a bigger effort. It's not an immediate thing like shared pizza, but over time it will have the same effect.

        1. 1

          Hey Mark, thanks for sharing some great ideas here - I'm sure these will be helpful for lots of people! I would definitely agree that these are all good things to try out (we've done all of them) - but in practice nothing replaces the IRL in quite the same way. Little gimmicks are fun, but they rarely stick. That's why I'm a big advocate of putting in the effort of organising real team trips and getting everyone together. It's not a gimmick. It's the real deal. And the impact on team dynamic, without fail, is fantastic :)

  6. 1

    I love your insights on pricing but are you guys running on physical servers?? Why not AWS?

    1. 1

      No we aren't running on physical servers. Not sure where you got that from

  7. 1

    Are you still based in Singapore? How's that working for you?

    What's your favourite place to work remotely from?

    Great to see a company as open succeeding!

    1. 1

      Company is based in Singapore - whole team is remote. So far this year I've worked from Indonesia, Austria, The UK, South Africa, Norway, and currently: Canada :)

  8. 1

    Hi, John. I first heard about you when you did an interview on the Indie Hackers podcast, and found myself agreeing with your point of view.

    What have you found to be the most effective way to hire talented engineers for a remote business? We have just reached the point where we need to scale and bring onboard an additional engineer (it's just me and my co-founder right now), but as we have never crossed that point before we are unsure about the best ways to attract the right individual, or where best to look.

    1. 1

      This is really hard, and even more critical in the early days.

      I think the best thing you can do to find that #1 hire is usually to get to as many meetups as possible, go offline, network, and find the right person for your current stage.

      It's very different for hiring further down the line. At that point what will attract the best candidates is an aggregate of building a strong brand which they would feel proud to represent, having an interesting product which the would want to work on, and having a great working environment which is worth them investing a big chuck of their lives in.

      Being remote usually means you'll get too many applications, not too few, but the red flag to watch out for is that the majority of remote applicants skew toward being very junior. Remote work is VERY attractive to younger people who are at an early stage in their career. It's less impressive to seasoned, experienced developers who have seen it all before -- and those are the people you really want to attract.

      If I could give only one piece of hiring advice for small startups it would be: Hire for experience, not for potential. You don't have the resources to train someone to meet their potential. You need someone who is going to help you get off the ground with existing experience.*

      *Disclaimer: Does not apply to every business, industry, sector, whatever. Just my personal experience. People with experience are very very valuable to early stage of a company's life, but the majority of applications you get will be from people with less experience. So you really have to hunt for it.

      1. 1

        Thank you for taking the time to write a detailed reply. Hiring for experience and not potential makes a lot of sense to me, we'll definitely focus on that.

        Once we do find that #1 hire, have you learned any important lessons about keeping an employee motivated and passionate about his work? Your meetups seem to be a great idea, and that's an idea we'll definitely copy.

        1. 1

          Hire the best people you can find, give them a great salary, interesting work, and treat them with the same respect as if you worked for them. That's what motivates people in my experience :)

          1. 1

            Since this will be our #1 hire, what have you found to be the range of a great salary for a remote software engineer? Not entry level, someone who's good and has a lot of experience.

            1. 1

              Depends on lots and lots of factors. Have a look at Buffer's open salaries spreadsheet as a good starting point. I'd say they pay pretty much top of market, though.

              1. 1

                Thanks! Very interesting. If anyone else is interested I'll save them the Googling: https://open.buffer.com/transparent-salaries/

  9. 1

    Great work with Ghost! Your accomplishments are definitely something to be proud of, especially as you're doing things very differently compared to startup world.

    Ok, so have a question of my own. As I'm building a remote first company also, I'd like to know how you handle things like contracts (for example, do you hire as contractors or full time salaried employees?), salaries and benefits, with you being registered in Singapore and your staff being everywhere?

    1. 1

      Hey! All remote companies basically do this the same way (we mostly all use the same contract, too - which gets passed around between founders). Everyone is set up as a self-employed independent contractor on a retainer contract in their respective countries. We contribute to costs to help people manage any associated hassle/cost - that's about it.

      Larger remote companies (eg. Automattic) go a step further and incorporate a subsidiary business in any country where they enough team members to justify it being worthwhile (like in Ireland). This is a much more complex setup, but makes a lot of sense when the size of the team warrants it.

      1. 1

        Would you mind passing the contract along to us? We will probably need to scale in the next 6 weeks, and want to bring on board 1-2 remote engineers. Right now it's just me and my co-founder.

      2. 1

        Thanks for this, always wondered how it was handled.

  10. 1

    I'm more on the dev side and am interested in this part:

    "Our core team tends to do the "real work" in private issues nowadays. The signal to noise ratio is just too overwhelming."

    Did Ghost move to a different tool/private issue tracking to move quicker? What would kind of actions would you want (or wish) Github to implement to help solve that problem of not being as good of a collaboration tool?

    1. 2

      We use a secondary private repository with a closed set of issues for a lot of things. As for how to fix it, I dunno man, we have enough of our own product problems. I don't know how to fix Github, all I know is that - at least when it comes to OSS - it's very broken. I don't think it's viable to make suggestions at a micro level - it needs a macro approach from Github themselves.

      1. 2

        I hear ya, I've heard similar stories from other OSS maintainers that the ecosystem can be toxic sometimes. Thanks for sharing!

      2. 1

        We have made good experience with setting up a different forum software (discourse is a no-brainer) and replying very strictly to all non-issues like usage questions or discussion with "Please use our forum". This way 1. only interested people stay and others learn that we close unrelated issues fast or even remove hijacking comments and 2. github issues will be not be too long and 3. I really prefer discourse over github issues due to many things like less Emails, desktop notifications, moderation (why can't we remove github issues!?!?) and more

        1. 1

          Very seriously considering this atm - Jeff was advocating for it yesterday, and we already have a Discourse install. Might give it a try :)