It was a Sinatra app for a while, and later I switched to Ruby on Rails 3. As the years went on I kept the codebase up-to-date by upgrading anytime a major new Rails version came out. (Running on Ruby on Rails 7 now with the Hotwire goodness.)

I played with the idea of moving away from Heroku for a while. For a few reasons. The most concrete reason being costs, but I also felt like their product development stalled the last few years and although I’ve had some good experiences with their support team, overall the company seemed more interested in serving huge enterprise clients rather than a startup like my own.

At one point one of their sales reps called me (still not sure how they got my phone number) and repeatedly emailed me trying to upsell me on a $1,400/mo Enterprise plan with a 12-month commitment. I guess someone needed to hit their quota 😅

Render

Because of these reasons I’ve been exploring alternatives. I briefly tried self-hosting with one app, but when the server randomly went down one night because my logfiles filled up the disk (apparently they don’t automatically get deleted?), I realized I don’t want to play devops engineer.

I ultimately settled on Render. They provide a similar “Devops done for you” product as Heroku at a more reasonable price point, the product is actively developed, and the team seems more in touch with their customers. Not just the enterprise ones.

Over the past year, I’ve been migrating all of my apps from Heroku to Render. First some smaller apps, and eventually some of my bigger sites like Startup Jobs. Since many makers are curious about switching to Render, I figured it would be valuable to document one of those migrations for others to benefit from.

I recently switched BetaList to Render as well and documented my approach below. I’ll also share some of the unexpected issues I ran into, and explain how I solved them.

Disclosure — Render was a BetaList sponsor at the time I wrote this post.

Previous Heroku stack

• Rails 7.0.4 / Ruby 3.1.2
• Web dyno ($50/mo)
• Worker dyno for Sidekiq background jobs ($25/mo)
• Postgres ($50/mo)
• Redis (for caching and Sidekiq background jobs) ($25/mo)
• Scheduler ($5/mo)
• Adapt Scale for scaling up/down web workers ($18/mo)

On average I was paying around $175/mo at Heroku for BetaList. Not horrible, but if you run multiple sites like I do this will start to add up.

The migration process

Here’s roughly how I approached the switch:

1. Deploy a few smaller apps on Render.

2. Prepare the BetaList codebase.

3. Deploy a test version to Render.

4. Import (sanitized) production data.

5. Migrate for real.

1. Migrate a few smaller apps

Before migrating, I got familiar with Render and render.yaml. Rather than configuring everything through the dashboard (which is still possible as well), you can write a document as part of your codebase that defines which services to use, etc. It’s one of my favorite features.

You spend a lot of time configuring your servers, etc. so it’s nice to have a concrete copy of all that work. It makes it easier to experiment as well as you can always revert. Plus, you can easily copy your server setup between projects.

2. Preparing the codebase

Good preparation can save a bunch of work. I started by moving all of my API keys and other sensitive data from environment variables to the more portable Rails Credentials. I also backed up my config variables with this just to be safe. (Don’t commit this file to your git repository).

If you’re anything like me, you’ll see a multitude of opportunities to clean up. To streamline the design. Remove unused assets. Refactor that piece of code you wrote late last night.

Don’t.

Early on when building your startup, chaos is your friend. That mess of an HTML template? It reminds you it’s okay to be scrappy. The customer won’t mind. Making that border radius consistent with the rest can wait. It’s okay.

Enjoy the moment. Pretty soon you’ll have your structure. You’ll have a working product. And better yet, customers!

But this comes at a price. Rigidity. Changes will be harder to make. Bugs more costly. You’ll long for the chaos. Back when anything was possible.

Embrace the chaos… while you still can.

This is excellent advice for carpentry and working with physical objects. But, when it comes to building startups, I’ve come to realize it’s usually faster to “measure once, cut twice”.

You often don’t know yet exactly what you’re making. You’re figuring it out as you go along. The first cut lets you try out an idea. The second cut makes it right.

So next time you’re starting a new project, don’t spend too much time planning. Just start hacking away and see what you come up with. It’s usually faster and more effective than trying to plan everything out in advance.

Measure once, cut twice.

I’ve always been fascinated by seeing creative people work their craft. I don’t just want to see the finished product. I’d like to see the progress that got them there.

That’s why I make products like BetaList (discover startups in their early stages) and WIP (community of makers sharing their work in progress).

Over the last couple of years, the concept of “building in public” has become mainstream. People no longer wait to show off their project when it’s finished. Instead, they start sharing their progress from day one. It’s a great way to meet other makers, stay motivated, get early feedback, and build an audience.

A lot of people now build in public on Twitter. To connect, they use the hashtag #buildinpublic. Unfortunately, there wasn’t a great way to explore all these tweets and makers. Until now…

Introducing buildinpublic.com 🚀

A place to explore all the #buildinpublic tweets and see what everyone is working on.

Have a look and maybe give building in public a try yourself. Just post a tweet with the #buildinpublic hashtag and it will automatically show up on the site!

It’s also live on Product Hunt and BetaList, so if you’ve got an account there, your support would be appreciated! Looking forward to your feedback and #buildinpublic updates!

Continue reading for the full story on how I validated the idea, built a simple product, grew it to thousands of active users, tried monetizing it, and eventually sold it.

📝 Blog post as an MVP

People always tell you: start with an MVP, prove there’s demand for your product before investing all your time into something nobody wants. In my experience that’s good advice, but it seems many successful products often start out as accidental MVPs. Tweet Photo is a perfect example of this.

If you’ve ever tried posting an Instagram photo to Twitter, you might have noticed it looks like this:

Just a link. No photo. Useless. I don’t know the politics behind this, but I believe Facebook is the one that disabled the photo previews at some point. So now we’re stuck with useless tweets.

You can find many workarounds using automation services like IFTTT and Zapier. Because I was unhappy with all solutions, I decided to write my own article in May 2017:

A better way to post your Instagram photos to Twitter

Turns out I struck a chord. To this date that post has been read 70,000 times. Over three years later it continues to get over a thousand hits per month.

If you read the post though, you will notice how complicated the setup is. So I figured there might be an opportunity for a product here. I knew there was interest, but I didn’t know if I could monetize it.

It wasn’t until Yuko posted this question on WIP:

She mentioned she’d happily pay $20/mo for Zapier to tweet her photos. That got me thinking: maybe it’s a product that can be monetized after all. Plus, I already got the leads coming in via the blog post. I could funnel them through to this new service instead.

Rather than further validating the business model, I challenged myself to build a prototype over the next couple of days.

🛠 Building the Product

I believe in using the tools you’re familiar with, so I used Ruby on Rails to build the product.

Tweet Photo is technically quite simple. I’m basically gluing together the Instagram and Twitter APIs. I was able to do most of the work with open-source libraries.

I finished the product in just over a week during my spare time.

I initially went with the tweetphoto.icu domain name because it was only $1. That’s how much faith I had in the product I guess. But shortly after I decided if I’m going to do this, I might as well do it right and purchased tweet.photo for $130. It might not seem like a lot of money, but with all the projects I start things start to add up 😅. In hindsight I’m really glad I got this domain name…

I wouldn’t realize it until later, but the key feature I added was appending “via tweet.photo” to every tweet. This single piece of text would prove to be the driving factor of Tweet Photo’s growth.

🚀 Time to launch

December 12th, 2018, 11 days after Yuko’s post, I launched:

It got featured on BetaList (although no surprise here, as I’m the founder of BetaList) and Product Hunt.

At the end of the launch day over 100 accounts were created with a combined total of over 100 published tweets.

The product worked! 🥳

📈 Growth

As time went on the userbase continued growing.

Unlike most software services, the retention of Tweet Photo was basically 100%. Meaning that anyone that signed up, was likely to continue using it for a long time. Once signed up, everything was automated after all.

Combine that with the “via tweet.photo” in every tweet and you’ve got steady growth:

Here’s a screenshot of the Simple Analytics dashboard showing how tweets are driving new leads to the homepage:

We even got some major Hollywood celebrities using the service. In fact, Tweet Photo became a hot topic amongst her fans. Driving even more sign ups.

💸 Monetization

Okay, so we’ve got decent growth. But what about the revenue?

This was a lot harder. When I launched Tweet Photo I included a $19/year PRO subscription that would remove the “via tweet.photo” branding. I figured if people care enough about their Twitter profile to not want to show that link, they might be willing to pay.

People with more Twitter followers would pay more. After all if someone has a million Twitter followers it’s worth a lot more to me if they promote Tweet Photo in every tweet.

I eventually switched to monthly pricing starting at $5/mo. I figured churn rate would be really low anyway, so it would be better to charge monthly. Paying $5/mo instead of $19 for a year upfront is a lower commitment for the customer, but ultimately 3x the revenue for me.

Unfortunately MRR grew very slowly. It’s about $135 MRR right now.

I think the main problem is that the free plan is already very compelling. So it’s hard to convince people to upgrade.

🤔 Now what?

While I had plenty of ideas for improving monetization, including removing the free plan altogether, it didn’t seem worth my time trying to grow a product that’s only doing $135 MRR. Even if I could 10x that, it’s still a low amount compared to my other products.

So over time I spent less time and attention on Tweet Photo. It continued to grow organically.

Another reason I didn’t want to invest too much time is the inherent platform-risk of building an API-powered product. I was dependent on both Twitter and Facebook continuing to provide me access to their API. They could revoke it at any time and Tweet Photo might be doomed.

Earlier this year Facebook did actually deprecate one of their APIs I was relying on, requiring me to upgrade my integration to use a different API.

💬 Acquisition offer

In April, Kevin reached out to me asking if I was interested in selling Tweet Photo. He had a strategic interest with his other products CreatorKit and Top Nine.

Of course the question of valuation quickly came up. Typically a SaaS product is sold for 3-4x annual revenue. In Tweet Photo’s case that would be around $5,000. But that didn’t factor in the many free users that required almost zero customer support, but drove continued growth.

If I were to sell it, it would need to be in the $xx,xxx range. Otherwise I’d prefer to just keep the service and see what happens. There’s always the possibility of another celebrity using it and it going viral.

💰 Valuation of $30,000

After some negotiation we ultimately settled on a purchase price of $30,000.

The first $10,000 is cash upfront with no strings attached. The remaining $20,000 is contingent on the revenue Tweet Photo will generate. Basically I will receive all revenue generated within 24 months of the acquisition, with a cap of $20,000.

We both ran the numbers and we believe that with the full weight of CreatorKit behind it, it seems very likely Tweet Photo will generate more than that.

But you never know how things turn out, so this was a way to de-risk the acquisition for the buyer while still allowing for a higher purchase than you’d typically see for a $135 MRR business.

Ask me in a few months how things are going 🙂

👀 What’s next

The $10,000 is in the bank and we’re now finalizing the asset transfer.

In the coming months CreatorKit will likely start marketing it to their existing userbase and possibly improving the service as well. Since we still have a shared interest in growing Tweet Photo me and the CreatorKit team will keep in touch to see how things are going.

Personally, I will continue to focus on WIP, BetaList, and Startup Jobs.

If you want to hear how the remaining $20,000 plays out subscribe to my newsletter below 💌

• ✅ submit.co
• ✅ submitly.com
• ❌ submitly.co

It’s not a hard rule, but when you’re weighing options I’d lean toward fewer parts. Play around with different combinations and you can usually find an affordable domain that fits.

I’m not a linguist, but I think the way we memorize these domains is by remembering the concept of the dictionary word and the letters or vocalization of the prefix, suffix, or TLD. Memorizing two vocalizations (i.e. two non-dictionary words) is a lot harder.

Common prefixes: get-, use-, hello-, hi-, meet-, ask-, my-. Common suffixes: -app, -ly, -list.

For tech-savvy audiences or fun apps I tend to prefer dictionary-word + non-standard TLD. A few examples: tweet.photo, wip.chat, highscore.money, expensive.chat, startup.jobs.

I have built dozens of different products over the last couple of years. The vast majority failed. Surely if I already knew the answers to those questions, but still failed over and over again, those answers aren’t that useful. So what’s a better question to ask?

The real question — the thing you actually want to know — is this: what makes WIP, BetaList, and Startup Jobs succeed where my countless other attempts failed? What separates a failed product from a successful one?

99.9% of the questions I receive are about the products that did well. In a way that makes sense, because we quickly forget the ones that didn’t. This is known as survivorship bias — focusing on what survived while ignoring what made it survive in the first place.

Honestly, I don’t know the answer. I wish I did. It’s like Steve Jobs said: “I’ll know it when I see it.” The same is true when we make products. We don’t know upfront what will work. But once we see an inkling of a product that does have potential, it’s not that hard to spot.

So keep shipping. Assume your current product will fail and that you need to try a bunch more before you find the metaphorical spaghetti that sticks to the wall.

Some contrasts I’ve come to recognize

The wrong idea requires you to push and push until you’re tired and can’t take it anymore. The right idea pulls you forwards.

The wrong product will have you focused on the technology, fine-tuning the design, tweaking the copy. The right product will give you the confidence to ship something embarrassing, because you know that despite all its shortcomings it’s useful.

The wrong product will have you begging people for feedback. You’ll cling to any comment remotely positive (“Wouldn’t use, but nice idea!”). The right product will attract people wanting to use it. People will give feedback without you asking for it.

Practical advice

Keep your initial products small. If it takes 10 tries to find something that works, you can’t afford to spend more than a month on any one idea.

Persistence is not about sticking with what doesn’t work. Persistence is continuously experimenting until you find something that does.

Happy shipping.

— Inspired by conversations in WIP.

A few things that stuck with me, in my own words:

Show, don’t tell. Rather than endlessly discussing ideas in the abstract, Apple engineers build prototypes and demo them to each other and to decision makers.

The best ideas win. There’s no place for ego when building great products. The book mentions multiple occasions where Steve Jobs, without hesitation, bins his own idea in favor of a clearly better one.

Iteration is the name of the game. Kocienda gives countless examples of how a prototype starts as an okay solution and step by step gets better through experimentation, real-life usage, and continued improvement. The product Apple ships is more akin to a v5.0 than a v1.0.

Hack together a first prototype ASAP. Apple’s first prototypes were often quick hacks that showed the potential of what the real product could become. They inspire, and they give you something tangible to work with. Start small.

There’s a lot more in the book — these are just the bits that resonated most with me as an indie maker.

February 2014

The idea of “Attaboy” was for makers to share what they are working on and keep each other motivated throughout the development process. It was email-based and never got any traction. Seems familiar though, right? 🤔🚧

Later that month

A mock-up for a mobile app. I figured maybe email wasn’t the right medium. I never built the app though — didn’t have the coding skills, nor market validation.

February 2015 — a year later

You can’t tell from the cryptic copy in the design mock-up, but this was an iteration of the same idea. I got it fully built, but it proved to be over-engineered and I never felt it was good enough to launch. 🤷‍♂️

April 2016

A different, but related idea. What if you could share your sketches, wireframes, and mockups to get feedback on? Truly building in public.

I built it, but lost motivation pretty early on so I never launched it. Repeating theme. 😂

September 2017

@levelsio suggests I start a Telegram group for BetaList.

A few days later, people start sharing their completed tasks. So I built a bot and a simple website. I renamed the chat and WIP is born.

Today

WIP is helping hundreds of makers achieve their goals of building profitable businesses, is doing a few thousand dollars in monthly recurring revenue, and is distributing the best memes in town. #humblebrag

(FWIW, I only included a selection of prototypes, sketches, and related products. I actually tried many more approaches such as changelog.co and others.)

Related things I made that led to WIP

Back in the days before Slack was a thing, I experimented with a $7/mo chat community on 37signals’ Campfire team chat service. While there was some interest, it proved difficult getting to critical mass — crucial for real-time chat.

Another thing that influenced WIP is a quick prototype I made for Telegram. It was supposed to record short podcasts through the chat app. I was able to use that codebase as a starting point for WIP — it already had the Telegram integration I needed. If it wasn’t for that codebase I might not have bothered creating that initial WIP prototype.

Lessons learned

• Just because your idea doesn’t work right now in its current form doesn’t mean it won’t work later in perhaps a slightly different form.
• Even if a product doesn’t work out, you can still gain insights that will help inform your next product.
• Some of the hardest yet most important insights to gain are insights into customer needs and behavior. You will only get these if you actually ship the damn product.
• For the reasons above it makes sense keeping the product scope small early on. (I know I’m like a broken record on this, but it’s so important it bears repeating.)
• Managing your own psychology is crucial as well. Know the things that motivate, scare, and bore you. My pitfall is over-engineering and running out of motivation before the product is ready to ship. Solution: smaller scope + accept seeming ignorant to obvious product shortcomings.

It’s 1am, I’m eating McDonald’s delivery, and making tons of grammar errors. Signing out.

🛄 Only bring carry-on luggage.

It’s usually cheaper and you can check in online. For most airlines this means you don’t need to go to the airport counter and can go straight to the gate. It also saves you time when you arrive at your destination as you don’t need to wait for the slow luggage belt.

🛒 In case of doubt, don’t bring it.

The less luggage you bring, the less hassle. Smaller chance something gets lost, and less weight to carry around. If you’re unsure about whether to bring a certain item, consider that you can probably just buy it at your destination as well.

🎫 Flight ticket prices vary wildly.

Prices can change a lot depending on when you travel, with which airline, in which class, etc. If you’re traveling on a budget, make sure to do your research. Typically the more time between when you book and when your flight is, the cheaper. Use sites like Google Flights and Kiwi to compare different airlines.

💬 Meeting people.

It’s great if you can travel with friends. But if that’s not an option, there’s a bunch of different ways to make new friends at your destination. Joining a co-working place is one way. But also meetups through sites like Meetup.com or Nomad List. Dating apps like Tinder and Bumble can also be good ways to make new friends (or more).

📅 Stay flexible

If you’re visiting a new place, it’s hard to predict if you’re going to like it. And which area to stay at. So I try not to commit too much in advance and keep my options open. For example I might book a one-week hotel stay even if I plan to stay a few months. That gives enough time to explore the area IRL and pick a permanent spot.

💳 Use Revolut

Traditional banks can charge a lot for international credit card payments and ATM withdrawals. Newer banks like Revolut have a lot lower fees, and make it easy to order multiple cards so you always have a backup if you lose one.

✅ Make checklists

I’ve created a bunch of check lists for myself for travel. I’ve got a list for “what to look when booking an accommodation” (I have quite a few requirements 😅). Prep for a flight (including a packing list, etc). I even have checklist with what to do when arriving at my destination. It includes things like getting protein powder for exercise (as I usually find it too bulky to travel with) and properly unpacking rather than living out of my suitcase.

🍛 Select specific in-flight meal during check-in.

You’ll get food first + your choice. AFAIK there’s never an additional cost for choosing beforehand

🎧 Noise-cancelling headphones

Well worth it for long flights. They make a huge difference to how rested you feel when you land.

🗺 Nomad List

Add trip to https://nomadlist.com to receive arrival email with local tips (which sim card to get, tipping percentage, etc)

👕 You can wash clothes during travel.

No need to pack weeks worth of clothes.

💺 SeatGuru

Use SeatGuru.com to find the best seats in plane

👍 Enjoy the trip

All the prep is only worth it if you actually take the time to enjoy where you are. Don’t pack your schedule so full you forget to just be there.

I learned many of these tips from @levelsio (@nomadlist), and @jelmerdeboer’s book: https://thuisblijvenisduurder.com