Author Archives: Jason

February 2020 Revenue Report

I launched Rails Testing for Beginners to my new subscribers in February.

2020 February $235
2020 January $268
2019 December $0
2019 November $0
2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

January 2020 Revenue Report

I’m not making an individual post for December 2019 because there were no sales.

In January I launched a new product called Production Rails, which made about $268 in sales. I ended up deciding the creation of the product was a mistake and I refunded everyone.

2020 January $268
2019 December $0
2019 November $0
2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

2019 Review and 2020 Goals and Plans

2019 has been a pretty interesting year. Here are some of the high points.

What went well in 2019

I didn’t flail around too much with product endeavors

My earnest attempts at building a successful product business started around 2008. In the time since then there have been a number of periods, some lasting many months, where I was completely without direction, just wildly flailing. These periods sucked because they were so obviously unproductive.

From February 2018 to now (December 2019), I’ve been pretty much steadily focused on the business I refer to as CodeWithJason.com. Obviously it’s good to stick with one thing for a long time, as long as it’s a good thing. I’ve definitely been guilty in the past of going around and laying foundation after foundation without sticking around to build the whole house. In this case I actually have stuck around long enough to build a good portion of the house.

I stuck with one client the whole year

In my career I’ve worked for a lot of different bosses and freelancing clients. A good portion of the people I’ve worked for and the teams I’ve worked with I frankly haven’t cared for that much, and haven’t worked for that long. (I’ve also worked for a number of startups that have had financial troubles, and so a number of relationships have ended that way.) Fortunately, in the late summer of 2018, I started a relationship with a client I like working with a lot, so much so that I expect he and I will work together for the indefinite future. (This relationship is what prompted me to quit freelancing.)

I got some good conference speaking gigs

Before the fall of 2018 I had never spoken at a conference at all. As of now I’ve spoken at 9 conferences, if I’m not mistaken. I’d say my biggest two speaking achievements of 2019 were speaking at RubyConf India, which was my first international conference talk, and RailsConf, which is of course the flagship Rails conference. I also really enjoyed speaking at RubyHACK in Salt Lake City and Southeast Ruby in Nashville.

My podcast endeavors went well

In May of 2018 I semi-experimentally started a podcast called The Ruby Testing Podcast. It was successful beyond my expectations. My guests included Michael Hartl and Kent Beck. To date I’ve gotten over 30,000 downloads.

Encouraged by my success with The Ruby Testing Podcast, and wanting to no longer be limited to the topic of testing, I decided to start a broader podcast called Rails with Jason. I’ve been happy with how it has turned out content-wise, for the most part, and I’ve had a number of big-name guests.

What didn’t go as well in 2019

The conferences were expensive

All the conferences I spoke at required some level of out-of-pocket expense.

When I first started seriously pursuing conference speaking around mid-2018 or so, my hope and expectation was that my conference talks would lead to lucrative consulting engagements (training gigs, specifically) that would give me a worthwhile return on my investment. Unfortunately those consulting leads never came in, or at least they haven’t yet. I can’t say these investments didn’t pay off, I can only say they haven’t yet, because it wouldn’t surprise me at all if I get a consulting lead 10 years from now from someone I met at a conference this year. I’ve found that the gestation time for consulting leads is often several years.

Anyway, the point is that I spent a bunch of money speaking at conferences and as of now I haven’t recouped my investment. So I’m probably going to take it easy on conferences in 2020. I plan to speak at perhaps one conference or maybe none.

CodeWithJason.com grew less than I expected

When I launched Rails Testing for Beginners in March, I did $988 in sales, which was the biggest launch in my limited career of doing product launches. Unfortunately things have only gone downward from there. Here’s a graph of year-to-date sales.

More concerning than the revenue numbers, my email list has only grown by a net of about 200 subscribers since March, or about 24 per month on average. That’s 288 new subscribers a year, which hardly seems like enough to sustain a viable business. I’m not ready to quit yet though. I think it’s reasonable to expect that audience growth can be somewhat exponential. Maybe in 2020 my email list will instead grow by 400 subscribers, and then 800 in 2021, and so on. We’ll see how things go. And of course, I intend to try to figure out how to deliberately make that number go up faster.

Other stuff that happened in 2019

In the later half of 2019 I had two great product ideas. One was a Rails CI tool with ridiculous parallelism built in that would allow you to run any test suite in under 10 seconds (I built a POC and it really worked!). Another was a tool that would make AWS + Rails deployment almost as easy as Heroku (which I also built a working POC for).

Unfortunately I discovered that each one of these two ideas would require a lot more time to get going than I really have available. Fortunately, I’m experienced enough now to bail early on doomed ideas instead of burning years of my life beating a dead horse.

Plans for 2020

Since I no longer consider myself a freelancer, and since I have a “day job” that I’m okay with keeping indefinitely, that makes that part of my 2020 plans easy. Unlike previous years, I won’t be spending time trying to get consulting clients or anything else on that side of things.

That leaves my product endeavors to focus on for 2020. Here are my plans in that area.

For CodeWithJason.com, I plan to improve and expand Rails Testing for Beginners, then re-launch it. In fact, I’ve already expanded RTFB from 99 pages to 189 pages by bringing in a bunch of the Rails testing blog posts I’ve written over the last several months. I’ve also begun radically redesigning and improving the sales page.

I also plan to try again with the AWS + Rails thing, but smaller this time. Building a whole software product to make AWS + Rails deployments easier is too time-consuming. So maybe I can do something smaller, like just write a blog post about how to deploy Rails to AWS. Then maybe I can build a tool or even just a set of scripts that makes parts of that deployment process easier.

I also decided to set a model financial goal for CodeWithJason.com. My 2019 revenue was about $2100 (which could conceivably still go up), so I’ll see if I can roughly double my revenue for 2020, and hit $5000.

November 2019 Revenue Report

November’s revenue report is pretty boring. No sales.

Here’s my revenue for past months.

2019 November $0
2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

October 2019 Revenue Report

In October my revenue was $168. I didn’t do any launches or anything. These sales were just “natural”.

Here’s my revenue for past months.

2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

Pulling the plug on Exosuit

After about two months of working on it, I’ve decided to stop working on Exosuit, the tool I’ve been building to make Rails + AWS deployments easier.

The reason for my decision is that I decided that the amount of time it would take to get Exosuit off the ground (in terms of hours per day) is substantially more time than I have available.

I know from painful past experience that it’s not enough to build the product. The product also has to be marketed. The marketing work takes a serious amount of time and effort. For a relatively complex software project such as Exosuit, I don’t have time to do the programming work, the marketing work, AND have a day job.

For context, I had spent about 2 months working on the Exosuit “MVP” and in that time I maybe only got about halfway done, estimating generously. I would have spent another 2, 4 or 6 months building the thing before it would even have been un-fragile enough to let another person touch it. Throughout all that time, all marketing work would be 100% on hold. That seems like a really risky plan.

I still think the product idea is a good one. I hope to come back to it someday. I just don’t have the resources at the present to build it and turn it into a viable business.

My plan now is to turn my attention back to building my email list and selling Rails-related info products. That stuff hadn’t been going as well as I would have liked, but my current thinking is that it’s a better bet to try to improve what was already working than to try a totally new thing.

Why immortality would be terrible

Some people think it would be nice if humans could live forever. I’ve heard of people in Silicon Valley trying to work on ways to allow people to live indefinitely.

I think immortality is actually a real bad idea, and I think these Silicon Valley guys’ endeavor is naive and crazy. I’ll explain why, starting with total immortality (which is impossible, for reasons I’ll describe) and then turning to the idea of an indefinite lifespan (which theoretically is possible).

To me, the most glaring and obvious problem with immortality is the inevitability of something happening to you that’s both really bad and basically permanent. For example, imagine that 62,000 years into your life, you’re on a boat by yourself. The boat sinks to the bottom of the ocean and traps you. No one but you knows that this happened, so you spend the rest of eternity trapped at the bottom of the ocean. Or think about the inevitably of eventually being falsely accused of murder and spending the rest of eternity in prison. I can even imagine a war where prisoners of war are hooked up to torture machines that torture them for the rest of eternity. Those things would obviously be really bad.

I also imagine that an eternal life would mean an infinite accumulation of emotional pains and regrets. As I’ve gotten older I’ve noticed that I have a growing backlog of regrets that my brain seems to enjoy picking from at random and surfacing to me in my mind periodically. Imagine making some huge regretful error at age 19 and then having to live with that mental burden for the next 1000, 100,000, 100 billion years.

Plus there are the logistical issues. If we somehow figured out how to get people to live forever, it’s still true that every star in the universe will eventually burn out. Then what? Even the idea of uploading a person’s consciousness onto a computer for eternal habitation doesn’t answer that problem.

I think death is actually perfect. You’re guaranteed that nothing that bad can happen to because either the bad thing will kill you or you’ll eventually die some other way and be done suffering. Death is nature’s “escape hatch”. You can accumulate a lifetime of mental weight, but then the slate is wiped clean. The “reset button” gets hit when someone dies and a baby is born.

I didn’t mention an obvious thing about immortality: it’s a physical impossibility because there’s no way a body could survive complete destruction. Even if you move consciousness to computers, the physical computers themselves aren’t absolutely impervious to destruction. It seems that the “next best thing” is an indefinite lifespan. I’ll explain why I don’t think an indefinite lifespan would be better than a normal human lifespan.

I suppose that if we figure out how to make humans live indefinitely, then that will necessarily mean that people won’t ever die of disease. So the only causes of death would be accidents, murder and suicide. So from the moment you’re old enough to understand it, you’ll be aware that your life will, as an absolute certainty, end in an accident or murder or suicide, most likely an accident (or maybe most likely suicide). To me this idea seems quite uncomfortable. I personally much prefer the idea that the most likely scenario of my death is just a faint petering out, “dying of old age”.

Also, as you get older, more of your friends and family would be dead the older you got. This is of course the way it is now. It would be more pronounced if indefinite life were possible. A person who managed to live to 5,000 would probably have very few 5,000 year-old peers. If you started life with 250 people you cared about and 0.1% of them died each year, it would take, by my calculations, about 6,000 years for almost all of them to die. Then you’d just be super lonely from then on. You could always make new friends, I suppose, but they’d all be much younger, and from a different world.

So, although I often get quite uncomfortable when I think about the reality that I’ll inevitably die, I find it comforting to consider that, among the (non-supernatural) alternatives, it’s probably actually the best possible way for life to be.

Technical update on Exosuit progress (10/10/2019)

I’ve been working somewhat feverishly for the last few weeks on Exosuit, my Rails + AWS deployment tool.

What Exosuit can do as of now

Install. You can install Exosuit by doing brew tap jasonswett/exosuit && brew install exosuit. I think this is pretty nifty.

Launch. You can run the exo launch command to launch a new EC2 instance. Exosuit will mark this instance in the Exosuit config file as the “primary” EC2 instance.

SSH. You can run exo ssh to SSH into the primary instance.

Install stuff. You can run exo prepare to install some stuff on the primary EC2 instance. This part is a work in progress and is not a part of the publicly-documented API yet. It might never be. This is just kind of an intermediate step to help make all my manual work less manual.

Register an app. My vision is that eventually you can run exo create, git push exosuit master, then exo open and see your fully-ready Rails app at a production EC2 URL. Right now, you can run exo create and, if you have an account at app.exosuit.io, you can register the app with “the mothership”. Why do this? Because the vision is that when you register your app with the mothership, the mothership will create a repo at git.exosuit.io, the CLI tool will do git remote add origin http://git.exosuit.io/your-app-name.git, and then anytime you do git push exosuit master, the Exosuit Git server can listen and automatically push to your production EC2 instance. I know that’s a lot of stuff. I plan to write something to explain it in more detail sometime. It’s all modeled after my understanding of how Heroku works.

My next steps

My current milestone target is the ability to run exo create and have Exosuit create a repo at git.exosuit.io. To do this in a fully secure manner is definitely non-trivial.

I currently have the Exosuit CLI working to where it can hit https://app.exosuit.io/api/v1/apps (again, “the mothership”), including the user’s app name in the payload. This will create a record in the mothership database to keep track of the fact that this user has this app.

Next I need to make it so the mothership can say “Hey, Exosuit Git server, create a blank repo for such-and-such app, and let me know if it actually worked.” I have a pretty good idea of how I’m going to accomplish all this, it’s just going to be a lot of work.

I also came up with some thoughts as to what the free vs. paid tiers of Exosuit might look like.

My current thinking on the economics of the Exosuit project (October 2019)

In September I started an OSS project called Exosuit. From the beginning I envisioned that there would be an economic component to Exosuit, that some functionality would be free and some functionality would be paid.

Here’s what I currently have in mind.

Free tier

The free tier will offer the core promise of Exosuit: the ability to deploy to AWS as easily as deploying to Heroku.

The premise I have in mind is that you, the developer, have an idea for an app in mind, and you want the path that leads from “I have an idea in my head” to “I have an application running in production” to be as quick and frictionless a path as it can possibly be.

This ease and simplicity will have a trade-off, though: the infrastructure you get when you run git push exosuit master (or whatever) will, out of necessity, be less robust than a full-blown production application with load balancers, scalable instances, etc.

Instead of a complex, sophisticated AWS infrastructure you’ll get a single EC2 instance, a single RDS instance, and the necessary security groups to wrap each. To me this still seems plenty good enough for a brand new app that’s just at the idea stage.

Paid tier

The paid tier will provide tools to help you “graduate” from the simple free tier infrastructure for an infrastructure more appropriate for a successful business application with real users.

Some ideas include:

  • Easy way to put instances behind a load balancer
  • Easy ability to scale instances (cattle vs. pets)
  • Convenient way to build and manage production and staging environments
  • Tools for common operations, e.g. copying production data to staging, recovering from RDS backup
  • Domain management, including SSL

All this is totally tentative and might change. For the foreseeable future I’ll be focusing on the free tier because I see a compelling free tier as the best possible marketing for a paid tier.

September 2019 Revenue Report

My September revenue report is pretty simple: my revenue was $0. Not surprising because I didn’t do any launches.

Here’s my revenue for past months.

2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868