Author Archives: Jason

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

I’ve quit freelancing for the indefinite future

Over the last 8 years I’ve spent a lot of time studying, thinking about, and writing about freelancing. I’ve been a freelancer on and off—mostly on—since 2011. I had had a dream for a long time of building a high-income, low-labor lifestyle as a successful consultant, kind of like what Alan Weiss has done.

Since I’ve written a decent amount about freelancing on this site in the past, I feel it’s appropriate to give the following update: I’ve given up on my freelancing dream. It’s a good thing, though, because the only reason I decided to leave the path I was on is because I found what I believe to be a better path. (Also, I discovered that freelance programming is basically a sham and 99% of “freelance” programmers are just contractors and glorified employees and that the kind of success I was fuzzily envisioning is not really possible, but that’s a different story.)

What’s the new path I’m on? I don’t want to get too much into the details publicly but I’ll say that I’ve found myself in a monogamous relationship with a client who I like more than any other client I’ve worked with. He and I have been working together for just over a year. All the aspects of the working arrangement are good, about as good as one could hope for. It’s basically a job, but a really good job. I expect that my client and I will work together for many years to come and I don’t expect to be working with any other clients on the side during this time. So, no more freelancing. I’m not saying never again, because who knows what will happen 5 or 10 years from now, but no more freelancing for the foreseeable future.

What I’m NOT ready to give up on yet, or probably ever, is my endeavor to build a successful product business. I don’t think that part of me can ever be killed. You can follow my progress in that area in my Entrepreneurship Journal.

Suite Magic test runner: project aborted

Recently I had an idea for what I thought was (and still think is) a good idea for a product: a test runner/CI tool that can run any Rails test suite in about 30 seconds, no matter how big the test suite is. I even had a rough proof-of-concept working.

However, I decided to abandon the project. The reason is simple: I realized that the work involved in building this product/business would almost certainly be too much. As someone who earns my living working more or less full-time doing coding (and as someone who has a wife and kids), I can only afford to put in so much time per week on side projects.

I know the pain of trying to take on something too big because I’ve tried it before. From early 2011 to late 2015 I tried to build a business selling hair salon scheduling software, and among other reasons for failure, I was never able to achieve “escape velocity” due to the limited amount of bandwidth I had to work on the business.

So, that’s my reasoning. Now that I’ve made that decision, my plan is to continue to focus on blogging about Rails and making Rails podcasts, which I do at CodeWithJason.com and the Rails with Jason podcast, respectively. As I move forward with these things I intend to keep my eyes open to other entrepreneurial opportunities.

August 2019 Revenue Report

Unlike June and July, I did do a launch in September. I didn’t launch a course like I was planning, and nobody bought the service I launched. But I did relaunch my book and made $327. I launched to roughly 100 new subscribers and made 5 sales, so about a 5% conversion rate, not bad.

Incidentally, I also sold a copy of the Angular for Rails Developers video package for $99. I didn’t even realize that that product was still purchasable. I guess it is since someone bought it.

Below is my revenue for every month worth mentioning.

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

July 2019 Revenue Report

July’s revenue was low for the same reason June’s revenue was low: I didn’t do any launches. In both June and July I was focused on building my email list.

I’m writing this on August 5th, 2019. This week I’m launching a new service. I plan to launch a course next month. Hopefully after those things happen I’ll see an increase in revenue.

Below is my revenue for every month worth mentioning.

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

June 2019 Revenue Report

I made exactly $0 in sales in June. This isn’t too surprising as I didn’t do any launches. During June I was focused on building my email list.

Below is my revenue for every month worth mentioning.

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

May 2019 Revenue Report

In March 2019 I launched my new book, Rails Testing for Beginners, and made $988 on the launch with a couple sales later in the month.

April was launchless. My revenue was only $98.

This month I launched a video package to accompany the book. I earned $481 which was less than I expected but in hindsight it makes sense. My list hadn’t grown much since the book launch so almost everyone who got the video launched to them had already had the book launched to them. I did the math afterward and out of ~700 email subscribers, about 5% of them ultimately bought something, whether it be the book by itself or the book + video package. A 5% overall conversion rate isn’t bad.

Now that I have this higher-tier product my focus for the next while will be to get a bunch more subscribers to launch to. I’m tentatively thinking that I’ll wait until I have at least 1000 subscribers to do another launch.

Below is my revenue for every month.

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

How I uncover genuine pains in technical watering holes

Note: this post is targeted at my fellow 30×500 students and might not make sense to anyone else.

A common problem students encounter in 30×500 is that we come across watering hole posts that are purely technical and have a short and clear answer.

Example: the question “how do I reverse an array in Ruby?” has a very cut and dry answer: Array#reverse. There’s not much more to say about it. This question isn’t really a pain, just a question.

The kinds of posts I prefer to find are ones that say things like: “No matter how much I read, I can’t figure out how to get started with automated testing. What can I do?” There’s a LOT to say in response to this question. This question reveals pain, pain that can be addressed with an ebomb.

I’ve often used a special google query to help me uncover pains. It looks like this:

rails testing confused inurl:forum

The inurl:forum part scopes the search to URLs that contain “forum”. The “rails testing” part is the topic under which I’m trying to uncover pains, and “confused” is one of several “pain words” I’ll plug into this query. I might run through several, like this:

rails testing confused inurl:forum
rails testing frustrated inurl:forum
rails testing stuck inurl:forum
rails testing confused inurl:reddit
rails testing frustrated inurl:reddit
rails testing stuck inurl:reddit

Here’s the full list of “pain words” I’ve come up with so far:

confused
frustrated
stuck
lost
painful
don’t understand
don’t get
struggling

Once I find posts via my queries, I of course safari those posts and then write ebombs addressing the pains.