Micro product launches == developer therapy

I just completed the second and final weekend of a two-weekend hackathon with a 3 month gap in-between the weekends.

I was joined by an old friend turned developer in the interest of creating a small project together. Our requirements included project self sufficiency and limited future maintenance. We had little interest in curating social networks or dealing with custom requests.

It was important to set goals that we could actually achieve. To do that, we had a few ground rules:

The (10) Rules

1. Above all: complete the project
2. Enjoy the time in-person. I live in New York, he lives in DC. That means one of us will be traveling. This is still and always preferable to remote work
3. Ample coffee available
4. Ample beer available
5. Don’t shy away from great food, but do stay conscious of time
6. Learn new things, but don’t force new things (see rule #1)
7. Confine the necessary work to the weekend. This was especially important given the time between our weekends
8. Wake up early
9. Lean on each other’s strengths and trust the other person to do their job
10. Repeat rule #1

We did hit our release, but I didn’t want to make this about self promotion. So if you’re really interested you can hit me up on Twitter.

The more important goal here is to dissect the good and bad aspects of these micro product releases. I’ve learned a lot about technology, my relationships, my increasingly-limited time, my risk tolerance, and some of my other interests.

Photo from Dan Carlson

Defining a micro product

Stage one of our process was to choose the direction we would go and aggressively limit our scope. We definitely noticed that common knowledge is anything but common. Every product sector has layers of hard-earned knowledge. This is why it’s hard to beat subject-matter experts as co-founders.

Our highest depth of knowledge is software development. This inevitably means that we suffer from a slight lack of substance on most other things. This is to be expected. It is also something I wish more people understood about developers.

The Good

• We limited the feature set on our initial concept. What we released actually looked a lot like our original plan.
• We planned & implemented a one-and-done, paid service. Every interaction happens within a single session. Customers receive emails upon completion. No long-term relationship with customers, no community curation (both time-intensive).
• We built marketing and communication plans into our weekend work schedules. This was new for me. It was incredibly eye opening and successful.

The Bad

• We underestimated the crowded-ness of the market (domain registration tools). This was both from a features perspective and a marketing perspective. Our ad budget per click is far lower than much of the competition.
• We decided not to focus on SEO, choosing an AdWords strategy instead. It was probably the wrong idea, in hindsight. This is given the low cost of the service ($9.99 — $18.99). Pay-per-click advertising is very expensive when you have low conversion value like this.

The technology that made the cut

The greatness of most technology is very context dependent. If speed and minimal effort is a goal, then Get Up and Running, Quickly is my slogan to win the day. This is not to say some of the tools in the bad section are not good in other contexts.

The Good

• facebook/create-react-app: was the first and obvious winner. I had not used it yet. I had priorly favored generators that bundled client and server into the same generator. I think the Facebook slogan for the repo says it all: Create React apps with no build configuration. JavaScript fatigue anyone? Not dealing with a build was the joy of our lives.
• claudiajs/claudia: I actually wrote another article about that here. Claudia saved us from dealing with the medium to high level configuration knowledge that was sucking time out of our development process. We wanted a simple API, we wanted to make changes, we wanted to be able to deploy it and have everything work.
• S3 static hosting: Initially problematic, but with some great tutorials from Kyle Galbraith here and Sebastian Buckpesch here, we were able to get it up and working very well. You can’t beat the cost and the caching advantages are also very real. For a client that is merely hitting an external (or Lambda) API, it’s hard to do better for a micro product.
• Stripe: It’s hard to say enough good things about stripe’s fantastic API and integration. They’ve made payment processing on the web into a pure joy.
• Mandrill: Been using it for years, and hard to go with something else at this point. Even though it’s no longer maintained, I was happy with the ease and syntax of rschmukler/powerdrill from Ryan Schmukler.

The Bad

• serverless/serverless: Originally looked like the right tool for the job. For the better informed on AWS Lambda, it probably is the right tool for the job. For our case, messing with different configurations on Lambda became too much of a distraction and threatened to derail our momentum on the project.
• webpack.js: I use it everywhere. Once facebook/create-react-app was in the mix, the value-add for webpack was very limited. Anyone who has worked with webpack knows that it is in the business of configuration headaches, so it was nice to get it out of the way.

Supplement resources for the win

We engaged in some education. Aside from the standard Stack Overflow and frantic solution searching, there were a couple other things that helped us through the process:

• The Ultimate Google AdWords Course from Isaac Rudansky. I took the first three sections to get us up and going. This thing is a beast. Very valuable. Very plain spoken. Very excellent advice on how to get up and running with Google AdWords.
• ThemeForest Bought a great looking template for $65.00. Quickly converted it into React components with no fuss. The template adhered to bootstrap standards, so applying existing classes was trivial. To be clear, the template did not look like Bootstrap, it just applied the standards.
• The Claudia JS Example Projects It cannot be said enough that this is a great way to document an open source library and its API. Learned a ton, and hope I was able to give back with my videos here.
• WanderU which came in handy for bus and train tickets in the northeast corridor.

Why Therapy?

In four days of work and good community, we managed to release a client/server application with reliable connections to 5+ APIs. It serves a basic need for customers. It has viral marketing built into the checkout process. It processes payments via stripe. It has a detailed, thorough AdWords campaign behind it. It works well on desktops, mobile, and tablet devices. We don’t hate the code and we don’t hate ourselves.

It feels good to say that.

That’s the therapy part.

What I’ve Learned

My desire to create and release products is a disease. My cure is not in sight.

The conclusion of the project was bittersweet. We can no longer focus on the next developer milestone. We have to see if customers are actually interested. That is the biggest test of all.

I do believe that the ability to create things with little cost pushes developers to write a line of code before it’s necessary. My future attempts will likely undergo a greater degree of market testing. Given that, I think we have learned a great deal and should be able to apply it more surgically when the next thing comes around.

Photo from Artem Sapegin