Miguel Oller, CTO of Makeswift, explains how the company shifted from selling cheap plans to individual users toward larger enterprise deals. He stresses that pricing needs to be built into your product architecture as a first-class component, not bolted on later, so you can test and repackage without rebuilding everything.
Tell us a little bit about what you've learned about commercializing products.
The one constant thing, which is we've always been changing, uh, and this is like, like in particular, like pricing, not just how much we charge for the product, but like who we approach. So in Makeswift, for example, for a very long time, we were looking at the market as like, okay, we're going to do a bottoms-up approach. We're going to go out there. We're going to get individuals excited about Makeswift. It'll be a low cost, kind of like reduce the barrier to entry. And then we'll get volume and then go upmarket from there. And then, you know, very soon we realized that based on our feature set, like based on like what we were charging and like where we were as a company, it made more sense to maybe actually start the other way where we'd start with like a bigger deal and move more. And then the mass market vision that we wanted, we could tackle later once the product was more ready for that in terms of onboarding features that were like easier to like wrap your head around. And so as those things like evolved, we were constantly just changing how we presented like pricing. If there is one thing, you know, if it was like, you know, starting a fourth, fourth company, is that from day one I would try to make sure that I understand, okay, like this is going to change, this is an experiment, like an ongoing thing. Um, how can I make it so that there's a framework upon those experiments that can be built and those changes can be made without having to like throw everything away?
I want you to maybe double-click into that idea of a framework for experimentation. Did you mean We need to be more organized around strategic hypotheses that we had from a go-to-market perspective, or were you saying we need sort of an architecture that enables flexibility for inevitable change?
So, so coming at this time from a technical perspective, like in the, in the world of, you know, like SaaS, like, like, let's call it, like, you usually have like all these features and when you're just focused on like getting the MVP out there, like building like the product, you're not really think— usually not thinking about "How do we process and then sell this?" Right? You're mostly thinking, "Okay, like, we'll set this up and then like we'll figure out how we're gonna process it. We'll like slap that on top and then present that." And when change happens, the amount of work is— it starts feeling a lot larger compared to like the importance that's given to like the rest of the product. And so that's— it's more what I meant. It's like not having— just not knowing how to model things. Because I think like, again, like what we've learned, and I mean, I think this is like, it's no surprise here because like we're schematic users, is like, wait, there is a way that you can kind of like invert how things are modeled. So when you do need to kind of like plug and play different ways of packaging like the product, it's easy. Knowing that is kind of like all you need. Because it's one of those things where if you just know, then it's not harder to do. You just do it a different way. And then that unlocks all these other benefits that if you just don't know, then you like really don't benefit from it.
How does MakeSwift price and package today? And given change is a constant, what do you anticipate to be future change?
So today we're about to like launch an experiment where we're We're trying pricing on change frequency. We've, for a very long time, have tried to find the right way to price our product. And, you know, we've done per page, per users, per sites, like certain features that we've gated. But it's always felt like they were, each of those, like, were suboptimal. And we kind of like try to think, okay, like, what is like the real value that you get out of something? Like, it makes sense. Like, if you have a site and you're not touching it, you're not changing it, you're not really getting that much value. If we want to align, align what we charge to the value we give customers, shouldn't charge much for that. And we kind of like figured out, oh, like the main thing is, is this like flux. It's like. People going into MakeSwift, making changes visually, and getting them out there. And so we identified like the publish time, like going and publishing those changes was like a very good point. So like right now it's like an experiment we're going to be running. But again, like I said, like in the past we've experimented with number of pages in your site. We don't like that because it limits creativity, right? If you want to like have a lot of pages. Also like different users have different use cases. See, if you have a, you might have a company that does a huge marketing campaign with one landing page that drives a lot of revenue. This one page, versus a different company that has, you know, maybe a lot of blog posts and those blog posts are mostly archived, but hundreds of them and they're not really changing them, but it's not like really driving any revenue for them. So why would you charge them for that? So number of pages, number of sites, same thing. Like we don't want to limit people. We want people to make more sites and make stuff, right? So they use it more. Number of users makes sense, but as a lever, like if you have like 3 users, but you're getting like a ridiculous amount of value because those 3 users create the page. So figuring out how to align it, it's been hard. Um, and then we have competitors that like do think different things, like they might meter on number of visitors. We have a lot of reasons why we don't think that's the best, but, um, yeah, that's kind of like how we, how we price things right now. And some ways we've tried in the past and some ways we could try in the future.
