Ok!

But first, a story about why we turned it off in the first place.

When Railway launched you could pay us $20 for “Unlimited Compute.”

We grew like wildfire, but it was funny-money ZIRPy growth.

At times we were giving away more than $1000 of compute for $20. At the worst point, we were losing $16 for every $1 of topline revenue.

We did margin-negative computing before it was cool, and it was silly.

Instead of running our business into the ground, we deleted the free plan, which nuked our growth.

We then went to work building durable product-market fit, restoring growth, and inverting our negative margins. That work culminated earlier this year when we lowered prices.

Today we have the pleasure of announcing that we’ve flipped the “free compute” switch back on.

New users now get $5 for the first 30 days to try Railway for free.

After $5 or 30 days, we will fund your account with $1 of non-rollover credits each month. This is enough to run a small app for free in perpetuity.

More details are available here.

Let’s take a question from the audience:

Q. So you pulled off a “mid-air” rebuild of your product? How did that work?

A. Good question! Let’s tell that story.

When we deleted our free plan, we cratered our short-term growth prospects to create a real, healthy business.

Our goal was to turn off the free plan until we had actual product market fit, so we wouldn’t spend the rest of the decade playing “free compute ponzi” with customers and VCs.

And although the original free plan really was a cash incinerator, it also bought us a good amount of attention in the market as a deployment option. So giving away free compute bought us something very important — a foot in the door with thousands of users.

First lesson: After you develop a compelling MVP, use investor cash to buy a small piece of the market … that’s what it’s for.

One reason we could afford a mid-air rebuild is that the early users we attracted stuck around.

Although we subsidized the early attention we received in the market, we earned a very good early user base that gave us thousands of lines of product feedback and thousands of referrals to their friends.

This wouldn’t have been possible without the “spin up a database before you can dismiss this toast” MVP onboarding experience. It was so good people had to tell their friends about it.

Second lesson: Nothing replaces a really good first time user experience (not even giving away free compute).

After we cauterized the original free plan, we saw that our business was in jeopardy on three axes:

• Margins — we wanted a durable business
• Reliability — it wasn’t bulletproof
• Support — we were losing the plot (which is to keep talking to users)

We originally bootstrapped Railway on top of Google Cloud Platform, which allowed us to build our initial product, but we soon discovered we couldn’t guarantee the product when you build a cloud on another cloud.

We could have continued to wrap GCP and find new ways to cost-plus the hell out of everything we were shipping, but that would’ve been like AirBnb-ing out the hotel room we were paying for. Our original ambition for this company is to “deploy anything, instantly” and that goal drives us to solve most of our upstream dependency issues through vertical integration.

When you build a company of true-blue technologists, you find yourself sprinting toward these hard technological problems every time because that’s the way you build advantages over your competition.

Anyway, the margin story changed overnight once we started racking and stacking our own servers and completed the cutover to Railway Metal.

The reliability piece had a similar outcome. By owning the hardware stack, we were able to escape the persistent upstream issues that our cloud provider was passing through to us.

We built our own orchestrator, our own compute stack, our own edge network … basically our own everything. This is what lets us be cheap and fast but also great.

This wouldn’t be possible off the shelf and it wasn’t possible on GCP, which is another reason why we exited the cloud in the first place.

For support, we underwent a similar revolution. We built an in-house support solution called Central Station that is part forum, part helpdesk, part roadmap, and part bounty payout system.

The support machine allowed us to get back to users really fast. It let us listen to customers and build what they need quickly. It has bidirectional integrations with Slack and Discord and serves as the nerve center for our customer service and product development work, may the two forever be intertwined.

There’s a much longer story here about why we didn’t use off-the-shelf pieces for support, but that’s a story for another time.

That brings us to our third lesson.

Third lesson: You’re a technology company, so make big bets on your own technology … that’s also what the investor cash is for.

This last lesson is the most important. We bet on ourselves repeatedly:

• We bet on our ability to deliver an initial “aha” MVP product experience
• We bet on our ability to exit the cloud
• We bet on our ability to build an orchestrator and compute stack from scratch
• We bet on our ability to listen to user needs and get back to them lightning fast

… and as a result we’re now able to turn the free plan back on.

Today we’ve built a product that users love, pay for, and share with their friends.

In addition to these deployment stats, top of funnel and NDR are up and to the right. Topline and bottom line revenue are up and to the right.

To us that means we have product-market fit and it’s durable this time.

And to you, that means the $5 free compute deal is back.

Sign up here to get started.