I purchased the Samsung Galaxy S10 5G (what a mouthful) on launch day – May 16th, 2019. Luckily, the Verizon 5G Network is live in Chicago. Here's a quick video recapping some of the amazing speeds I have been able to achieve with the device.
As part of my recent effort to test my ideas, I came up with a relatively simple subscription service concept. What if many of the popular flight deal subscription services were better?
I'd personally love a service that:
Alerts me when there's an awesome flight deal that will save me lots of money
Has no ads or unnecessary sponsored content
Is focused on great deals (quality airlines only, no crazy long stopovers, etc.)
Only sends me deals for my city
In my experience, finding quality flight deals is challenging but possible if you know how to search and where to look. Because I like to travel, I'm constantly searching for new deals and reviewing them with my friends and family. So somewhat naturally, I thought to myself: I could make one of these services.
Given these inputs, I decided to put something together. I spent some time brainstorming and soon Club Finch was born. It's up and running today, so please take the website for a spin and sign up if you think the offering is compelling.
This is an extremely simple product: users sign up for the free trial with their email address and ultimately can become a paid subscriber with a credit card. Once a user signs up, they begin receiving alerts about these awesome flight deals in their inbox. After some recent conversations about this service with friends and advisors, I thought it would be useful to share everything that's under the hood to make Club Finch. Below, I detail everything in my process.
The basic economics
With any business idea, there needs to be some level of economic validation. It's fine to create things that don't make money, but I tend to focus on ideas that can in theory generate some revenue. For this idea, the back-of-the-napkin numbers are somewhat simple:
There are over 9 million people in the Chicago area (public data)
Some number of people in the world are willing to pay $20/year for a service that delivers value (see competitors and their pricing models)
If I can capture 1,000 paying users, it's about 0.001% of the population, which seems achievable (gut feeling)
If I can capture 1,000 paying users, it will gross $20,000 in annual subscription revenue, which would make this more than worthwhile for me
These basic numbers gave me enough confidence to try something. Given the low cost to start (see below), there's almost nothing to lose.
Coming up with a name
Having a good name or codename for your project is crucial. I've found it's a lot easier to start working on something once you have a name for it. In a future post, I'll outline my name generation methods. But for now, I'll keep it brief. For this name, I had three key goals in mind:
I didn't want to have a terribly gimmicky name like some of the other services out there
I wanted to land an easily memorable .com domain
I wanted the name to be travel-inspired (loosely)
Given these goals, I created a brainstorm document. I started with travel words and synonyms, which ultimately led me to the term "finch" as a starting point. Quite simply: a finch is a bird, birds fly, and this is a flight deal service after all. As the domain finch.com is taken (obviously), I began to look into modifier words.
As this is a service subscription, it seemed obvious to call the customers "members" when they sign up. From there, it's somewhat straightforward to consider the term "club" as the modifier. In many ways, it fits. It's a membership club about flying on airplanes.
Logo and creative identity
With most ideas for side projects, I don't go as far as creating a logo. Usually, simply having a name will suffice. However, this one felt worthy of a brief identity/branding exercise. Typically, I would contact a designer friend or find a freelancer and pay them to create a logo or identity. I've done this numerous times over the years with great success. However, this time I was feeling a bit creative myself. I'm by no means an expert with design or graphics, but sometimes it's fun to give it a go. At the end of the day, side projects are mostly about learning and stretching yourself rather than making money. Most of them fail to gain traction.
For this, I had the word finch in mind the whole time. I initially started off with bird or bird-like shapes and never really landed on one I loved. I then tried some combinations of lettering or fonts. I started liking those variations quite a bit. Before I made a decision, I created a few more generic abstract shapes to compare. When I had several options, I showed them to friends or family to get feedback.
Ultimately, I landed on a shape that is inspired by a C and F lettering intertwined. I'm pretty happy with it. Though I'm sure a professional could do better, this works just fine for my needs. If this starts generating real revenue, I will almost certainly pay someone talented to create something better.
Landing page design
My go-to landing page tool these days is Carrd.co. AJ has done such a fantastic job with the tool, and the pricing is incredible. It integrates seamlessly with ConvertKit and Stripe, which made this site a breeze. I started with a blank template and simply put elements together.
My only real guiding principle was: keep it simple so it works well on mobile. I think it turned out pretty well. I can improve it over time, but it has all the necessary information in a streamlined layout. Like many of the other steps in building this MVP, I shared the page with friends and family to gather feedback on the layout and content structure regularly.
Email system and email automation
To make any email product successful, you need a tool to manage a subscriber list and send emails. I've heard great things about ConvertKit over and over again, so I decided to give it a try. I can segment users easily and create powerful automation sequences.
Within a matter of minutes, I was able to set up a new user on-boarding flow, a sequence to entice free users to convert to paid users, a trial expiration automation, and more.
Subscriptions and processing payments
Stripe makes it easy to collect payments, and luckily enough it plugs right in to Carrd. It really couldn't be easier. Within Carrd, there are simple drag-and-drop form builders that can accept payments using your Stripe credentials. Furthermore, it's just a couple clicks to connect Stripe and ConvertKit. This connection tags users who subscribe to the paid plan automatically.
Costs to operate the business
To run Club Finch, here are the costs:
Domain name: $12/year
ConvertKit: $29/month (14-day trial to start, pricing scales with more subscribers)
Carrd: $19/year (for 10 sites!)
Sourcing flight deals: some of my time
All-in, I can operate this business for under $500/year. Technically speaking, I should probably budget some level of legal/account costs for operating a business, but seeing as this is simply in MVP phase, I left that out. Luckily, all the tools I'm subscribed to are easy enough to cancel. If I can't break even on the idea in a few months, I can simply turn it all off and move on.
Thus far, Club Finch has 2 paying subscribers on the annual plan. It has generated $40 in subscription revenue, but the costs have been around $60 for the first few weeks after my ConvertKit trial ran out. In a couple weeks I'll have another bill for $29 from ConvertKit, so I had better start signing up more paid users.
I've been telling friends and family about the service for a couple weeks now in order to ensure it's fully operational and that all the automation sequences work correctly. I plan to widen this net soon. Ultimately, I'm going to throw some money at advertising to see if I can acquire customers through paid channels.
My goal with Club Finch is to break even within 90 days and generate $100/month in recurring revenue within 180 days. If I can't get to these milestones, I'll evaluate things again and make a decision to keep trying or shut it down.
Up next, I'm going to start some paid acquisition campaigns on Facebook and Instagram. I've seen competitor services achieve success with these, so I have some confidence these will work. Given my extremely low operating costs per user, I have quite a bit of room to spend on acquiring a customer. I'd like to find a reliable, repeatable way to acquire paid customers for $10 or less.
March can be a strange time of year to reflect, but lately I've found myself doing just that with respect to my GitHub stats. For about 12 months, I've been obsessed with tracking one simple graph, and I think it's time to analyze what this has done for me and decide if I need to make a change going forward.
More specifically, I updated my GitHub Profile to make my contribution activity public to the world, even for my work in private repositories. This still hides exactly what I've been doing, but it does show how many commits or pull requests I create on a given day. I've used this as a step toward accountability with myself: last year I set a goal to code more often, and this helps prove that I have been coding more often.
In my day job, I don't write much code at all. I lead a very strong team of engineers, and as a manager I empower them to make decisions and write code while I get out of the way. My focus on leadership, people management, and technical strategy for my day-to-day responsibilities has led me to side projects or weekend hacks to stay current with coding and modern web or app software trends. Thus, my goal to write code at least once per week was born. I've made a deliberate effort to take an hour or two in the morning or evening to write code at least once a week.
Evaluating my progress
In the last year I contributed 561 bits of work towards repositories on GitHub. That's just over 1.5 contributions per day. However, as you can see from the visual representation above, I haven't quite hit my goal. Even though it averages out to at least once per day, there are multi-week stretches of time with no activity whatsoever. On the flip side, there was a stretch of time where I wrote code for 49 days straight.
Reflecting on these numbers has made me think: has the obsession been worth it? I've dabbled with React Native, React web apps, Node.js backends, Ruby/Rails backends, native iOS or Android apps, and more in the past year. Exposure to all of these platforms in my free time has helped me in my day job, and it has also helped me build cool prototypes or MVPs of various ideas I may have. In many ways, it has been extremely valuable to continue coding regularly.
Keeping an eye on my contribution number has also driven me to write more code. It may seem obvious, but having a number to increase by one has made it pretty simple. There have been several days in the past year where I think to myself, "I need to keep the streak going" so that I can fill in the next box in the chart. This has pushed me to write code when I might have just taken a morning or evening off to relax.
While I have been able to achieve my goal to write more code, it has me wondering: should this be my focus? I've gained a lot from coding more often, but I have also sacrificed growth in other areas. Lately I've become extremely interested in the Low-Code or No-Code movement. In many ways, we have hit an inflection point: non-coders are able to produce results and create value in ways that simply was not possible before. I've been following makers like AJ of Carrd, Ben of MakerPad, and Pat of Starter Story. The stories of their individual success and the success stories they share of others is often astounding.
Looking ahead, I plan to continue coding. No questions. It's fun, rewarding, and second-to-none for me. However, I'm putting my obsession with GitHub stats to the side. Going forward, I will focus on delivering value and proving out ideas rather than writing code. If those ideas or value require code, I'll write it. However, there are a number of no/low-code ideas on my list that have been shelved due to my focus the past 12 months on purely writing code.
Here are a few specific ways I plan to hold myself accountable, in lieu of chasing my GitHub stats.
Publish updates transparently discussing my progress on projects on my blog or another content platform
Deliver something of value each month: a software prototype/MVP, new feature in an existing project, or test an entirely new business idea
Reflect on this effort regularly, but evaluate thoroughly in six months
Writing this post is simply the first step toward achieving this goal. I'll keep you posted as I go.
I've created many apps that could benefit from quickly spinning up an API from a static data file. This can include a frontend app or even a backend app. One example could be a bit of data you've got in a spreadsheet that would be great to simply throw in an API. Whether for testing something as a POC or running all the way to a production app, this can be a great way to get moving.
Note: The term API is somewhat glorified here. What I'm really making is simply a way to access JSON data over HTTP.
I'm familiar with Node.js and luckily I stumbled upon the package json-server a while back. This package is super simple: run a server that hosts data from a JSON file. That's it. You can install it globally using npm install -g json-server and serve up files locally for development. Alternatively, you can wrap it in your own app and deploy it to a service like Heroku for a fully-functioning public API stand-in.
I'll walk you through doing just that. This app is extremely simple on purpose. It's just three files. There's a link to all the source code at the bottom of this post.
First, we have index.js which is our Node app. Here, we import our dependencies and create a server to host our JSON data.
const jsonServer = require('json-server');
const server = jsonServer.create();
// Create a json-server with our JSON file on disk
const router = jsonServer.router('db.json');
const middlewares = jsonServer.defaults();
// Configure port for Heroku deploy
const port = process.env.PORT || 5151;
// Start the server
Next, in package.json we list our dependencies and configuration. Note: Heroku will automatically pick up on the start script in this file.
"description": "A demo app to host JSON files as an API.",
"start": "node index.js"
"author": "Nic Roth",
Lastly, we have db.json where we store the data. The json-server package is pretty automagical when it comes to configuration. As long as your data is a valid JSON file, it will render correctly as an API.
"title": "A demo.",
"body": "This is the demo story"
"title": "Second story",
"body": "We are hosting some JSON!"
Using these three files, you can deploy a data API in minutes. Simply drop in your data file to db.json and deploy it to Heroku.
In this example, if you query the /stories route you will receive the following data.
"title": "A demo.",
"body": "This is the demo story"
"title": "Second story",
"body": "We are hosting some JSON!"
Now, my frontend app can start to interact with an API stand-in over HTTP. I can wire up loading states, interactions, and more all without having to build a real backend.
You can view the full source for this example on GitHub here. On the repo, there is a button to deploy this app to Heroku so you can have your own live example in just a click.