Vercel is a platform for easily hosting static sites and serverless functions. In this new user teardown of Vercel, I’ll be highlighting my journey from the homepage to a deployed React application and all the developer experience takeaways I found during the process.
Discovery - 1/3
Starting things off, I visited Vercel’s landing page to learn more about what the platform offers since I’ve heard good things about it from friends. Unfortunately, the above-fold content was a bit vague on what they offer besides their emphasis on “Develop. Preview. Ship.”
After scrolling down a bit, I learned that they have some credibility with Facebook/Google and users like Airbnb and Twilio using their open-source Next.js framework. The next paragraph over they switch over to talking about how the Vercel cloud platform can deploy any app at scale.
However it became confusing reading some of the features such as “Fast Refresh”, which only makes sense in the context of their Next.js framework. Vercel seems to be blurring the lines between their framework and their cloud platform, making the overall content difficult to figure out which of the two (or both) each feature is referring to.
Features such as “edge on localhost”, replicating cloud features while developing locally, resonated with me as a pain point I would appreciate being solved. However, I wish they named it more clearly. “Edge” is an odd way to describe caching/serverless functions to an unfamiliar user and I’m still not sure if I’m understanding the feature correctly.
Afterwards, I saw their straightforward CI/CD pipeline, the strongest selling point of their platform—to actually deploy apps. The preview deployment system is pretty neat. However, I’m confused if “share and collaborate” is a built-in feature or value that you can get out of the platform via the preview URLs.
After getting the gist of the features Vercel provides, I started trying to sign up before realizing that I didn’t know how much this platform was going to cost me (especially if my app suddenly becomes the next hot unicorn). There was almost nothing about pricing/sales on their landing page, which certainly shows their strong focus on a bottoms up sales motion.
I hopped over to their pricing page and initially understood their pricing per seat model. However, it made me question how I would be charged for bandwidth or serverless function calls and what limits I’d comply with. Those constraints are pretty important as I’d imagine costs would scale as a function of my app’s consumption of resources—not just the number of seats.
After clicking through to read the platform limits, it became... complicated.
This page was a lot longer and more detailed than this
I wasn’t sure if any of these limits would be relevant to me and it was difficult to understand limits (ex. if 12 serverless functions created per deployment was sufficient for me). It led me down a deep rabbithole of understanding how Vercel manages their serverless functions.
I eventually realized that Vercel doesn’t restrict bandwidth or execution time used—which is awesome—but also really hard to understand as a user. The pricing and limits page certainly made a lot of things more complex than necessary and some of the important limits (or lack of limits) should have been shared on the pricing page.
Takeaway: A simple pricing page is great, but if you don’t provide enough detail to what things are priced/limited (or unlimited), your users are likely to start digging into details that they shouldn’t ever need to worry about.
Signing Up & Deploying - 2/3
With the pricing and features understood, it was time to sign up. Overall it was a really smooth process getting my Github account linked. It felt especially good that Vercel only initially asks for email permission from Github, putting me at ease that I didn’t need to fork over code access yet.
Afterwards I chose whether to import a repository or try out a template. I clicked the big blue button and chose to import a git repository, which was straightforward.
After picking a repository to connect, I was faced with this screen.
During the actual sign up process, it was incredibly easy for me to choose “Yes” as a user and proceed since it was clearly my personal Github account. However, I didn’t realize this was actually a plan-based limitation from Vercel only allowing personal Github accounts on the free tier. This worked for me while trying out Vercel, but I would’ve appreciated an explanation of the plan-based limitation at this step.
After jumping through another hoop to connect my Github and Vercel accounts, which seemed extraneous, I was then placed on an oauth screen asking for permission to connect to my Github repository.
What is really nice here is that I can actually scope down Vercel to only have access to a specific repo, which made it super easy for me to feel comfortable trying out Vercel.
After installing, it showed that I was importing a Create React App which increased my confidence that it understood my app and likely had sane default settings. I double checked that the settings were correct anyways, just in case.
While clicking the blue button to go to the next step, I realized that I was actually deploying the app! It was honestly a shock to me that I’ve finished the sign up process. I only realized I was deploying when an in-lined view of the build/deployment process popped up.
Takeaway: It took quite a few clicks to get to the deployment step, but the overall process still felt incredibly fast. It really puts into practice Steve Krug’s quote from Don’t Make Me Think: “It doesn't matter how many times I have to click, as long as each click is a mindless, unambiguous choice.” Every step was a simple form, with a blue button to progress me along.
Post-Deployment - 3/3
Within a minute, my site was deployed and I was greeted with a shower of confetti. It was great seeing a screenshot of my deployed website at this step. It helped me preview my deployed app and personalized the celebratory page.
At this point I was curious what domain my site would be hosted under, since I haven’t specified a domain name yet. Obviously, if I wanted my site to be a unicorn, it has to have a good domain name.
After looking at my site (by clicking the big blue button) and seeing it’s generic domain name, I checked out the dashboard to see if I could personalize the domain.
I clicked through the “View Domains” button on the dashboard to edit my domain name and found a settings tab with many options available. The other parts of the dashboard weren’t particularly interesting, but there was a helpful hint that I could update my production deployment by pushing to the master branch in my repository.
I found it interesting that Vercel put a “View Domains” shortcut directly on their dashboard. I’d imagine users commonly want to customize their project’s domain right after creating their app. This also gave me the incentive to check out other settings I could configure, settings I would not have discovered without the “View Domains” shortcut.
Takeaway: Up-front shortcuts for common user actions can accelerate discovery of other parts of your product, especially those that are adjacent to your user’s intended page.
Overall, Vercel has created a seamless sign up experience. It was a slightly lengthy yet clear process that got me deployed extremely quickly. I was super surprised that I deployed my application without realizing it. At first, I attributed it to me deploying a simple static app, but their Next.js serverless set up experience was exactly the same!
The marketing around their core value proposition was more verbose than needed and failed to distinguish between their Next.js framework and Vercel hosting platform. However, the most confusing aspect was their pricing model. They would benefit a lot if they emphasized their unlimited bandwidth and function invocations but have tiered limitations on how often you can deploy.
Otherwise, Vercel clearly paved out their developer experience and delivered core value propositions that target their end user’s needs. It’ll be exciting to see how their platform continues to evolve. I’m looking forward to taking advantage of their hobby plan—especially with their unlimited serverless function calls—to learn a bit more about serverless development.