Vercel Pricing and Billing Teardown (What Works & What Doesn’t?)

In this panel discussion, host SPEAKER A and co‑founders of Schematic (Ben, Jazz, Geo) dissect Vercel’s pricing strategy, billing experience, and product‑market fit. They begin with a high‑level overview of Vercel’s business, funding, and positioning as a Next.js‑centric developer platform. The conversation then dives into Vercel’s pricing model, noting a hybrid seat‑based tier (hobby, pro, enterprise) layered with three usage‑based metrics—edge network, edge data, and compute. The panel critiques the seat‑based metric as potentially misaligned with value, especially for automated or small‑scale users, and debates whether a platform‑fee model would be clearer. They compare Vercel’s pricing to competitors (Netlify, AWS, Cloudflare) and highlight Vercel’s premium positioning based on performance, SEO, and developer experience. The pricing page’s design is examined: a simple hero for hobbyists, deeper sections for enterprises, extensive use of documentation links to sell features, and a large FAQ. Opportunities identified include a pricing calculator, clearer ROI framing, and potential CRO concerns about linking away from the page. The billing experience is described as highly transparent, with separate usage, plan, and invoice sections, granular add‑on controls, spend management tools, and role‑based access. The panel discusses typical expansion paths (scale of usage vs adding projects) and reflects on Vercel’s brand confidence and transparency. Finally, each participant rates the pricing page and billing experience around 4–5 out of 5, noting strengths in depth, clarity, and alignment with developer needs, while pointing out areas for simplification and better alignment of seat‑based pricing.
Chapters
Hey everybody, welcome to another special edition of Monetizing SaaS. Over the past few weeks, we've been doing teardowns of pricing pages and billing experiences for standout developer tools. Last week we dove into Linear. Today we're tackling Vercel. This is going to be a big one. Vercel, as everybody knows, is a leader in the developer tool space around infrastructure. For some quick context, Vercel was founded in 2015, and if you don't know, they've raised over $550 million in funding. They now employ around 600 people. We're guessing based on, you know, back of the napkin math, this is a company that has exceeded $100 million in ARR. What do they do? Their platform helps developers quickly build, preview, and deploy modern web applications. People buy Vercel for its focus on speed, its ease of use, its seamless integration with popular frameworks like Next.js, which they maintain. The gap they filled when they started the company, well, before Vercel, deploying and hosting web applications required piecing together tools for infrastructure optimization, scalability. Vercel simplified this process with an all-in-one solution designed for the specific needs of front-end teams and modern web apps. So today we're going to look at how they connect their product experience to their pricing page, to their billing journey. We're going to look at how they package their features into tiers, how they enable upgrades, the design of the purchase experience from, for both individual developers as well as large-scale organizations. Joining me today are Schematic co-founders Ben, Jazz, and Geo. We'll highlight what we think is really good about what they're doing from a pricing and billing perspective. We'll also try to identify opportunities that we see. So let's get into it. Geo, can you share your screen?
Yes, let's do it.
Jazz, maybe you can kick us off today. I'd love to talk about kind of what you've observed around Vercel's pricing model, inclusive of their price metric. Can you give us a little bit of a voiceover of, you know, kind of what you've seen, price metric, packaging schema, just give us the kind the 10,000-foot view?
Uh, yeah, I mean, it's— I mean, you know, it, it is infrastructure, right? So it's just like a relatively complicated pricing model. Um, and so like if you go through it, you can— I mean, there's just like a ton of dimensions. Um, it is, you know, this space obviously has developed over the last decade. Um, who are they competing with? They're competing with folks like Netlify, competing with folks like AWS, uh, Cloudflare, uh, a lot of other smaller competitors that are kind of in the space as well. But if you're kind of building on Next.js, like there's almost no reason not to use Vercel, at least when you're starting out. Right. Um, and so that's, that's kind of their top of funnel. That's kind of like how they get, um, opportunities. Um, and then, you know, obviously a huge sort of user base. Um, when you look at the pricing model, I think it's like relatively straightforward. It kind of mirrors Netlify and mirrors kind of other sort of folks too, but you've got a hobbyist plan that's really oriented towards individual developers. You've got sort of like a middle tier that's oriented towards businesses that are just starting out. And then enterprise tier, right? That's kind of oriented towards kind of like those enterprise features that you're always accustomed to. SLAs, SCIM, advanced support, access control, sort of security features that you see in the top tier. I think what one thing to sort of like maybe hone in on notice for Vercel is that they kind of win mostly on probably three dimensions. They tend to win on performance, they tend to win on SEO, and they tend to went on personalization. Those are kind of like the three sort of dimensions that Vercel is really competitive on. And that doesn't mean that AWS, Cloudflare, Netlify aren't good at those things. They're just not optimized as well as Vercel for Next, right? You know, arguably Cloudflare is better in the edge network, right? AWS is incredibly configurable, better at compute. But they sort of excel on these 3 vectors specifically for Next.js. And obviously, they're competitive broadly as well. But when you look at their price metric, right, there's kind of 3 dimensions that matter here. And you can kind of see it when you kind of go through their pricing page. So if you go slowly, Gio, you'll see edge network is one of them, right? You keep going, edge data is another one, and compute is the other. They sort of represent 3 different types of things, right? So depending on what you care about as a business, right? Edge data generally, what that's sort of like the purpose of that, what it sort of means is that you're storing data close to a user, right? So that might be sort of like personalized settings, configuration data. Companies like Spotify, you can imagine might cache playlists or recommendations on the edge. And that might be really sort of beneficial for them. So edge data is really important. There's edge network, right? Which is sort of delivering static or cached content super quickly to the user. You can imagine folks like Amazon, which have a ton of things that they need to sort of serve to the user at any given time. That's really important. And there's compute, right? Which is sort of backend, right? The ability to kind of run lots of logic on the backend relatively quickly. And that's super important too. What you'll notice if you compare all three of these to other folks, you know, let's take edge with Cloudflare. They're just going to be more expensive, right? Compute with AWS, they're going to be more expensive, right? But they went on convenience. They went on sort of like this ecosystem alignment. And that's, that's why people use them. And so what tends to probably happen is if you go up to the top of the page, hobby, pro, like getting started with Vercel, super, super easy, gets relatively expensive as the business grows, right? And so what you probably tend to do is mix and match infrastructure as you move from pro to enterprise., or you get, you know, some kind of deal for them, at the very, very large scale. Um, because it's, you know, you're, you're talking about, you know, you look at AWS, this is orders of magnitude more expensive on the compute side, um, than, uh, than AWS. So, um, anyway, just a high level, right? Um, I think they win on this ecosystem alignment. They win on convenience. They win on developer experience. Um, certainly not the cheapest option, but those are the three sort of price dimensions. They tend to operate across.
Yeah, that's awesome. And so to dig into the price metrics just a little bit further, it sounds like what you're observing, tell me if this is wrong or right, is like they make it really easy to get started with like what is effectively a seat-based metric. But if you're going to start to use Vercel at any type of real scale, you'll also pay for very, it looks like 3 different usage-based metrics on top of your seat-based metric. Is that correct?
Right.
I feel like the seat-based metric is probably marginal. At best, like it's probably not the most expensive thing once you get to a real business scale, right? Um, and then it really depends on what you're maximizing for, right? Maybe you're maximizing for all three and you sort of, and they kind of flex across all of them. Um, but, um, but I imagine, right, you're going to care about one of these things over the other, um, depending on the business that you're, you're sort of operating.
Yeah, yeah, it's an awesome high level. Ben, I want to ask you for, for your reflection on what you like about their pricing page as well as anything you feel like is, is kind of a potential opportunity, um, you know, it would, it would serve you even better than their current pricing does.
Yeah, for me, I think like the real elephant in the room here is, I mean, this screen, I, I do find it a little bit strange for, you know, I would, I would call for sale like a PaaS, a platform as a service, like, um, having your leading kind of the summary of your pricing be seat-based is a little strange, right? Like we talked about Linear last week, how, um, like the seat-based pricing may or may not be ideal for like their company's revenue growth, but, um, it's hard to imagine a different price metric. In Vercel, it's kind of hard to imagine— it just seems very counterintuitive to do seat-based pricing to me. Um, and it's like a, a very lead-bearing thing in my mind because Um, at the beginning, right? Like you don't pay much for Vercel, like Jazz was saying, like it's cheap, easy to get started on. And then as you scale, like you might start incurring more of these usage-based costs, which means like probably not a lot of people are paying mostly seat-based pricing. And then as you get bigger, like you're probably automating your Vercel deployments in a way where maybe you don't even need that many seats. So like, for example, with Schematic, we use Pulumi. Um, and for our production deployment, there's a Pulumi connector that actually does the deployment to Vercel, which is different than their out-of-the-box behavior, which is just by default, the Git integration is turned on. So when you push to Git, it deploys. And the reason we do that is so that we can know where in our sequence of things being released the Vercel deployment happens, but, um, not to save money, but realistically, like if you automated all of that, you wouldn't necessarily need so many seats. Um, in our case, we only, we are a Vercel customer and we only use Vercel for fairly simple front-end parts of our stack. And so we actually do basically just pay for seats. So it's a little bit of a strange billing model for people in our situation specifically. Unclear to me how many people are in that type of situation, but either way, it seems like an odd thing to lead with to me.
Is it odd because it leaves money on the table for them or because it doesn't feel sort of aligned with the value that we're getting from the product?
In our case, it's definitely unaligned, right? Because, um, I don't think there's much connection between the number of developers we have on our team and the value we get from Vercel. Um, I do think like, like Jazz's point around like the enterprise stuff, it makes sense, right? Like that's usually where you upsell people is things like SKIM and this managed WAF rule sets. Like that's like a clear, like enterprise feature. The SLA, it's always interesting when companies advertise their SLAs, like First of all, 99.99% is like, uh, it's good, but also my understanding is that like a lot of Vercel deployments run on AWS, right? Like it's, I think it's a lot of, a lot of the deployments are using like S3, CloudFront, Lambda, right? And those services have 3 nines or at most 4 nines, right? So like, it makes me curious if I know that it makes me curious, like, is that SLA legitimate? And if so. It would be impossible to have a 4.9 SLA when one of your dependencies has a 3.9 SLA. So how does that work? You know, that's a bit of a thing that strikes me as odd here. Um, overall, like the seat-based thing, I find the like social proof piece interesting as well. Like I think the names we saw there, if you scroll down, it's like eBay.
Yeah.
Um, yeah, Box. These are big, big, big names. And like, I mean, especially has had tons of ink spilled about how they deploy and what their hosting is like, so I would assume all these cases, Vercel is like a fairly small part of the infrastructure within a larger company. And, you know, it's kind of hinted here, like Box says 300% increase in SEO. So it's like, okay, this is good social proof because these are good brands, but probably those products may or may not be using Vercel, right? It may just be their marketing site or something like this. And really, like, Vercel has just done a slam dunk job with their brand. And a lot of that is, uh, very well earned just by having a good product that feels really nice to use as a developer. Um, there's a lot of detail that just makes it feel like where you should be when you're using it as a developer. But infrastructurally speaking, it's like, it could be perceived to be kind of like a fairly thin layer. So that order of magnitude price difference is like, I think easy to rationalize if you're early and don't have a lot of scale. And then maybe easy to rationalize if you're like a small part of a big company where you don't have access to like, you know, the ops resources, it's easier for you to just use a tool like this. But, you know, I think they're really benefiting a lot from the brand that they've built up in order to, you know, charge like this, right? I mean, and obviously they are contributing a lot to Next.js being so popular and benefiting from that. So that's, you know, I think totally inextricable from their brand as well.
Jazz, what do you think about the seat-based billing metric for the earlier stage company being misaligned with the value that company's getting? Is this something— let's assume that's true— is this something that they likely know and it's all about adoption pricing to just get more and more people in the door, or are they considering this from a different angle?
Yeah, it's a good question. I'll say a couple things. One, the SLA thing is funny. You're right. Like 99.99% is like actually quite low. It's like, it's like an hour of downtime a year, which is like, if you're an enterprise company, it's like, but a lot of people don't know, like, again, EC2 has 4 nines, right?
A lot of people just don't know how few nines you're getting from these like robust services.
Um, I don't know. I mean, like, it's a good, it's a good question on the seat-based stuff. I, it, you know, it's funny because when you said the seat-based stuff, I actually just like, when, you know, I was reviewing this and I, you know, when I was going to our account, like I just, it didn't even occur to me that was seat-based actually. It's like such an afterthought here. Um, I don't know. I mean, I wonder if they just like want to get a credit card and it's like one way to charge people like that aren't using the product that much. Um, like I can't imagine this is like any meaningful percentage of the revenue, right? And so like, I don't really know why they do that. Um, I agree, it's like for an infrastructure type service seems super misaligned with the value they deliver. Um, and given kind of what Ben was saying, like when you automate deployments from GitHub, et cetera, like how many people are actually logging into Vercel? Like I don't even log into Vercel more than like once every like quarter. Um, to, and I'm, and like, there's no reason I'd do it. Just, I do it just to like confirm a build has like happened. Yeah. And so like, it just doesn't really make sense why they charge for seats. I feel like they could get rid of it and like probably make a lot of people happy. The only other reason they might be doing it is to differentiate between hobby and pro. Um, right, like if you are below their usage limits, um, there is no other differentiation, um, and they'd have to collapse into kind of like just a hobby tier.
Yeah, I would imagine they have a lot of people that are paying them $20 a month.
That's it.
Yeah, you know, essentially hobbyists, but one seat and they're below the free tiers for every usage.
Yeah, what are we doing then? What are we paying them?
Uh, between $1 and $200 because we just have a seat for every developer basically. And again, that's just because of the Git integration and we use their preview app. So when we open a PR, we get a preview app. And if the Git user that opened the PR doesn't have a Vercel user, we don't get the preview app by default. Again, that you could, if we really wanted to squeeze them out of the $100, like we could automate that and not have to have a seat there, but that's like the default behavior.
Honestly, it'd be fun. Like if anyone at Vercel sees this, like that actually made this decision about seats, I'd be curious, like what that decision was.
Yeah. Yeah. To me, they feel like I always think of Vercel as like the spiritual descendant of Heroku. Like the Next.js developers of today are like the Rails developers of 2012. And, um, so yeah, it just sticks out to me. Like it, to me, it should all just be like usage hours and metrics like that.
So let's say we're paying them a couple hundred bucks a month and we're paying on seats. Are we at a place with Vercel at this stage of our company where that feels expensive to us, cheap to us, somewhere in the middle? How would you react to that?
For me, my answer would be, again, I think our experience is not that representative, but it feels expensive to me only because we don't use Vercel that much, you know, but objectively it's not expensive. Like similar to like the seat-based topic we had last week with Vercel, like if you're doing seat-based, but the seats are engineers, like you're increasing your costs a lot when you hire an engineer and $20 is not really a factor in that very much, right? I think, um, for us, I think if we were, we don't use Next.js, you know, so like if we were using more of their like, um, serverless invocations and things like this, like, um, it would feel more differentiated to us, right? Um, but I think we're like a non-typical Vercel user.
I think one other thing to say here is that, well, two things. One, um, what they could be doing is just mirroring what other infrastructure companies are doing, like Netlify charges per seed. Um, and so like, maybe there's some comparable sort of like pricing going on here and like, that's the strategy. Um, I feel like if I were them, they would be super like, to me, better served if they just had a platform fee, which implied you had higher limits, right? Like what you're getting in the pro tier is you're getting higher limits before you're actually on Pago. And so like, if you said, look, it's $200 a month or $100 a month, plus you have higher limits, like that's way more intuitive to me than per member.
So yeah, I probably missed some like packaging trend in the JavaScript platforms world, you know? Um, cuz Netlify was kind of like the leader before Vercel. So yeah, I mean, again, like I think with a company this successful, like there's a lot of authorial intent you should assume. So like, I'm sure they're doing it on purpose, right?
But, um, you know what the other thing is like that they might be doing is that one big part, I think, of their value proposition of their product is like collaboration and like commenting and like all of that stuff. Um, and so I wonder if like that's the play here on a per-seat basis is like you get these collaboration features and like if for instance, like you talked about eBay and these other folks, a lot of them are collaborating on like marketing sites. Like it becomes a lot more intuitive, right? Because it's not just like developers working on infrastructure.
Yeah.
Their UX around like commenting and things like that is pretty delightful actually. But it definitely is going to work better for something that's more like a static site than an actual web app. So that, that does probably seem right to me.
Super interesting. I want to do one more kind of deep dive here before we get into the anatomy of the pricing page itself and then the billing experience. And that's, can Jaz, Gio, can you kind of scroll down and Jaz, can you highlight the, the metrics here and the curiosity that I want to kind of drive at is like, the way they're pricing each metric, does it feel really expensive? Does it feel really cheap? Does it feel somewhere in the middle?
Yeah, I mean, like there's submetrics here, right? I think we talked about the, like, categorically each metric, right? Network, data, and compute. Like, those are the three sort of categorical price metrics. Each one of these, I honestly just haven't analyzed each one of these individually. I think the one I did analyze was compute. And I think like, for instance, right, like, this is kind of like a hard number to pull out, but I think for Cell Compute versus like AWS, right, like I think AWS is like 20 cents per million requests and like for Cell something like 0.000008 per request, which ends up being roughly, I think 40 times more expensive. And so like, that's kind of like one. I don't know if I did that math 100% right, but that's like one sort of comparison here. I imagine if you extrapolated across the other ones, you'd have something similar against AWS. AWS is going to be like to the metal anyway, right? So you're going to have like the lowest price comparison. But, you know, that's kind of like, you know, probably the difference you see between like a Vercel, which can charge the premium versus a Cloudflare in AWS, which is, which often doesn't because they put more work on you for configuration and for a lot of the other sort of like aspects of managing your infrastructure. Um, they, Vercel kind of does a lot for you, uh, which is why they, they kind of charge a bit more.
Any other things, any other thing, sorry, anything else you'd add, Ben, to that?
No, I mean, I think Jazz is right. It's a premium price and there is an extent to which this is like a classic platform, do it for you, no worries type of pricing model.
Right.
But like. It's clearly premium pricing. Like, we haven't had any kind of spikes like this that have been, you know, notable for us with the schematics deployment, but I had a personal blog on it where I was on the Hacker News front page one day and it spikes pretty good just from that, you know, and I've had the same thing happen on other CDNs and it's, yeah, it's just clearly premium pricing and you notice that when you, when you get a lot of traffic.
And for those that are a little bit less familiar with why they can charge premium pricing, the reason they can charge premium pricing is because if you're developing on Next.js or React, this is the, this is the platform to use.
Yeah. And I think they do bring a lot to the table with the, um, like on the left column, like everyone gets DDoS mitigation, right? And like, I mean, Cloudflare obviously is exceptional at that. But like, if you're, if you're deploying to AWS, like you probably do have to fiddle with a lot of stuff. To get, you know, anywhere close to the level of protection you're going to get from like a Cloudflare, um, or a Vercel, right? So like, they do bring a lot to the table. I don't want to be harsh on them, right? And I don't think they would disagree with the premise that they're premium pricing compared to those options. Um, aside from that, I think the reason they can price a lot is because again, yeah, like you're saying, the Next.js thing, like they've been very much the drivers of growing that ecosystem and the beneficiaries of it. And that's something that. You know, not a lot of companies can lay claim to a, you know, achievement like that. And then just their brand overall, right? Like I'm, every time I'm in Vercel, I'm noticing like little features where I'm like, okay, this is super nicely done, you know? And that's the type of thing where you just earn a little bit of goodwill with developers over time. And, you know, it's like the Stripe effect, that kind of thing. Like people just perceive of you as being really thoughtful in your product approach. And especially if you're not the one swiping the card, you know, that means a lot.
Yeah. I mean, I think one way to summarize it is like they can charge a premium because they make just like everything easy. If you're on Next, you know, and so it's kind of worth the price, especially if you're like starting out.
Um, Gio, take us into the pricing and the pricing pages anatomy here. What do you notice? What do you really like? What are opportunities you think that they have from a design perspective?
Yeah, I think like What has been said already is there's a mix of enterprisey type positioning alongside maybe an established brand around the hobbyist tier. And that's an interesting mix. You get like the main call to action is the business type of tier. The actual price is pretty subtle. Like if you look at most pricing pages, the price is a big, big old number. You don't have that here. You've got 3 different personas to, that have different calls to action that do totally different things, go to different parts of the website. You even have this Get Started with v0, which I think is their like AI chatbot, which is kind of thrown in here and it's a side product that gets a lot of emphasis here. And my overall is like, we, we talk about the biggest pitfall with pricing is complexity, the pricing page rather. I think the first above the fold area looks simple, but as you scroll down, we really start to feel the enterprise positioning with, like it has been said, like the logos here are big, big logos. As you keep going, there's a lot of options, a lot of configurability. You can start to find add-ons in here. They aren't very emphasized at the top, but they're in here. Each and every row here links to a docs entry where there's even more detail. And so the feeling I get is there's a lot. It's a massive platform. It's highly configurable. It's pretty complex. If I'm a hobbyist, I feel like I can get started, but I know that this product is trusted by big logos. If I'm an enterprise, maybe I feel like despite the brand being a hobby brand, maybe there's enough here for me. So they're trying to thread the needle and attack many personas. There's a very in-depth FAQ section too. So it's one of the longest, most complex pricing pages, although at the very top it tries to be simple.
You brought up one thing that I think is actually quite interesting, which is the use of docs to sell. Yeah, I think we talk a lot about or hear a lot about for developer tools, docs are so important. I think this is the first example I've seen of tying it directly to a commercial outcome. And that's so interesting to me because Just like the questions come to mind are like, how much do they see drop-off between someone clicking through to conversion? You know what I mean? And how tied are their commercial teams to their content teams? Because like, if it's like this sort of like intertwined, I imagine there's just like a ton of collaboration.
I think that's an awesome point too. Um, Gio, can you scroll down and just kind of like show us that again? So basically, Jazz, what you're saying is here is effectively like a feature and we're linking off to the feature's documentation. And that is probably one of the most discrete examples of tying documentation to the pricing page and to the buying decision that we've seen in any of these analyses so far.
Yeah, I mean, there's two things, right? Like, there's kind of two things that, like, are just like— I'm riffing on this a little bit, but I'm sort of thinking about it. Like, one, these aren't just, like, marketing features. These are literal features that are, like, available in the product, right? Like, so often you see a split between marketing features and like what's offered in the product. Like these are tied directly to those things. And the second thing obviously is like they're using, like they're relying on docs to sell you here if you have a question, which, you know, I just don't think a lot of people, like for lack of a better way of saying it, put like their money where their mouth is with docs in some ways.
Gio, what do you think about that?
I think it's true. I think it's a, there's just a lot of depth if you want it. Um, and typically pricing pages. Accept that it's a high-level entry point. It's just a selling tool. And it's not meant to explain every detail of your, of your product and show you all the different ways and permutations of configuration. Instead, here they're leaning into it. Like I said, the top is simple and you kind of choose your persona and go, but as you keep going, the detail like is exponential almost. And you start to feel like this thing can do a million things and Every little feature has more detail within, within it. It just feels like a big world, a big platform. Feels like a big product.
You know, to piggyback on to some of that, I think for me in evaluating this, I agree with you. Like, it's one of the most complex pricing pages that we've looked at. I think they do a great job of threading the needle between being simple and accessible for the hobbyist, but going really deep for the enterprise. To me, what this pricing page sort of reeks of is confidence, and that's confidence in their product. And if I were to take that a level deeper, it's they are so incredibly transparent about the way they're pricing. And that transparency to me is just a function of how confident they are in the product to serve this audience so well. I love if you scroll down their FAQ, I think it's the best we've ever seen. I mean, it is the most in-depth, it's the richest, real answers for real questions. If I were to cite an opportunity that that I was kind of thinking about as I was observing the page was given the complexity, given the complexity for an enterprise, it feels like a no-brainer investment to consider is, and there might be headed with this here with like read about our ROI study is like a calculator. Help me calculate what my overall enterprise pricing might be if I'm going to go down this path, you know, upgrade, you know, kind of use this at scale.
That's right. Like, and you see this in other products like Can I get a sense for what I'm going to pay by adding in what my estimated usage will be? You know, maybe roughly how many seats, like, since there's so much configuration, is there a way to give me a preview of what I might be paying? Because it seems so variable.
I might just note, like, on the pricing calculator piece, like, the more you move towards platform-level pricing, it seems like they could make a case that, like, your performance will be faster, and therefore, like, especially if you're an e-com or something like that, that will be, you know, will make you more money or something like this. But even in that example, like they don't know what your performance is now. Um, so given they have this pre— like they're about as high of a platform as you're going to level as you're going to be at. So the pricing is going to be high compared to anything you compare it to. So, um, you know, it might be high because then you don't need to have a developer or DevOps person do this work in AWS to set up this and that service or basically like someone who's super into DevOps or into configuring their AWS is going to look at a company like Vercel and think like, well, I can just do all this myself. And it's like, yes, you probably can. But that makes it hard to do a pricing calculator, I think, right? Because they're saying like, they don't know what it would cost you to do it yourself, really.
Make sure I understand that point. It's like hard for them to do like self-serve config because Say the because again.
Well, I guess another way of putting it is I think a pricing calculator can mostly only hurt them if it's ungated because all they can communicate with accuracy is their high prices. They can't give you accurate numbers on like how much you're saving on your labor or how much you're improving your performance, which in turn would improve your conversion rate if you're an e-com, things like this. They just can't give you those numbers unless they're just, you know, assuming a lot of things about you they don't know. So I feel like for them, a pricing calculator should probably be gated to a context where somebody has intent and you can talk to them about those trade-offs.
Yeah, that's a super interesting point.
Yep, totally agree with that. Um, I think the only last thing I'll say on this is like, just back on the docs example, I think like, there's a level of depth here. There's obviously a lot of confidence. They're sort of like doing something interesting where they're tying like actual features to marketing sort of features. But like, there's something about it that like feels like not optimized, right? Which is like, you know, if you're an e-com brand, like you would never like, once you like get someone to check out, like you would never try and put them in any other page, you know what I mean? And so like the fact that they kind of like push you to, or like actually link off to so many different pages, I'm curious how that affects conversion. Like I wonder if like that's like a bad decision from like an optimization perspective. Purely speaking from a pricing page. Optimization and CRO perspective. But, um, that's only last— that's the only last thought I'm sort of thinking about is they—
I was thinking about that too. Gio, one more time, can you just— does the doc page, if you click on it, does it open a new tab?
No, it opens— yeah, it does open a new tab.
Okay. So you keep your pricing page tab open, but they go answer the question in a separate tab. And they've got, you know, at least a dozen of these, of these linked docs pages.
I do think, unless you're a one-person company or a hobbyist, like, you're not going to look at this pricing page and convert. Right? Like you're going to make the decision over a period of time.
Yeah, that's a good point.
Okay, let's shift into the billing experience. Gio, take us, take us through here.
Yeah, so what we have here is a pretty in-depth billing experience that exists in many parts of the product, starting with the billing page where you're able to see what plan you're on, what your billing cycle looks like. You can do— we, we are on the Pro plan, which means I think to, to get to a higher plan, we have to talk to sales. There's like a way to downgrade. Um, from here you can actually see the other plans here, but you can see what you're on. Um, you have a pretty in-depth add-ons type menu here where you can self-service turn on a variety of the add-ons that are pretty expensive. And also there's a lot of depth here. Like this one has volume-based pricing, or at least at least even, even more sort of metering within just this one feature. Um, you've got a whole spend management section, which is impressive, where you can start to understand like, how much am I spending towards my, what I'm using? I can set budgets, I can set limits. Um, I can even set behavior based on hitting those limits. I can set up notifications. Um, And then we get into some other features that maybe aren't purely around purchasing, but just on this first page, tons of configuration, tons of options. They push you to a view usage tab, which is in a whole different part of the product where you can see in great depth what your usage is of this, of this product. Yeah, I mean, I think there's so much here, like extreme transparency, extreme configuration. Again, it just feels like a big product that does a lot and is not going to hide anything from you, um, and gives you all the data you might want, um, which I, I think is like, again, maybe feels enterprisey in terms of just the, the high bar of detail, but I'm sure even the hobbyist appreciates this and feels like they can— they've chosen a platform that scales with What do you guys think of this?
I think there's, I mean, I totally agree on all that. I think like, you know, it's sort of an extension of the pricing page in many ways, which is like, you've just got a lot of, like, I think Vercel just has to serve a lot of different types of users. Um, and so I think you see that obviously in like how much they expose, you know, um, like you probably don't care about all about all of that, but you might care about some of it depending on your use case, depending on who you are. Um, and so, you know, one way to get around that is just to be comprehensive.
You know, I think also to me it lines in with their, like, their choice to be, uh, associated with quality, right? Like with a dev tool within a category, I feel like you can be cheap or you can be great or else you probably lose, right? And so like they are choosing to be the great tool, not the cheap tool, and therefore like they have to be great along so many different vectors, like, and especially given their large install base, uh, or large user base, eh, they just don't want to have a lot of surface area for people to be like, oh, this part wasn't great. You know, it's just that it's their brand. They must be great in every way. Uh, I mean, it's being a victim of success, right? It's kind of like having haters or, or whatever, like, but we've all seen viral tweets where people complain about their for-sale pricing, right? And so, you know, I think if you were not giving them as much credit, you would say like they're, they've built all this, you know, transparency reactively to that. But I think it's more proactive just because I think they, they wanna make sure they're presenting an image of, you know, um, there's nothing hidden here. This is every, we're like, like you said with the pricing page, Fynn, like, we're confident in what we're doing here, uh, all the cards are on the table kind of thing.
I was going to ask you how proactive you felt that decision was versus reactive. I'm glad you answered the question.
I mean, I don't really know, but I, I think probably a little bit of both, but more proactive.
You componentize this a little bit for us, like, so we've got basically— would you describe this as this is our customer portal? Is this Schematics customer portal?
It's I would say our idea of a customer portal is split into a few places. Here you have the usage dashboard, which is not a place where you make purchasing decisions necessarily, but you just monitor usage. You can see across 5 different products what your usage is. If they have a concept of overage, that's listed here, um, and even more detail per feature on usage. So this is purely the usage. Dashboard. It's quite in-depth like we talked about. Then you can go to the plan page where this is where you might actually make a, a purchasing decision around an upgrade, around add-ons. It's like, it's even more complex in terms of you can turn on an add-on and then some of them are just a one-click install. You can see how proration will work and some of them are actually per project. So there's two steps. You have to turn it on and then decide what project it applies to. But all the purchasing decisions appear to be here. And then you've got an invoices tab that just shows you past invoices. So 3 different places: usage, purchasing decisions, and the invoice bit.
What is your opinion of that split into the 3 different pieces? Do you like the split? Would you add a 4th? Would you bundle it all? How do you feel about the design of this?
Um, I think it makes sense for them. Um, potentially invoices are in a different place because of role-based access where maybe you have a user that only can see invoices. That's maybe why invoices are split out, but then it makes 100% of sense to me, or it makes a ton of sense to me that they have a separate usage tab that's separate from your plan page where you can just monitor usage. Because this is like part of their product. Part of the value of Vercel is seeing all this. This is not just usage as it relates to what you're paying. It's usage as it relates to why you're using this product. I'm monitoring your infrastructure. It's like, it's part of the manage infrastructure features to see usage.
Yeah, it's pretty common to separate those out for infra. Part of it is also just, and I don't know to the extent this is a consideration here, but with a lot of infra products, like you might have different user types, like some might be interested in usage, but you don't necessarily give those users access to billing information. So I think it's fairly common to separate those out.
It's extremely well done. Not all of these usage graphs relate to something you're being billed for. It shows you like, that's, this is part of the product. It's not just a, here's what you're paying.
So Jaz, can you talk a little bit about what you would expect to be their typical expansion path?
Yeah, I mean, I think there's two obvious ones, right? One is like obviously scale, right? Like you become a bigger company, need much more infrastructure. Um, and you just sort of travel on a continuum of their usage metrics, right? And you start to increase, right? But I think at that point, you tend to like have a negative feedback loop, right? Like, you know, you're paying a premium, you're big enough, you're probably going to optimize into like other parts of other sort of infrastructure services. The other sort of dimension that makes it like probably is where they see a lot more expansion, I would suspect, is adding more projects. And I think what happens, I bet, like, is my guess. I think a lot of people probably start with, it's kind of how we started, right? Which is you start with your marketing site and you host your marketing site on Vercel. You say, oh, well, I can probably add an app here or a sample app or like something else. And I start adding other sort of projects. And then those obviously from a price metric perspective, they're priced separately. Right. And so you start to kind of pay for those as well. And each marginal sort of project isn't that expensive, you know, and then you start to kind of expand that way. And so I think there's like two dimensions typically where they're probably seeing expansion. And those are the two that make the most sense to me. Um, but, but again, I think like a lot of their revenue is likely through enterprise deals, um, where it's sort of custom pricing anyway, right? Um, and there's some sort of baked-in usage metric. Those feel like the two dimensions that feel the most obvious to me, with projects being probably the most, um, uh, active one for them.
Did we use Vercel at Automox, and did you guys use Vercel at Relay?
Automox, we use I can't remember. I think we were on Netlify.
Um, no for Relay.
And then Vercel, I think, wanted the business, but, um, there's no reason to switch infrastructure. It was only marketing site though.
Yeah. And then you said no at Relay. Okay. Um, we're, we're with 10 minutes left. Anything else we want to talk about on the billing experience and purchasing experience side?
I think the only thing I'll mention is like, I'm actually curious, like how many people ever go into that usage tab? Um, One, because like when, like how many people actually hit those limits, you know, and two, like you're probably, you're answering a specific question when you hit this page, which is, that's kind of why it's hidden a little bit, which is where did I hit an overage? You know, like, like where are they like charging me more than I expected? Um, and I think that's the main function of this page, right? Which is like trying to answer that question in as fast a way as possible with the most like trustworthy. Audit trail as possible. And so like, I bet, like, I wonder if they look at like their analytics, like where this sits in terms of rank, um, for like visited pages. Uh, it's certainly interesting. Um, I had never been on this page before we like started, like, we're like, let's talk about Vercel.
Ben, how many times have you visited this page since using Vercel with Schemata?
I mean, maybe one hand's worth. I haven't gone to it a lot.
I was actually thinking a little the opposite of what you said. I mean, there's some aspects here that like we, that do touch your subscription and overages, but then there's other, it's answering other questions that have nothing to do with your subscription, like top pads and.
It's true. It is. And like, which begs the question, like, why isn't this higher level? If it's like answering like more analytics, interesting questions.
It's pretty, I mean, it's, it's a top level.
Oh, there it is. Yeah. I thought it was just like, you know, view usage in the billing page.
That, that was, that was my next one as well.
I see this, this NAV always confuses me.
Yeah.
I don't use it enough.
Their nav is pretty complex. Like what my point before was, they haven't just put usage on the billing tab, like, like many companies would. It's a top level concept that answers many questions, not just related to that. But I mean, it sounds like maybe still not that useful since Ben hasn't really used it, but.
Well, the reason is that the services we run on Vercel are not the ones that I our core software doesn't run on Vercel, right? It's more like our marketing site, things like this.
Yeah. Like how many builds have you done? CPU time?
What's that? If you go to observability versus usage, it's kind of interesting. There's some overlap here, but yeah, sort of interesting.
Okay. Let's, let's go, let's use these last 8 minutes to give our rankings. Um, so on a 1 to 5 scale, their pricing page, their billing experience, 5 is excellent. 1 is terrible. If you're going to throw them a 3.5 or a 4, you got to be able to speak to opportunities you see that would take them to the 5. And Ben, why don't we kick off with you?
How would you—
what would you give Vercel's pricing page and billing experience on a scale of 1 to 5?
Um, I'll give them a 4, maybe a 4.1. I think they're— I really like the pricing page. Like I said, the seats thing I don't love, but I, I can see there's reasons why it might make sense. And again, I think The reason I don't like it somewhat has to do with my being a non-typical customer of theirs. So what I like about it is on the pricing page, like I, I like the, um, the fact that they've managed to strike the balance that Gio referred to of like a simple simplicity in the top section and then depth in the rest of it. Um, degrading in documentation and things like this. Like they have features that are in every plan, but you have a link to docs, so it's kind of. Showing you like what you really get. So it's very choose your own adventure in a way that I think is well suited to the way people buy these types of products. In-app, like I talked about, they just leave no stone unturned. It's very high quality, high depth, high transparency, which is great. I mean, that's like a bar that I think any infrastructure product would want to reach, you know? So yeah, that's my, my read on them.
4.1. Okay. Jazz, what about you?
I think it's sort of hard for me just because I don't buy a lot of infrastructure. Um, I would say like, feels like it's, you know, based on like what I've seen in the wild from other folks, like relatively comparable. Feels like a 4.1, 4.2 out of 5. And, uh, yeah, I think it's like, it mirrors like, you know, like the Netlify's, etc. And so it doesn't, it both doesn't do anything that adventurous, but it also does some new things. Which I think are sort of, it's sort of cool to see, like maybe trying to sort of like insert new best practices, like linking to docs, et cetera. And so I think those are great. And then I think the third thing they do like relatively well is they just like really highlight why people buy. Like I think they like deeply understand why people buy from them. And they highlight that super high at the top in the hero. And they're very clear about that. And they're like super transparent about like, this is what you use us for. And so I think those reasons are why it's probably a bit higher. And And yeah, I think like those are things you'd probably, I'd probably take away if I were like listening to this in terms of like applying to other pricing pages.
Nice. Gio?
Yeah, like Jazz said, I don't buy infrastructure. I'm not like the target user, so it's hard for me to, to pass judgment on the strategy. But from just a pricing page design, product design, I would give it a 5. I mean, I, I think they have a massive platform that does a lot of things and they do a good job of achieving the balance of this pricing page is helping me to convert, giving me an understanding, but also showing me depth and complexity that I need to see from a platform like this. And then within the product, the purchasing experience leaves nothing to be desired, at least again, from my perspective. I can self-service add-on, I can see usage to extreme gran— granularity. If I need to talk to sales, that's a click away too. I can't really think of something where they're lacking.
Gio, I'm with you. I'm going to give it 5. And, and I love the point you made, which is like, there's nothing to be desired. Like, I couldn't figure out one thing that I really like would ding them on. So I've got to give them a 5. I love the confidence. I love the depth of the FAQ. Love the in-app billing experience. And I think like the more and more we do this, the more I've come to realize that in my own life, buying products, whether it's software or any product, like the clarity of the pricing, why it's priced that way, and the friction that kind of informs the buying experience just really matters a lot to me. And they're extremely low friction and extremely high transparency. So I'm going to give them a 5. Guys, this has been awesome. Sorry, my voice is giving out. I think Vercel does a really good job of reinforcing the idea that a pricing page is more than a transactional page. It is sort of this essential asset to describe what your product does. And they've tied their product to their pricing with, with probably more more, um, intertwining and depth than any tool we've so far evaluated. So it's really cool. Thank you guys for listening, and we'll get this out.
More from Fynn

Schematic at Operators Guild Demo Day 2026: How to bill for AI credits without a surprise bill

Should you move to usage-based pricing because AI is compressing your margins?

Why raising prices every year backfires (a pricing leader on the Mastercard quota model)







