Phoenix Igniter

I just finished integrating Phoenix Igniter with Gitlab and Stripe yesterday to make everything self-serve. 

Previously, I'd given access to the alpha version for free to 100 of my paying subscribers for my other product, Alchemist Camp, but now it's possible for anyone to go to phoenixigniter.com, sign up via Gitlab, buy a licence for the starter kit and get access to the repo on their own.

The surprising thing is that I haven't even emailed the people on the waiting list. I haven't shared it on my YouTube channel and I'm not even linking to it from my main website, yet! I wanted to get some docs written before sharing the new product more broadly, but someone already went through about bought it! 🎉

The customer was also kind enough to email me and share some of his background, too. The reason he bought is because he's been learning Elixir from the free tutorials I put on YouTube and he likes them. In essence, no email sales were necessary because my educational materials had already built enough trust for a one-off sale. The fact that it's discounted for people who sign-up before it's finished is probably a help, too.

The main takeaway here is that if you're building a second product, it pays to find more ways to help the audience who already trusts you.

Two days ago, I dramatically reduced the scope of the project. I got a landing page up with a ConvertKit form on it yesterday, and I started getting signups today.

All I did was mention it at the bottom of an email update to my existing email subscribers for Alchemist Camp and tweet it once (to about 800 followers). The result was over 50 signups, zero of whom are paying Alchemist Camp members (since I'm giving them the template for free while it's in development). About 2/3 came from my email list and 1/3 came from the tweet.

I've already gotten two really positive email responses, too! 🎉

While having lunch with one of my good friends, I explained a bit about what I'd been working on and he asked me, "why don't you just make one version and launch that?"

And he was right. Not only does flexibility make it a lot more work for me, but it's totally unnecessary for launch. Most people don't want an endlessly customizable meta-template that requires them to make a lot of choices. Just the power users do. A lot more just want a single blueprint based on my choices, as long as those choices work for them or are easy to revert.

A couple of years later, I was in a much different situation. I'd long since let my startup slip into zombie mode and I'd built up a lifestyle business around Elixir screencasts that was finally pretty much covering my living expenses.

I had thousands of followers on YouTube and on my email list. Many in that audience were working on projects of their own and could use the same sort of starter kit that I could have a couple of years before. I was in a great position to write that starter kit, so I told my subscribers I planned to.

Not only that, but it was one of the things I'd identified as an opportunity while doing 30x500, and it was one of only two ideas to survive the "idea grinder" portion of the Nugget.one course.

Fractal rabbit holes

I saw the power in Rails templates and was very interested in setting up something similar for Elixir. I also drew inspiration from how Vue CLI and similar tools in the JavaScript ecosystem allow for users to interactively make a few decisions about what kind of app they want to generate from the command line.

I didn't want to add another layer of complexity for users by adding requirement that they already had another language installed and I didn't want to risk version or toolchain conflicts, so I decided the best option would be to write a native CLI in Rust to generate the desired Elixir code based on settings in a config file. I.e., they could choose to generate an app with the following options:

• full-stack app or a pure back-end API
• email-based auth or social media login
• SASS or PostCSS
• LiveView or a JS library
• dockerized or not
• etc...

And the result was, the project had become way more work than I had time for.

I was up to my ears working on a solo startup that I'd barely been able to raise any money for. I'd already rewritten my app's tech stack three times—very early on abandoning JS for a Ruby on the back-end for productivity reasons, then moving to Elixir for performance reasons, and finally ripping out all the Twilio APIs I was relying on for WebRTC since they raised their prices by more than 100x on me.

Using Elixir was great, but there weren't a lot of libraries past the very basics. I ended up writing a lot on my own. I wrote my own Auth, my own API wrappers for half a dozen services and worst of all, I had to make my own UI components. Of all the things I needed to spend time on, I didn't want to be spending it on that.

Then somebody shared Laravel Spark with me. I'd heard of it before and had a very vague idea of what it was, but when I took a good look at it, it blew me away. I saw right away how much time it would have saved me if I had something like that for Elixir.

I was busy, so I wrote a couple of sentences about it in my journal that afternoon and didn't think about it again for more than a year.