From Jekyll to Ghost

Inside Flybase

We've just migrated this blog from Jekyll where it's been running on Github Pages for the past two years to Ghost.

We still love Jekyll, but we really like the simplicity, writing experience and speed that Ghost offers

It's been an interesting move, and not much has changed for readers, only for us, the editors.

First of all, we're using the same modified version of Ghost that we use for Coded Geekery, including the front matter app that we use there, this lets us keep our posts formatted mostly the same way they were in Jekyll, complete with the links in the front matter.

The links stayed the same, so no 301 (or 302) redirects were needed.

We were already storing our images on S3 so that never changed anything either.

The biggest piece was moving all our markdown files into a ghost import file. We started with the node-jekyll-to-ghost export tool, and modified it to keep the front matter in the markdown and to include support for tags, then we imported the posts into Ghost, and modified our template to work with Ghost / handlebars vs the Jekyll / liquid format previously used.

As the one who does most of the writing, I like this move. It gives us an actual CMS to use for writing and will help improve our work flow and get more articles out to you.

10 weeks of YC Startup School Founder Track

On Startups, Inside Flybase

We just spent the last 10 weeks taking part in the Y Combinator Startup School Founder Track online course (aka SUS17), the end of which saw Y Combinator hosting the world's largest startup demo day ever.

Here are some stats:

  • 13,321 startups from 141 countries applied to Startup School
  • 2,820 were selected
  • 1,584 graduated
  • 797 presented online at demo day

The experience was very positive, we came away with lessons from some of the better known people in the startup world and made contacts with several people all over.

What did the Startup School Founder Track consist of?

Startup School consisted of several pieces that came together great.

Generally, the course was very _hands off_, you had your video lessons to watch as you went, your chat system for networking and asking questions as needed, and the mentors and weekly checkins and office hours.

Additionally, there was no pressure to take part in “Presentation Day” or to apply for YC funding.

If you wanted, the opportunities were there, but ultimately the choice was yours.

Generally, the entire focus on Startup School was simply: continue to build and grow your product.

1. Video Lectures

The weekly video lectures were great, they hit a wide variety of topics around startups and building a business:

  • Week 1:
    • How and Why to Start A Startup By Sam Altman (YC), Dustin Moskovitz (Asana)
    • Startup Mechanics By Kirsty Nathoo (YC)
  • Week 2:
    • How to Get Ideas and How to Measure By Stewart Butterfield (Slack) and Adam D’Angelo (Quora)
  • Week 3:
    • How to Build a Great Product I By Emmett Shear (Twitch) Steve Huffman (Reddit), Michael Seibel (YC)
    • How to Build a Great Product II By Aaron Levie (Box)
  • Week 4:
    • How to Build a Great Product III By Tracy Young (PlanGrid), Jason Lemkin (SaaStr), Harry Zhang (Lob), Solomon Hykes (Docker)
    • How to Build a Great Product IV By Jan Koum (WhatsApp)
  • Week 5:
    • How to Get Users and Grow By Alex Schultz (Facebook)
    • Week 6:
    • How to Invent the Future I & II By Alan Kay
  • Week 7:
    • How to Find Product Market Fit By Peter Reinhardt (Segment) How to Think About PR By Sharon Pope (YC)
  • Week 8:
    • Diversity + Inclusion at Early Stage Startups By Kat Manalac (YC)
  • Week 9:
    • How to Build and Manage Teams By Vinod Khosla (Khosla Ventures)
  • Week 10:
    • How to Raise Money, and How to Succeed Long-Term By Ali Rowghani (YC) Jess Lee (Sequoia), Aaron Harris (YC)

Obviously, these can be more useful depending on where your startups is right now, but they hit a wide variety of topics for that purpose.

2. Mentoring

Each Startup was added to a group of about 20 to 30 and assigned to a dedicated mentor within the network of YC alums.

Ours was Anand Kulkarni, and he did a great job hosting the weekly video call & making time available in 1-on-1 office hours.

Most of these mentors are themselves actively building their second or third startup. so it's refreshing to hear your mentor also talk about what they are encountering as they grow their startup themselves.

3. Groups

The groups were nice, they consisted of about 20-30 startups from various stages and verticals, from early stage, late stage, solo founders, etc.

I found the varying states of the startups to be nice, as the wide variety of experiences gave you a wider audience and it was nice to bounce ideas and get answers based on where your group members were at this point in time.

4. Office Hours

There was a twice weekly video call with about 20 startups and your mentor but other than that the course was at your pace.

On top of that, there were also 1 on 1 office hours with your mentor.

5. Weekly status updates

Each startup was expected to report a weekly metric in an online tool on the startup school website. For most startups this was either active users or revenue.

Defining and tracking that weekly metric was extremely useful.

There’s a whole lot of value in having a single KPI to keep you accountable & focused. We've been actually using Basecamp for daily and weekly checkins for the past several months already.

Since we've been launched for over two years, finding the right metric was easy, but some others found it harder to work with.

6. Networking

With a chat community of over 4,000 people, it was interesting to see everyone pitch in and build a nice active community that's continued even after the school has finished.

7. Deals

Each startup was able to apply for credits from Amazon and Google, and if you asked through the YC network, ex-YC alums were happy to give you deals on their products.

8. What happens in Startup School stays in Startup School.

There was a very clear agreement to respect each other’s privacy & at no point were we pressured to talk publicly about our startup. This made it possible to talk openly during office hours & contributed to the long-term value of the Startup School network.

Healthchecks and Heartbearts


Most web apps set up a healthcheck, it's usually an endpoint that tells you that your databases are up, and websites are up.

I've even got a repo ready to go that I install on servers and enable quickly, based on another middleware healthcheck but with a few changes to make it easier to use, and with endpoints already in place for mongodb, redis and elasticsearch if needed.

We use healthchecks heavily here at Flybase to monitor all our services and let us know in case of any issues.

These work great, if one thing goes down then your monitor will alert you.

But what about all those third party APIs your app uses?

Or if you use a microservice architecture, how do you ensure everything continues working as expected?

This is where heartbeats come into play, and are a slightly different take on healthchecks.

For example, let's look at an e-commerce site that sells spoons:

  1. User picks an item to purchase
  2. Item goes to cart
  3. User logs in (or signs up) and pays for item
  4. System registers purchase, and signals warehouse and shipping company about shipment
  5. Shipment gets picked up
  6. Users gets his new spoon.

So there are several APIs involved here, we have the payment processor (maybe Stripe), we have the shipping processor, we also have internal APIs such as user management, inventory control, order management and notifications.

In this scenario, let's say the shipping processor never gets notified? or the inventory control doesn't adapt the numbers and we end up showing more in stock than there actually is?

Nobody likes ordering a sold out item thinking they'll have it in a week, and actually waiting a month or two.

Or worse, ordering an item and the shipping system never gets the pick up request.

So we set up a heartbeat. Which is a simulated order that is run every so many hours.

In this case, we can create a special item that never gets seen anywhere else, and a user account that is called heartbeat.

Then you would have your heartbeat user walk through the order system using automated scripts and if any errors occur, for example an email never arrives in the heartbeat box, or the order page never shows sucessful order.

You could add some extra checks to make sure the db updates and check responses back from the various end points, heartbeats are allowed to be slower than the actual order process as they are checking everything involved, but the end result...

You get a snapshot of your system every so many hours and can get a heads up in cases of any issues.

Also, most important, perform clean ups once done, this is also why you should use a dedicated user (or even users).

The End?

This wasn't a code heavy post, I shared a repo I use on several projects for healthchecks and mostly explained ways to do a heartbeat.

It's hard to code a demo heartbeat as the code is so different based on projects.

So all I can recommend in building a heartbeat is monitoring every step you can. It's the heartbeat of your app and an unhealthy heartbeat is very dangerous.

This post was originally published on Coded Geekery, my blog on various topics from cooking to work life balance.

Scaling Growth


Gustaf Alstromer, YC’s newest Partner (formerly product lead for Growth at Airbnb) joined a panel with Ed Baker, (former Head of Growth at Uber), to share tips on growth experiments and team dynamics at a scaling company.

Topics discussed:

What is a north star metric for growth? If you talk to anyone on the growth team, and ask them, “what number are we trying to grow.” They’d be able to say that number. And if they aren’t working on something that could grow that number, they’re probably working on the wrong thing. At the time Ed was at Facebook, retention and user engagement contributed even more to the north star metric (MAUs) than new user acquisition.

Paid acquisition can further accelerate growth: Growth isn’t only about organic growth — especially for companies who charge for their products. In a competitive market, it can make sense to pay to acquire up to the potential value of a customer if it’s important to grow quickly (this was true for Uber, who had to beat competition to market).

Is there a channel with particular upside right now? Nothing beats building a great product. Beyond that, most great companies get really good at one specific channel — so figure out what your product is best suited for and double down on it (make sure it’s a channel that can scale — meaning that channel potentially has 100s of millions of people coming through it).

You should be seeing things that are counterintuitive in your data: If you aren’t, you probably aren’t experimenting enough.

A little wording change can matter: As an example, Facebook saw low growth in Japan, and went and talked to people in the local market and found that people felt it was rude to “invite” friends to Facebook. They found through a growth experiment that changing the wording to “announce to your friends you’re on Facebook” (instead of “invite”), they immediately began to see growth there.

Make it easy for users: The simplest thing you could do today to help strengthen user data is to not log people out. This practice is bad for growth, and Amazon is a great example of doing it right.

Eventually, the whole company is a growth team: At Airbnb today, every big team uses data to fuel decisions. That’s the goal. The growth team should not only be collaborating across the business, but you should start to see most areas join in on a cadence of experimentation.

Definitely click the link and watch this video, it's great, and covers a lot in the 34 minutes.

Last Page 2 of 48 Next