As a way to incentivize the sharing of demos, Paper Audio has an api deployed to Alexa and Google Actions, and I am able to feature a ‘demo of the day’ to voice speakers. This separates my project from places like Instagram where musicians are already sharing, and, it allows the project to be enjoyed without screen time (and without giving more time to Instagram!)

At the time of writing, Paper Audio only allows the ‘demo of the day’ to be played on voice speakers. I personally select the demo of the day. Though this is a bit more gatekeeper-y than I’d like, it actually has to be this way; the Alexa Skills store forbids unmoderated user-generated content. I actually had to address this directly with Amazon in the submission process — maybe I’ll say more about that in another post. At the very least, all user submissions are shown on the web on the ‘explore’ page.

On to the tech stuff:

As with all side projects, I was hoping to learn as much as possible, while also trying to actually ship and maintain high leverage in terms of throughput and platform support. TypeScript is my strongest programming language, so that was definitely a big factor in my selection of frameworks and tooling.

Voice platform support: Jovo

Jovo is an awesome framework for writing apps for voice platforms like Alexa, Google Home, and more. This react-native like premise of write-once-deploy-everywhere made it a natural choice for getting Paper Audio to work on multiple platforms. I’d used it before for an incredibly simple Alex Skill called “Pitch Player”, which is basically a pitch pipe. Ultimately the logic in the voice interface is deployed to AWS Lambda, and is called by Alexa and the supporting Google devices. In turn the Lambda calls the Paper Audio back end, described below.

What I loved about working with Jovo:

• Write once, deploy to multiple platforms
• Built-in TypeScript support
• A great web-based debugger
• Lots of tutorials and examples

What I loved less (these things may of course change and become outdated)!:

• Managing metadata (images, descriptions, etc) for my products in the Alexa Skills & Google Actions portal. You can fetch this metadata via the jovo cli, and then later push it, but it can be tricky to understand what fields map to what values in the portals. I suppose this is the price you pay when you try to target multiple stores, and you can imagine that this is not easy for the Jovo framework, as there are no incentives for Google and Amazon to cooperate in making this straightforward.
• Some examples and tutorials have become outdated, and some areas are not as well documented. For example, I used the Google Conversational Action builder pattern, which seems slightly less conventional than using DialogFlow when using Jovo.

Back End — NestJS

I used NestJS for the back end of Paper Audio because it seemed to be a very ‘complete’ node solution with native TypeScript support, and lots of ‘opinions’. I didn’t want to spend a lot of time sewing together lots of express code myself. I wanted something that would more or less let me define a data model, and then do most of the ‘boring’ work for me. I also knew I wanted GraphQL and Apollo support since I’ve used the Apollo client with React in my job, and I’ve loved the end-to-end typesafety that is available with this approach. Postgres backs the app via TypeORM, because, why not use Postgres?

I’d use NestJS again without much hesitance. On my next project, I might even go a step further into convention over configuration and use something like RedwoodJS or Blitz.js, effectively taking the monorepo approach to the web front end and back end. As an engineer I have already spent too much of my career solving the same familiar CRUD problems. CRUD is not terribly interesting, so it seems best to use tools that allow one to spend more time on the challenges unique to a particular application.

Paper Audio’s NestJS back end is deployed to a digital ocean droplet via Dokku. Dokku doesn’t quite seem like the cool new thing in town, and my architecture here isn’t perfectly ‘web scale’, but it was very easy to configure (there was no chance I was going near Kubernetes for this), and offered me more performance per dollar than heroku, and allows me to deploy via git push dokku.

Web Front End — Create React App

The front end that you see at https://paperaudio.com is a react app written in TypeScript and deployed via Netlify. I used create-react-app here, and built the UI with ‘Material UI’. Next.js would’ve been the ‘cooler’ thing to use here, but, for now I just don’t need its features, and was already more familiar with create react app. Material looks a little android-y for my tastes. If I were to start over, it’s likely I’d try tailwind in its place.

Other Lessons & Conclusions

I wish I’d ‘built in public’ more

Building in public has become a very popular strategy, and it makes sense. If you don’t talk about your projects early and often, the odds go up that you are building the wrong thing.

I’ve done some work to recruit users, but I should have been writing and talking about Paper Audio even before I started the tech work. I could’ve done what so many do and explained the product with a splash page and worked to develop a user base, so that I’d have users at ‘launch’, and so that I’d more likely build what users might want. It also would’ve helped keep me motivated and excited about the project.

Captcha? Really??

At the last minute before ‘launching’, I had to add Captcha to the sign up form. I was getting hundreds of emails sent per day from my server from stupid bots filling in my email form. It’s really annoying, and I still can’t understand how the incentives could be there for anybody to deploy these crappy scripts to just pollute the internet with garbage. I could’ve used Auth0 for user management to avoid this issue, but my simple sign up flow was generally working, so I decided to make the UX a little worse with the Captcha approach to avoid the abuse.

The need to ship known bugs & imperfections

This is a tough one. There are lots of known issues. My favorite is a timezone bug: Alexa and Google Home will change to the next day’s demo at midnight UTC, while the web app behaves the way one might expect in that it will change at midnight browser time. It turns out it’s not quite that easy to get the local time of both Alexa and Google devices. And of course, this is far from the only issue in the project. The perfect is the enemy of the good, and if nobody ever uses your product, the bugs don’t matter at all!

If you liked this, consider following me on Twitter!

I’m talking about pursuit and achievement of long term-goals here.

Whether your goals are matters of fitness, business, music, finances, or anything else that will really make a difference, I think it’s important to understand that one-time, one-off efforts are roughly as useful as no effort at all. Maybe one day you pack lunch instead of buying it on your lunch break. Great. Do it again. And again. You just can’t move the needle enough doing it once. Maybe you practice bass for a few hours on a given Tuesday. That’s great, but you’ve got to keep it up. That tough workout? You plan to do it again in two days, don’t you? Don’t blow it.

It’s not all doom and gloom though.

There’s a truly positive element of all this that is worth considering. I’m definitely a fairly anxious person, and life’s mundanity can cause a lot of discomfort. This long game of consistency can provide some comfort from those problems. Once you internalize that it’ll take many days of consistency to get to where you’re going, you can turn that mundanity into a positive thing, in that you’ve been given the chance to chip away at those goals over and over again.

Furthermore, you can also use this concept to feel good about time off. The effort from that one prospective work day or week wasn’t going to matter too much by itself, anyway. Understand that and unplug.

It’s also worth noting that this position only applies to longer-term goals. When it comes to random acts of kindness, one-time events are hugely important. Try buying coffee for the person next to you in line. I know that when somebody does this kind of thing for me, my entire day is made. We’ve all felt that great feeling.

This is also one of my favorite qualities of musicians.

It’s one of the things that amazed me in my time at Berklee. I encountered people with drive and desire that I can barely describe. One such person is Matt Garstka, one of my roommates in my freshman year. Matt would practice for eight hours per day in many cases, only to return to his room to practice quietly on a drum pad. Here’s one of my favorite videos of Matt’s chops:

Get out there and be what you dream to be, one day at a time.

Find a niche

Preferably, find a niche in which you have special domain knowledge. Finding a niche will allow you to have less competition, and if you believe Peter Thiel’s monopoly theory from Zero to One, this is a great place to be. I also believe that focusing on a small set of important features makes your app more valuable. No matter what you are doing, you want it to be frictionless. Read more about picking a niche in the very useful series from Trevor McKendrick

Work on a hard problem

tuneUp doesn’t really fit this criteria, although I think it’s important. First, it keeps you interested. If you are reading this as an indie developer I suspect you may have another full time job. Part of the point of side projects is exploration, and it’s certainly easier to stay interested in a problem that you find challenging.

Also, as a side benefit it protects your niche from being gobbled up instantly from competition. Think about the flappy bird knock-offs.

Don’t ship anything that has no chance of being featured by apple

Here’s another one I cut corners on, although as I mentioned I was just trying to get this thing out the door. Depending on your niche I do believe getting featured eventually might not be as hard as it seems, and it would make a world of difference. Keeping this in mind will also help sharpen your design skills.

Instrument your app

Until the very recent rollout of iTunes Connect’s analytics, if you were to make an app and ship it without adding any analytics, you’d end up very bummed out after your launch. Sure iTunes Connect will tell you how many downloads you got the previous day, but that’s about all you get to know. Wouldn’t you like to know what buttons people are pressing? How long they are in your app on average? If they come back? It’s easy to add localytics, mixpanel, google analytics, segment.io, or any of the dozens of tools available. If you don’t do this you’ll be sad that you didn’t. Also, you’d like to know if your online marketing is driving downloads. Good luck understanding and comparing marketing campaigns without any instrumentation.

Don’t underestimate users’ interactions with each other

Something as simple as integrating with game center will show you how important this one is. With tuneUp, somebody scored over 50,000 points on the easy setting. This person went through more than 500 pitches in a single game, which is an astounding number. The reason is that this person wanted the top score on the leaderboard. In my next app I may try to build a platform for more sophisticated user interactions. However you address this topic, I recommend at least touching on it.

Market it

Unfortunately the app gold rush days are over. You’ve got to do something to drive downloads. Ad platforms like Facebook, Twitter and AdWords all give promotional credits for new users. Don’t throw away free money. Also, this is another reason to instrument your app. If you are able to pay $2 per download on average and make $4 per download, you’ve just found a gold mine (yes it’s very hard to find this kind of opportunity). You’ll need code in your app to really track the effectiveness of these campaigns. Get it setup before launch.

Don’t blow up your own launch

Here’s one where I really screwed up. After your app is approved, when you pull the trigger to deploy the app, under no circumstances should you pull it from the App Store. You get a big boost in app store rankings for being a new app, do not give it away. If you find a bug that you think is really a deal-breaker, rush to get a new version out, but do not pull it from the App Store. Look what happened to me after I pulled the app because I found a bug. This chart from mobileDevHQ shows the placement of the app in the App Store for the keywords “ear training”, at launch and second launch. Don’t let it happen to you.

Track it

Use a tool like SensorTower, App Annie, MobileDevHQ, or one of the others to track your placement in the app store. This way you can plan for future updates and even future apps, in addition to tracking your marketing efforts. On these platforms you can add competitor apps and chart what works and what doesn’t.

Hopefully this is a useful resource to other app developers out there. There are plenty of posts out there just like this one, and I recommend doing a bunch of reading before you ship so that you don’t make the same mistakes as others before you.

I didn’t take great notes throughout this process, though I’m hoping I can help get some others moving in the right direction for getting ember.js and ember CLI running on github pages, with a few other notes about getting Jekyll in place alongside ember.

Start by installing ember-cli and creating a new project via ember new myWebsite. The next thing I did was remove the dist folder from the .gitignore file. The reason for this is to be able to deploy with a single git command…tracking your build folder is a big no-no but this is quick and dirty. I recommend the cli addon mentioned in my edit above.

Next, I setup the git origin to point to my username.github.io repo. Then, I added the following alias to my .aliases file (although .bash_profile or elsewhere would certainly work:

alias pushSite="git subtree push --prefix dist origin master"

With that in place, the general deployment strategy would be to make changes, ember build, git add and commit, run any tests, then run the alias to deploy to github.

Adding Jekyll

Github supports Jekyll out of the box for its pages, but since we want ember at our root path, we’ll do a classic Jekyll installation, without using the github jekyll builds. First, gem install jekyll. Then, in the public folder, jekyll new blog. I then went into the newly created blog folder and modified _config.yml file to include:

source: .
destination: ../public/blog
baseurl: "/blog"

With these new additions, we now build our blog via jekyll build from our blog folder. This prepares the ember /public/blog directory, and we just use the aforementioned process to deploy the whole site.