The unreasonable effectiveness of shipping every day

It's fairly common for folks in tech to dream of quitting their day job and working on their side projects. I find when you ask them how their projects are going, they tend to have 2-3 projects running at the same time, none of the projects are actually available for potential users to try out.

The question they seem to ask me most is "you seem to complete your projects, how do you stay motivated?"

My secret? It's a habit. I ship something every day.

Table of Contents

• Some context
• Forming the habit
• How I work
• How this works in practice
• Summary

Some context

For context, since 2017 I have shipped:

• a job board (shut-down)
• an appointment scheduling service (shut-down)
• a room booking service (shut-down)
• a GraphQL API testing service (shut-down)
• a web performance monitoring service (shut-down)
• a weekly blog about React (paused while I work on my SaaS)
• a book about React's useEffect hook (still gets sales)
• an introductory book for testing React
• an incident management service (uptime monitoring + status pages)

I initially got started because I wanted to learn to use React and GraphQL better for my day job, but these days I enjoy running the business and learning about marketing.

Forming the habit

Actually forming the habit is the most difficult part, but I promise it gets easier.

To get started on each project, I prioritize getting an absolute minimal "viable" product live and able to accept customers as soon as possible. In the case of my most recent project (that I've now been working on continuously for two hours per workday since February 2021), this took one week.

I say "viable" because while users could login, subscribe to a paid plan, add pages to monitor, and receive downtime notifications, it wasn't an actually viable solution to their problem. It wasn't until I added significantly more features that users started paying me for the service.

Once a product/blog article/book is live, you can start getting users. Once you start getting users, their feedback helps inform what you should work on next.

How I work

I tend to work on my personal projects in 2 hour increments (before my work day starts), partly because that's how long I can focus at a time, and partly because I prefer to chip away at a problem, rather than making one big push.

Usually by the end of those two hours, I'll have something running live.

You'll find two hours isn't nearly enough to "complete" a feature. Get used to being embarrassed by your incomplete project.

In other words, limit scope as much as possible.

Practically, this means releasing forms that gather less data than needed, or only building the UI portion of a feature before the backend is ready. For books, it could mean releasing a chapter as an email to your newsletter subscribers. For SaaS, I'd recommend starting an early access program and let users that opt-in know when they're looking at incomplete features.

How this works in practice

It's all well and good for me to tell you to "ship more!", but it feels pointless without providing a concrete example of how it works in practice for a real SaaS product.

Here's roughly how OnlineOrNot's uptime monitoring was built:

1. Released a simple form that accepted a URL to monitor, and a name for the uptime check
2. Made it possible to receive email notifications when an uptime check is down
3. Made it possible to search for text on the page while checking
4. Made it possible to customize the uptime check frequency
5. Made it possible to sign up for a Slack notification when your uptime check is down
6. Made the Slack integration actually send a notification when the uptime check is down
7. Made it possible to wait for several failed uptime checks before sending a notification
8. Made it possible to edit existing uptime checks

All of these features were delivered while the service was live, accepting users, and those users were helping inform the direction of the product.

You'll find an Early Access Program helps a lot for cases like Steps 5 and 6 above - I'll often release forms to my early access users that only save their preferences, without actually taking the preference into account until a few days later when I fully complete the feature.

Caveat: the types of folks that opt-in to an early access program tend to be accepting of this kind of thing, I wouldn't recommend shipping incomplete product features to your entire user base unless you're extremely early in your product's development.

Summary

Consistent effort over a long time helps you accomplish things you think are impossible.

Get used to being embarrassed by your incomplete project.

I wish I realized this in high school/university.