Paul (00:07):
I didn't build the startup for investors, I just built what I thought would be the best product for developers.
VO (00:14):
Welcome to Spotlight on a podcast about how companies are built from the people doing the building one messy, exhilarating decision at a time.
Arun (00:23):
Welcome to Spotlight On. I'm your co-host Arun Matthew.
Gonzalo (00:26):
And I'm Gonzalo moa. We're here with our guest, Paul Cobblestone, founder and CEO of Superb Base.
Arun (00:32):
Thank you for having me, Paul. Thanks for being here. It means a lot to us. Let's start with what Superb Base is. Give us a quick overview. We'll go into the story and the history, both of you and the company, but why don't you tell us what the company is all about?
Paul (00:47):
The simple way to explain it is a backend as a service. Our tagline is Build in a weekend scale to millions. So we aim to provide developers, especially with all the tools that they need to build the infrastructure, send it around Postgres. Actually, Postgres being the world's most popular database. We very commonly are known and kind of started our journey as an open source Firebase alternative. So that's the other part of Superb Base that's really important. We're open source. Everything we do is open source and we've got a really fantastic community around the open source and we try to support them as much as they support us.
Arun (01:25):
Let's start at the beginning, Paul. Tell us a little bit about your upbringing and history and what sort of led you to launch and create superb base. And this would include a couple of startups before that you started before Superb Base.
Paul (01:39):
Yeah. Well, you can probably tell from my accent that I'm not from the us. I'm from New Zealand and I grew up there. New Zealand is not a really tech heavy country. There's a few breakouts. I think Zero is the most famous. But yeah, to be honest, I didn't even really know the concept of a startup when I was growing up. I dunno when that concept even started in the us but for a long time I just thought I'll build things and my father was an entrepreneur and is an entrepreneur, so it's just what I knew. I just knew that you build things, build businesses, and started my tech journey more as a contractor helping people and helping other businesses build the infrastructure around. And my very first professional job actually was building with databases. It was very database centric and I could see how difficult they were to use, but I kind of was fascinated by them.
(02:35):
So I remember one of the first things I did, it was probably 15 years ago now, was I wanted to build a startup around databases and I literally went and found a millionaire in New Zealand and I pitched him this idea of building a database startup and I looked back at the email as basically what we're building right now with super base, which is kind of cool. I would've failed miserably. It would've been the wrong time. I would've done it differently, but obviously I had completely forgotten until I, yeah, someone was asking me these questions about how I got started and I remembered and I went back and saw the email.
Arun (03:14):
That's funny. So what was the first company that you started?
Paul (03:20):
Yeah, so this is my third venture back company. My first one was a marketplace. It's very similar to I think Thumbtack in the us
(03:31):
And we took that model and we implemented it in three countries in Southeast Asia. And so I was the CTO of the business. I had met kind of a friend of a friend who had done Groupon China, and so he was going to replicate that sort of success in Southeast Asia. So I literally flew into Malaysia. We started, we built it in Thailand, Malaysia and Singapore, and we scaled it up. We raised money, but it just wasn't the right market and also super hard to build a three-sided marketplace where we sit between two different people. So yeah, I learned a lot. I learned a lot from scaling that up. Learned a lot of what not to do to be honest. The really classic, what you should not do, which is done by almost everyone in their first one is kind of playing startup.
(04:24):
You'll see this very often when you go to a startup meetup, one of the first things people ask is how many people in your team or how many do you employ? And this is like a classic trap. You say it almost with pride, but actually what we did was we took on the funding, we put the posters up, we hired a lot of people, blitzscaling or whatever, but we didn't really have product market fit. And there's no point blitzscaling until you've actually got a really good product that people want to pay for. So we actually did the opposite. We in superb base now, we in the early days really only hired when we had a hair on fire problem that we completely over understaffed, and so we've got a problem that is getting completely neglected. Then we'd hire someone in and it always felt like we're a little bit behind on hiring, but that's good. It keeps the density, the velocity up. When we hired someone, they just had a ton of work to do. I think one thing that I did learn a lot was actually from my co-founder. He was very good at fundraising, and this is probably why we played startup.
(05:34):
We could fundraise quite easily and we could use the cash to kind of hijack this startup mentality and we got the press and everything. But when I remember the first meetings that I had with VCs and I was a shy kiwi where I didn't even want to promote anything that I had done in the past, and it's very different, the Kiwi mentality to the US mentality.
(06:01):
So yeah, I had that beat out of me very quickly, so I learned a lot from him. So that was nice. The second one, I went to Singapore and it was kind of a similar one if managed by queue. It's basically managing services and office management and it was something very similar to that just for the Singapore audience and we had a regulatory moat that we could use in that one. So it's still going and it's doing very well. Actually, most of the tech that we use now at Superb Base was what I implemented in my second startup. And so when 2020 came along, I reached out to my co-founder and said, Hey, this is what I'm going to build. Do you want to do it? And he said, yes, luckily, and here we are five years later.
Arun (06:48):
That's great. It's a very non-traditional background for a dev tools or infrastructure type company. I mean most founders in this category have a deeply technical background. They typically don't start something that's a consumer business or a marketplace business. But what do you think about those experiences sort of helped you in launching something in this category?
Paul (07:09):
I think the thing that actually between the first and the second business, I think I helped maybe five or 10 people launch their businesses and there was not much tech talent. So what I became very good at was essentially this kind of build in the weekend type idea and I wanted to find the highest leverage tools that we could through open source. A lot of the time developers think, oh, I'm going to build this myself. The temptation is always just to build, but not to get to the finish line. And I was like that at the start as well. And at some point what clicked in my brain was like, it doesn't really matter what you start, it meant what you finish.
(07:47):
And so I was always focused on getting to the finish line and trying to help these founders launch something very quick so they could iterate. I think that's the thing. It didn't really matter what industry. I helped Web3 companies launch during that time. I was trying to launch a ar vr startup during that time, very deep tech as well. I helped several companies launch, I went through an accelerator and after that a few of them needed help. So that was the thing I just became very good at finding how to get people to market very fast.
Arun (08:23):
How did you settle on Postgres that you were going to build on Postgres? And when you think about the core differentiators or what makes super base truly unique in a world that's littered with different products and competing solutions, how would you define what makes you unique?
Paul (08:41):
Yeah, so the idea of Postgres was pretty obvious to me because I consume hacking news so much. So before my finger on the pulse is just going through Show Hacker news, reading Hacker News, and it wasn't at the time 2019, it wasn't the world's most popular database. Now it is. And I could see the trajectory that it was on. It has some very nice characteristics if you want to build a business around it, it's open source. It's not owned by any particular commercial entity. In fact, it cannot be owned by any particular commercial entity. So that was good for us because then we could build an offering and we'd compete on experience, not on license or anything like that. So that was great. The thing that makes us unique is exactly that. We literally compete inside our principles. We've had them since day one. How we build our platform, one of them is portability. We think that if our platform is not the best, then you should be able to take your data and take it to any other Postgres provider. And a lot of people think that's nuts. Like, oh, where's your moat? You can just download and reinstall. But I think that's fantastic. The reason people choose us is because we're competing all the time for their love. Essentially. It
Arun (09:56):
Expresses confidence
Paul (09:59):
And we've literally helped people migrate away when we were not satisfied, satisfying what they needed. So we lived by that principle
Gonzalo (10:11):
That to investors is sort of a very contrarian bet that you made early on, right? Not many database companies start with saying, Hey, we're not going to build our own engine. We're going to use something else. Sure. Can you talk about that decision and how that felt at the time? Did it feel contrarian to you? Did it feel natural?
Paul (10:28):
Well, the first thing is I didn't build the startup for investors. So I just built what I thought would be the best product for developers. And I truly thought Postgres is the tool. It's extremely extensible. We've done a few unique things for our platform. So we don't just offer Postgres, we offer these autogenerated data APIs, we've got a storage service, a North service, and these are all the questions that I needed to answer at the start was if you want to launch a business very fast over a weekend build in weekend, it turns out you don't just need a database, you need a bunch of tools. Imagine you're going to build Instagram, you want to log your users in, you want to store those images and files and you can't store them inside the database and maybe you want an API to access the database securely. So we kind of built this all these day zero products that you need around the database, but really focused in on leveraging the database as much as you could. So when we compete against other database providers, typically their model has been, oh, you know what? I can build a more scalable Postgres offering, which to be honest, sometimes they do and they do a very good job, but that's not what the developer needs when they're choosing a database. What they need to do is get to market very fast and they don't want to think about whether it's super scalable. They just want to think whether it's super easy to
Gonzalo (12:00):
Use. So maybe on the product side would love to just hear what have been the critical milestones along the way. So you talk about a auth as sort of when you're finding product market fit, something which sort of tipped the scales. You do rolling launches now you're building an incredible velocity. What are the milestones that you think are most important in food basis history so far?
Paul (12:24):
Yeah, we've been pretty fortunate in that our roadmaps almost been defined by us, for us, by our community. So when we did our first launch on Hacker News, it was like May, 2020, and it wasn't even us. Someone put us on Hacker News and we got a lot of love around the positioning, actually open source, fire based alternative. We got a lot of hate for that as well. Funnily enough, someone said, ah, their positioning's terrible as they do on Hack News. It turns out then it was the best positioning we could have had, but what we had was a database and a data, API, but no auth. And they said, this is great, but we can't use it until we've got auth. And so what we did all throughout YC was we just worked on auth, and I remember, can I swear in this interview? Whatever you want.
(13:16):
I remember we'd turn up every week and we meet Michael sbo, who's the God founder, and he's pretty, I dunno if his reputation outside of YC is this, but basically you can go and meet Michael and you'll think you've got a good idea and he'll tear it apart, but in a good way you go away thinking, oh yeah, that's not what matters. This is what matters. And basically we'd turn up every week and I'd say we're building off, our users asked us to build auth, and after a while he said, Paul, for four weeks you've been telling me you're going to build auth. When the fuck are you going to ship auth? And so we just had to hammer it out and figure it out. And about three weeks before demo day, we shipped it and we put it on Hack and News again and we said, Hey, you guys asked for auth, here it is. We've shipped it and we've done it in this Postgres centric way, which no one kind of believed that we would be able to pull off.
(14:14):
And so sure enough, it went to the top of Hack and News again, and people like the fact that you listen to what they ask for and you deliver on exactly what they ask for. And that's been the cadence basically each time we launch something, we see what they ask for the feedback, and then we've almost got that three month roadmap ahead of us and we started building that into our company philosophy Launch weeks are a big thing now I know across the industry, but they started with us coming out of YC and not having the demo day looming in front of us. So we wanted to recreate that feeling. I know for example, our next demo day, our next launch week is in three months from now, and that's where we'll ship a lot of the feedback that we got in this last launch week.
Arun (15:03):
We'll dive into a little bit of product roadmap and where you're headed, but can you just give us a sense of product philosophy, how you think about where you're headed, what you prioritize, what's on your roadmap, just how you think about that. And some of that I imagine is informed by the community, which we just talked about, but some of that is how you think about where the world is moving and this massive AI wave that you're riding. And so just take us through a general philosophy around product and then we'll dive into some of the specifics around where you're headed.
Paul (15:36):
Yeah, it's hard to give one single philosophy around product. Generally, we just see things through a Postgres lens. I guess the overarching theme, we do a lot of principles around our products, so we try to stick to existing standards. We try to make sure everything's portable, composable and integrated. So a lot of the time it's actually dual philosophies, so they might seem contradictory, but one is that everything feels integrated. For example, when you come into super base, it should feel like it's just a single API and everything fits together, but actually we have say five different products or storage and database, and you can use each one of them as a standalone service. And very often people do. They might just use ortho in the database or they might just use the database with existing providers. It could be drizzle or click or zero or anything else.
(16:38):
And that's how we've designed it so that it's very composable, almost like Lego, and it's a bit hard to design the system like this, but since we had it like that from day one, it is been very, very good. So what's happened is these AI builders came along the bolt, the lovable, the V zeros cursors and everything, and what we found was actually they really enjoy the single API feel of the platform. The reason why is because as soon as you have to stitch together many tools, then it becomes more difficult for the LLM to actually figure out the context between say, three different platforms. But because we provide our own basically behind a single data API, it becomes very simple for the LLM to scaffold out an entire backend versus maybe the enterprise customer, they actually might start only with Postgres and then they'll try it out different services over time. So what we're finding is this almost divide where both have proven equally important and even more so we're seeing attach rates for the AI builders for different products like real time that we had never seen for just developers building on our platform.
Gonzalo (17:54):
When we were talking about superb base, we talked about the business model and the product and giving the company the right to get lucky and catch new waves of growth and all the rest. But how much would you say, you mentioned years ago you had this idea about some kind of database startup, which was different than subbase, but some version of it, right?
(18:12):
Yep.
Gonzalo (18:12):
How many of your product decisions have been deliberate and how much of your success would you say is strategic and deliberate versus we built something cool and we stumbled into a great wave and we've been really lucky? How do you think about that trade off?
Paul (18:24):
Yeah. Well, the deliberate thing is, I said this to you guys, right? The question we always wanted to answer was, if you want to build the next Oracle, how do you go about it? So that's the deliberate thinking in our brain. We need to build towards that vision, and then you can scope it right down to what's the next three months, what's the next three months, what's the next three months? So the waves that came along were always just, for example, we've seen the Web3, the NFT wave, and now the AI wave, a bunch of different waves. Generally we just see them happening and they've got some direct three month requests, and it's not like you give up on this long-term vision of building the next Oracle, it's just that you need to solve some decisions in the next three months that won't conflict with that long-term goal.
(19:22):
So it's very easy. They'll ask us, MCP is the one at the moment, that means that people can spin up more databases. Is that conflicting with the Oracle goal? No, it just might displace some of our roadmap. It'll take us a bit longer because we have to build this new thing. Versus maybe one which is slightly more difficult is maybe the positioning and branding around super base matters. So if we move completely towards this world where people are building and they might not even know what a database is, they could build many smaller tools. Will our brand become just for non-developers? Can we actually reach the enterprise? These are much more deliberate things. We need to think strategically about the product, the packaging, how to position ourselves both for AI builders and for enterprise, and that's where I need to spend more brain cycles.
Arun (20:19):
Maybe let's talk a little bit about team. You started the business a month or two before covid hit.
Paul (20:27):
Yeah. Is that right? We started January, 2020.
Arun (20:29):
January, 2020. So you started in Singapore and then Covid hit what happened, and take us through your philosophy around team building for the first couple years, and now you have employees in 25 or 30 countries, you're sort of a fully distributed team. Take us through your team building philosophy, how you sort of manage the team, and I know folks listening will probably have tactical questions around how you manage that team and all the growth that you've seen over the past few years.
Paul (20:58):
Yeah, it's a great question. So yeah, just high level now we're in super basis over a hundred people. We're in 30 different countries, so very split. There's no hq. We have offices, but they're just WeWorks and only if people want to use them. So that generally means no one uses WeWork, but we offer it in case. When we started, we started actually an and myself met in Singapore, and then we got into YC almost immediately in the first couple of months. So the plan was to move, of course through YC to move to a SF, but that's when Covid hit and we had to build, it was the first fully remote YC batch. So we ended up building it directly from Singapore under complete lockdown, and there were only a few of us, and a lot of the people we recruited at the time were ex-employees from our previous startups or companies that we knew.
(21:57):
And so we already had this kind of bond with those type of employees. The next phase of employees were more the open source maintainers who really knew the product, and they started coming in and we could see that they were contributing a lot to the product itself. And so turns out that the open source community is almost like they're very accustomed to doing an async type environment. You do pull requests, you detail out your GitHub issues, and you do everything fully remotely. Not only that, they're used to working, they're used to working for free. So for us to offer them payment to do this job, they're very excited to do it. So yeah, it evolved a lot. The company tactics wise, now, it's pretty interesting. We use generally Slack for synchronous comms. We use Google Meet for synchronous, like calendar invites, meetings, meetings. There's very few. We have one meeting per team per week, and that's it. That was very strange for a lot of people joining. Actually, we had a lot of people join at the start and they said
Gonzalo (23:17):
That would be impossible for Arun. Arun loves a good meeting
Paul (23:21):
And get as many people in as possible,
Gonzalo (23:23):
Please.
Paul (23:23):
That's right. We actually had, because at the time during covid, everyone had worked remotely and then so we had asked people, oh, have you worked remotely before? And they said, yeah, yeah, yeah, I've done it. And then they get into superb base and they're like, oh, what I meant was same time zone. And to what they didn't realize is you spend 95% of your time coding and then 30 minutes a week you see people and that's it. So yeah, we had built up this written culture that really we became very good at weeding out the people who just didn't like that type of culture. So the written culture is the most important thing of superb base now, and I don't dictate too much the roadmap or anything. We hire very good people, a lot of founders who just know what they're doing. Then it's really about getting alignment and consensus around the weight that what we might ship, how we might ship it.
(24:20):
So we use notion a lot at the start, and we do this thing in RFC, which is very common in open source. It means request for comments. And even this evolves. So what you do is say you put a problem, a solution, and then you put it out and you get some comments. What I found, which is natural for humans, is that when you do this generally you come up with a solution in your brain and you formulate a problem. So the RSE now is like problem. Who are the customers asking for it? And then three solutions,
(24:54):
The three solutions are really good because generally you'll think of only the first one. You become very attached to that idea, and especially in an async environment, it could be a day or two before you receive any comments. So having to put three decouples the solution from your ego essentially and allows you to think a little bit outside the box. And so yeah, that's how we do it still to this day. If someone's going to make a big change, they create an RFC with a problem, customers and three solutions, and then they put it out to the entire company where anyone can comment. And then at some point there'll be an approver, maybe me, and we approve it and they start building whenever they want. Generally, you start looking at your core metrics. For us, weekly active databases or weekly active projects is our key metric, and it's very tempting to automate that so that you just can see that anytime. But YCC says, oh, don't automate it. Just write it down every week, start a spreadsheet and manually input it. And so still to this day, every week on Slack and starts a thread called Monday Metrics Madness, and it's the same spreadsheet that we had since YC now with a million metrics,
(26:11):
And the teams have to go and update manually their metrics, whatever they've decided are their key metrics. We guide them a little bit, but they've kind of decided. And then inside that thread, they essentially do a team standup and you can follow on the replies. And that's how we keep alignment across the teams. Hey, we shipped this, this is what we're working on. And then if anyone's got questions, they pop them off into the relevant team.
Arun (26:37):
And the rationale of manually inputting the metrics is that the team owns it or understands it more
Paul (26:44):
That they've got to have the finger on the pulse. If it's automated, you're not going to look at it. And we've talked about this. One of the things that we're doing is this weekly business review. It's kind of hijacking the weekly business review process where you should know off the top of your head. For example, the Edge functions team should know the number of projects that were launched last week and what percentage of those launched started using edge functions, and they should have that number directly. And they do. They get really proud of how many people are using their product when they see it going up, then they dig into why that was and what changes they made. And that's the behavior you want to drive.
Arun (27:32):
It's a super unique way of building, but I think it's very true to both the problem that you're solving and candidly finding the best talent anywhere in the world to work together. I mean to get former founders that are used to having independence and freedom to sort of join forces and be part of the organization. I mean, I think you have to build it this way, but to date most of the business has been product and engineering. How do you think about that going forward and how you scale a system like this, particularly when you have to build out other parts of the organization that maybe are just a little bit lighter at this point?
Paul (28:11):
To be honest, I think the system that we're built is the scalable solution that most companies need to find eventually. You can't be across everything as a founder, I literally just cannot. So we're building this distributed organization that eventually a 2,003,000 person company has to find their feet on, and we hire these ex founders who have done that themselves. So they know they probably don't want to manage their reluctant managers, but they know that they have to do it and they've done it before. So I feel like we've kind of gotten ahead a lot on what the next stages of the company are going to look like.
Arun (28:53):
Yeah. You've referred to your talent acquisition model as Moneyball software. Can you talk a little bit about that?
Paul (29:01):
Yeah, well, at the start, so Moneyball of course is the movie where they had very little money, so they hired people in baseball with the best statistics, but maybe we're super cheap. Well, we didn't have a lot of money at the start, and so we're a startup and we're going to have to go up against these, the AWSs of the world, how can we compete? Well, open source was one of the ways that we did that. And the other really good way of doing that is just not looking only in SF and New York for your talent. We hired from anywhere in the world and not many companies were willing to do that. And so yeah, our company being distributed across 30 countries is literally because we would sc the earth to find the right person for the job that we actually needed. And then it didn't matter where you are, as long as you were willing to put your head down and do that job, we would hire you and now our salaries are going up.
(30:04):
So it actually also has a really nice effect that generally, let's say we hire you in Peru, there's no way a Peruvian company will compete with super based salaries. So over time, generally you have attrition maybe because your best people or people look at your company and they say, our super base are good, let's take their people. Well, now they're not willing to take our people because they're based all around the world. Whereas if we had hired here in sf, then of course they could just skip over to, I dunno, open AI or something like that where they'll get paid really well and it's just worked out really well for us.
Gonzalo (30:45):
How do you keep the cultural consistency as you scale? It's pretty remarkable how sturdy, hardworking, independent the whole team is. You've done so much with so little. What are the criteria? How do you keep it consistent?
Paul (30:57):
Yeah, I guess there's always two ways of thinking. That is you come up with a culture and then you develop people into your culture. I don't think that really works. I think you have to realize, be very deliberate about the type of culture you want, and then hire the people that fit that culture already. And I guess people think that's controversial because they think, oh, then you've got no diversity, which absolutely is not true. We've got extreme diversity, but the way of working is the thing that's important. Just being very focused on work, intrinsically motivated, low ego, all of these characteristics. It doesn't matter which country you're from or anything like that, or which gender you are or anything. We just look for these characteristics within people, and if they don't fit that, that's the kind of final bar raiser, then we just don't hire them.
Arun (31:53):
Paul, part of what I think makes Super Bay so special is just the community love around the product and the company. And it's obviously something that you guys have been very intentional about and have cultivated, but it's taken a life of its own. You have meetups in 70 countries around the world, a hundred, I'm behind on it, and the feedback just online is extraordinary. And so just take us through anything that you can share about the community in terms of metrics or size or engagement or what you pay attention to, and then some of the tactical things that you do to foster that level of community that we just think is very special and extraordinary.
Paul (32:34):
You can almost think of super base like concentric spheres of a company essentially getting looser and looser all the way out into a community. So we've got the core team that we hire, then we've got even the contractors, the maintainers, and then the community, and then the wider audience. That's largely how we thought about it from the start. And people can move in and out of these concentric circles. We quite often hire people directly from the community as contributors. Some of our first hires were just maintainers of tools that we needed that could be based in Peru or Spain or something like that. And we would hire them because we're fully distributed. The community's been amazing, honestly. And that's, to be honest, our biggest mode is just how awesome our community is. They can help, they can contribute. They find bugs, they report them, they give feedback, they hold us to a certain standard.
(33:34):
So it's kind of awesome that we get access to all of these people. In terms of numbers, we don't really measure. I mean, I think we're in a top 100 repo on GitHub, for example, by stars. We stopped carrying a lot about those sort of metrics early on. Now we're more focused on just making sure that the community itself are really benefiting. And so we do things, we don't publish them too much, but if people are regularly maintaining, we sponsor them. We pay maintainers for doing some of the periphery projects, like maybe our client libraries of different languages that we haven't yet made official. We can sponsor people to do all of that. So yeah, many, many initiatives that we've got going on just to try to support the community.
Arun (34:27):
On our side of the table, we see a lot of companies that start off with this mission around focusing around the community and investing in the community, and then they get bigger, they get more mature, some of them move up market and they lose a little bit of focus, I think on the community. If you look at Stripe, I think they're one of maybe the only examples of a team that has scaled, but also has sort of stayed true to their roots in focusing on the community and individual developers and getting started. And so why do you think that's just been so hard, and how do you maintain that focus of obviously building and scaling a commercial business over time, which is important, but also focusing on what made you special in the first place and that real community love and ency.
Paul (35:14):
Yeah, I mean it's nothing. It's pretty obvious. So what typically happens is developer tools, business starts scaling up with their community, then they start getting bigger and bigger customers. Those big customers take a lot of the attention, especially off the founders. And then the founders lose sight of the community because they have to cater to the big customers. And then eventually they realize, oh, they look back over their shoulder and they think, oh, our sales are slowing down. What can we do? Let's reengage the community. And at that point, it's too late.
Arun (35:52):
You
Paul (35:52):
Lost it already. You lost it. I mean, you have to keep your community. That's the thing that I've seen happen time and time again. I'm old enough now to have seen so many great developer tools that I've loved slowly wane in terms of the community love because I feel they lose the pulse of their own community. So the only way to solve it really is to make sure that those people who are significant in the company, the likes of and myself, continue to engage the community and we know that it's going to be in the long term, our number one mode. Can you
Gonzalo (36:29):
Speak to tactically how that progressed statically? We know super base is what it is today and is doing remarkably well. The community is huge, but it's not as if you and Ant and Rory and the like are Fortune 100 CMOs or sort of scaled companies in this way. Describe the journey. How did it start? What was the edge? How do you tactically engage with the community today?
Paul (36:50):
So from a tactics point of view, it was very easy at the start because our name is super base, which with an A and that's unique. So I just literally received to my inbox every single mention of superb base on the internet. I use this one F five bod, which kind of does red and it's very basic,
Arun (37:09):
But you got to tell us the origin of that name too.
Paul (37:14):
Yeah, that's right. Yeah, the basic origin was that. So I was trying to find a good database name and it was going to be ultra base or hyper base or some sort of base, right? I had to have base, I couldn't find anything. And super is S-U-P-E-R that was taken. And so as a joke, I just put SUPA base and it was a placeholder for Anton myself to exchange ideas. And actually the real reason was because an and I like a lot of memes and the Super Basses and Nicki Minaj songs, so we could make a lot of Mees The's favorite song by way. Yeah, not very good. Luckily not a lot of techies, no song. I think it's amazing. And that's pretty much it. When we hit, we eventually got found and someone put us on Hack News and it went to the top. And at that stage we realized, oh, we can't actually change the name, so you're locked in. So yeah, it's like one of my regrets. But yeah, now everything inside the company is super something Super Troopers and all these names in it. It makes me cringe all the time, but we're stuck with it. And I'm sure when we get to IPO, maybe it'll be our ticket symbol can be super.
(38:33):
Yeah. But technically speaking, just to find their mention of super was pretty easy. So to this day, I still receive all those emails. I mean, there's too many for me to keep up with, but I skim through and anything, especially now critical feedback, I'll jump in and I'll search on Twitter when people mention us and I'll actually respond to people. Just yesterday someone said they pinged me and they said, ah, I'm missing this on the open source repo, and they wrote Kiwi Couple. And so then I jumped into our Slack, said to the front end, Hey, is this missing? Our front end person responded in them within the space of 12 hours, we had fixed this issue. It wasn't even a GitHub issue, they just pinged me on Twitter.
Gonzalo (39:23):
At what point does the community come sort of self-sustaining versus your bootstrapping responding to every request and then now you described there was an older guy, I think maybe in Arizona who's on Discord, who's prolific. So how does maybe share that anecdote? How does that happen?
Paul (39:37):
Yeah, so the point that it becomes self-sustaining is basically when you find someone like Gary Austin who's like our guy on Discord, and I think he's maybe in his sixties and maybe I think he worked at IBM, I don't actually know all those details, but he worked at IBM for a while and kind of retired and he was a bit bored. So he was just in our discord answering all these questions and now it's a bit of a meme When he's offline, the community doesn't know what to do. And so yeah, we were really lucky and at one point we thought, oh, should we employ him? But actually he's more valuable to us as a community member that we keep a looser relationship. He's kind of like the bond between the fly by community members and the internal team and the way we work with him. We also have a contributor Slack where he sits in a single channel and then he kind of fits between our Slack and the Discord and GitHub.
Arun (40:36):
What do you do when the tour are in conflict, meaning what the community wants and is requesting for that might not be commercially a big thing for you to do, might not be what your upmarket customers are thinking. I mean it all logically makes sense and I think there's a lot of overlap, but there are moments I imagine in the past and certainly going forward where the two are going to be in conflict. How do you trade that off?
Paul (41:01):
We don't do it because we see it as a tactic or anything. We use open source tools. We benefit from open source tools. Postgres is the core of our business. It's our way of giving back as much as we can. So it's often not a like, should we do it or not? It's usually to what level can we reasonably do it? Then the other one is when it's a tricky product. So for example, a really common ask that will we do hosting of websites? And I get it all the time and I just say no. And this one comes from that. There's a famous Steve Jobs quote where he's up on stage and he says, focuses is about saying no for us, if we want to build the world's biggest database company, there's no way we can do that while simultaneously trying to solve front end hosting. And to be honest, there are already, Versal is phenomenal. Why would we bother even trying to compete with them? We are focused on the database and if we continue to do that, our outcome won't be that Oracle outcome rather than some Heroku like outcome, which is still reasonable, but we want to really solve database problems.
Arun (42:20):
Yeah, luck and timing had so much to do with company success. And for you, you launched superb base in 2020, well before the Chachi PT moment, but the AI wave is here and you guys have a product that's sort of meeting the moment. And so talk a little bit about how you view ai, these AI app builders, the explosion of applications that we're seeing, and just how much of our focus is on that versus the traditional enterprise database market that we were built to serve as well?
Paul (42:55):
Yeah, I mean luck plays a huge amount within a startup. I mean, even going back to the early days, no, absolutely no way we could have built the database company that we have without that kind of VC hype cycle at the start, it takes a lot of cash to build a database company. So we got very fortunate with our timing and it wouldn't be the business it is today without a lot of luck. Now we see this new, the AI builders, the chat GPT explosion, like you say, and it's this moment in time. I feel that a lot of builders, new builders are pouring into the market, and I love it because they've got the same sort of energy that I did when I was learning to code. They just see that they're producing something rather than consuming something. And that's why we built this business.
(43:51):
We like that people are building. So a lot of our focus this year, and the reason why we bring more people on and more capital on board is to be able to service that grows or signup rate basically doubled overnight, which means support tickets double overnight, which means that traditionally your roadmap also gets delayed. So our question this year has been how to service both. And in particular, my focus this year is how to make that experience for builders phenomenal like we did for developers. And eventually those builders will become the developers, they'll learn how to code for sure. I think maybe not to the level that a developer of 20 years has been doing, but I guarantee at some point they'll start dipping into it. And that's awesome.
Arun (44:38):
Paul, maybe as the last question, how do you think your role and leadership style has evolved over the last five years?
Paul (44:46):
That's a great question. Technically, the roles changed from doing a lot of coding to doing no coding, which is a shame. But of course that's going to happen and you can only hold onto that so long. So these days I start projects and I don't have enough time to finish them. So that's actually, I became a liability. And the truth is when I started, I thought I'm a pretty good programmer, I can do some stuff. And then I hired all these people and I realized I'm nowhere near as good as the talent around the world is phenomenal. So that's one thing.
(45:29):
Then yeah, I guess. So there's that shift in focus and then you have to eventually become just more focused on developing the culture, the team, the people within the team. They're going to start managing people as well. So making sure that they've got the right mindset around how to manage. And usually that's a bit foreign for people who haven't managed before. So essentially my job is finding alignment across everyone. And as you are growing, you lack alignment, which is natural. How do you keep a hundred people pointed in the same direction? So yeah, that's really my job and it will be my job for the next decade or so.
Arun (46:16):
Yeah. Well, Paul, thank you for doing this and sitting down with us. We're so excited about the journey that we're on together, and so appreciate you spending some time with us.
Paul (46:26):
Thanks for having me.
