Heroku is a popular Platform-as-a-Service that helps developers deploy their applications onto the cloud with very little effort. In this post I’ll be doing a product teardown of Heroku, highlighting my journey from the homepage to the deployed application and all the user experience takeaways I found during the process.
For this teardown of Heroku, my goal is to quickly get my application hosted somewhere so all my friends can check out my latest Node.js application with minimal effort.
As a hobbyist developer, I’m drawn in by Heroku’s well-known free-tier, popularity among my peers, and attractive value proposition of easily deploying and hosting my application. While I know Heroku serves other users from large enterprises that might have different thoughts and concerns, I figured my lens is general enough for a new user approaching Heroku for the first time.
With the background out of the way, let’s dive into Heroku!
Discovery - 1/5
At this point along the journey I’m trying to understand if Heroku:
1. Is something that can host code easily
2. Has a free tier to try out
3. Has free limitations, and how my costs will scale over time
One of the first issues I ran into was the “Platform” marketing around the core offerings of Heroku. While I’m well aware that a “Dyno” (Heroku servers) was what I was looking for, it was unfortunately hidden behind 3 layers of indirection in the navigation panel. While it’s great to know what Heroku has to offer outside of just servers, it’s also excessive in promoting non-server value propositions that really only make sense once I buy into running my apps on Heroku.
Takeaway: Keep your landing page focused on your core value and make sure your information architecture is simple enough to let your users find your bread and butter features.
Their pricing page fares better. Knowing how difficult it can be to provide transparent pricing for complex sets of services (yes I’m looking at you AWS), it’s certainly not easy to lay out the pricing tiers of everything offered under Heroku.
Heroku starts off by splitting up services into different tiers. Here it clearly shows that it supports a free tier and scrolling down lets me know exactly what’s included.
Despite the extremely busy and slightly confusing layout, it still lets me know the pricing tiers, The “See full specs” link gives me a wonderful view of what’s included out of the box, including the limitations and pricing of each tier. It’s very well communicated and exactly what I need.
Takeaway: Pricing tiers for platforms can get complicated, but a clear table of features, tiers, and checkboxes makes it easy to dive into the specifics of each pricing tier.
The Free & Hobby tier is good enough for a hobby-grade project; any other tier is a bit price steep and exponentially increases in cost. Who am I to wishfully think that I’d ever use enough traffic to graduate out of the Hobby tier anyway?
While it wasn’t immediately clear if I could add users on the free tier or if additional users would cost me more, it wasn’t a big enough barrier to stop me from signing up.
Signing Up - 2/5
Now that I’m convinced, I’ll give the application a poke and start to try things out.
While the sign up form was relatively lengthy, it’s worth the hurdle given the generous free tier being offered. Beyond this, there was an email validation step (on top of a reCAPTCHA!) which is bearable considering you’re getting free hosting.
Takeaway: If you give away good stuff for free, your users will likely put up with more friction along the way to get it.
While it’s neat that they’re re-affirming the value that Heroku can provide me, at this point I’m pretty sold that I want to be trying out Heroku, so we press on!
After a quick confirmation email, password set up, and welcome interstitial, I’m finally able to set up my account.
Account Set Up - 3/5
Now that I’m finally inside Heroku, I can start hooking up my application.
I have to admit there were a lot of choices presented before I could start deploying my app. First I had to choose between creating a team or an app, which was an odd distinction as a first-time user. Since I was trying to get anything working, I chose to go with an app. Though it’s unclear if I can still create a team later on or anything else to undo this decision.
Takeaway: If there’s any decision to make in onboarding, it would always seem like a good decision to ease the user into knowing that they can always change it later.
Afterwards, Heroku introduces the concept of adding an app to a “pipeline”, though it’s unclear to me why they didn’t call it a “deployment pipeline” to make it more clear what kind of “pipeline” we’re talking about. Otherwise at this stage as a new user, it’s really unclear to me why I’d care to add an application to a pipeline just yet. I fear that I might not be able to take advantage of Heroku’s easy deployment process if I don’t sign up for a pipeline, so I go ahead and try it out.
Takeaway: When introducing a new concept, especially during onboarding, make sure to explain what additional value they can get, without needing to hop into a pile of docs. Even better, combine it with the last takeaway so they know they can always revisit their decision later.
Deployment - 4/5
Finally, time to run some commands to get my code deployed on Heroku!
One painful part getting the deployment set up was how Heroku asks for access to all repositories in a Github account, even if I just want to deploy from a single repository. This makes it harder for me to feel comfortable using Heroku to experiment with, especially in a corporate setting (ex. Setting up a Heroku test project under your corporate Github account).
Otherwise the only other option is to use the Heroku CLI, which requires installing Heroku-specific tooling to make it work. Not only that, but they didn’t inline the CLI installation instructions which required yet another click to figure that out. On top of that, copying from the documentation was pretty much impossible because of the “$” symbol in the way and a lack of “Copy to clipboard” button to make this a simple one-click affair.
Takeaway: When presenting terminal commands, present them all on one page for easy copy and pasting and please, please, please don’t include the prompt string “$” as copyable text in your command documentation!
However, the CLI experience really shines as the heroku login command seamlessly authenticates via the web app with almost no effort. I expected to fumble around to find an API key in the UI, open up a text editor, paste it in a magical config file somewhere hidden on my computer… you get the gist. The heroku login experience, while not novel, was still by far the most delight I’ve gotten so far.
Now with the Heroku CLI set up, Heroku starts to do it’s magic and deploy my application.
Until this error…
I’ll admit that this was human error on my part of the project set up. However, it’s something that has at least been asked 50 times on Stackoverflow and unfortunately the documentation wasn’t the clearest, nor was the error message particularly helpful. At least it points you in the right direction, and a quick Google search after browsing the docs would tell you an easy fix to take.
Takeaway: Combing through 3rd party support forums might help identify places where in-app messaging and documentation could be improved.
While it was a small stumble in the whole deployment process, and much better than setting up a CI process with other tools, it unfortunately ruined the perfect magical moment of getting the application deployed.
Post-Deployment - 5/5
After the deployment completes the CLI output also helpfully tells you every step that Heroku is taking to deploy your app which makes things easy to debug if things go wrong, as well as the URL of the deployed application. Super handy to then click into that URL to actually check out your application being deployed.
At this point it’s pretty impressive to note that I had to add almost no Heroku-specific configuration to my app. The fact that there’s not a ton to note here goes to show how effortless it is to set up Heroku, which is the largest value for their new users. By far, signing up is the hardest part of getting your app started on Heroku, not the technical parts of getting the app running.
Takeaway: Heroku delivers their core value with minimal effort, which is the most important part of winning user love and showing enough value to have users stick around.
Beyond that, there’s not a lot I needed to do. I attached LogDNA as a log drain to Heroku so I can easily tail, search, and analyze application logs. Outside of that, redeployments are simply one git push command away. The fact that I don’t have to write a lot here goes to show the simplicity of Heroku’s deployment model.
Takeaway: Always have the next step a user can take be obvious, even if it’s the last step to actually leave your workflow. By putting the application’s URL in the Git’s remote CLI output shows the thought they’ve honed in on their deployment UX.
There were a few rough spots in the beginning of using Heroku from an overzealous marketing site to a decision-loaded onboarding process. Heroku could benefit from simplifying the landing page to focus on their core value props while providing an easy way to navigate to their additional offerings. The onboarding process could benefit both in reducing the number of upfront decisions along with reassuring users the flexibility of the decisions they’re making during onboarding.
However, Heroku still provides a solid developer experience, especially during deployment and post-deployment where it really shines. Heroku’s primary value proposition around ease of deployment is shown by how little I had to write about the technical parts of actually deploying the application. There was certainly a magical feel around the seamless login experience on the CLI, no-configuration deployment, and easy transition into viewing your newly deployed site right in your terminal.
Heroku’s reputation among developers is certainly well deserved. I’m looking forward to using Heroku to host more of my future projects!