Code with Jason
Code with Jason
272 - Anthony Eden, Founder of DNSimple
In this episode I talk with Anthony Eden about building DNSimple, a DNS provider and domain registrar. We discuss his 25 years in the domain industry, technical challenges, and why specialized niches create natural competitive moats.
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right, I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonnier from Dickinson, Texas says just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly dot com. That's nonsensemonthly.com. I'll say it one more time. NonsenseMonthly.com. And now without further ado, here is today's episode. Hey today, I'm here with Anthony Eden. Anthony, welcome. Hi, thanks for having me, Jason. So you're the founder and CEO of D and Simple. That is correct. Yeah. So a lot of people listening to this are probably familiar with D and Simple, but tell us about D Simple.
SPEAKER_00:So for those who don't know us, we are a DNS provider and domain registrar. So we provide authoritative DNS, domain registrations, transfers, and renewals, and we also provide SSL certificates. And we've been in business now for 15 years. I started the company with my brother back in 2010, originally just focusing on the DNS side of it. Started in, so I wrote the first line of code in April of 2010, launched at RubyConf in July of that same year. And then proceeded to add domain registration also towards the end of that year, based on feedback from people that I knew on Twitter and from my networks who said, wow, I really we really want to be able to register domains too. So we added that. And that's kind of been our mode of working since then, right? It's just focus on domains, DNS, building tools around that really for developers and for other engineers. Um, and just be a very specific niche, serve that niche well, and it's resulted in a pretty successful little business.
SPEAKER_01:Um, so something I'm definitely curious about is like uh a domain. I don't know, what what do you what what label do you put on it? Like it's not a domain registrar, is it like how would you describe it?
SPEAKER_00:So we are a domain registrar, and what that means essentially is that you have accreditation to sell domains to the general public, and you get that accreditation through an organization called ICANN. And so um we've done that, and then we also resell domains because for each top-level domain, so.com, dot net, dot org plus all the other ones, you need a separate accreditation with the registry. So that's the group that actually man manages the database for that TLD. And so it's kind of cost prohibitive unless you're selling a lot of a particular TLD. So sure, it might make sense for Calm or Net, which are going to be the majority of your sales. But you might have these random country code TLDs and be getting accredited with each one of them is very expensive. So, in terms of time and also just uh investment. And so what we do is we resell some of the TLDs uh as well. So it's kind of a you're you're still doing the same thing. You're selling domain names or allowing customers in the general public to register domain names through your service. Um, and uh it's just in one case, you're doing it through your own accredited credentials, and in another case, you're using some third-party provider that does that.
SPEAKER_01:Got it. Okay. Yeah, and I I understood that DN Simple has domain registrar capabilities. I just wasn't sure that it's appropriate to say like DN Simple is a and then fill in that blank with, I'm not sure what would go in that blank.
SPEAKER_00:Yeah, we are a domain registrar, we are a DNS provider, and we are also a domain reseller. Okay, got it. So that that's kind of the the areas that we can say we are definitely those things.
SPEAKER_01:Okay. Um, and whatever you call that group of those three things, it's obviously not just like a straightforward crud app. Um no, definitely not. Yeah, and and from a technical perspective, I think that probably takes a lot of like specialized knowledge and um a lot of I imagine crazy programming to get all that stuff to work. And so, like in the in the beginning, when you approach this thing, I think a lot of people would have been daunted by the prospect of doing something that's so um not straightforward. And so my kind of two-part question is like maybe it's just a one-part question, like like why this? Like, what led to this specific thing? What made you feel like you could do it? That kind of stuff.
SPEAKER_00:So I have actually been in this industry for quite a while. Uh in 1999, I worked for one of the first seven domain registrars when the dot-com TLD was deregulated. So prior to that point, it was run by a single company. That company was Network Solutions. They had the full rights to manage the entire domain and sell those to the public. In 1999, they accredited seven registrars, and I was the CTO at one of those registrars and proceeded to get into the industry through that job. Then throughout my career before DN Simple, I off and on kept coming back to domain names. I ran the.mp registry, which is the Mariana Specific Islands. And so I ran that registry and that registrar, uh, both the customer face, like the consumer facing as well as the other registration facing side of it. And I during this process, I also learned a lot about the operations of DNS itself. So that so DNS and domains has kind of two sides. It has the intellectual property side, which is really domain names, and ensuring that those are registered to the right entity and that they are renewed regularly, so on and so forth, and that they're protected. And then the other side is the operational side, which is the authoritative DNS, the DNS resolvers. That's the thing that we actually use when we use a web browser and we go to a website and it looks up a name to determine what the IP address or addresses are that should go to. And so throughout this, I learned a little on both sides. Um, and I kept coming back to it. And in 2010, I was wrapping up the sort of or winding down, I would say, the startup or that was built around.mp because it didn't really take off the way we'd hoped to. And I was using, and I'll say it, I was using GoDaddy at the time, and I was like, oh, the DNS side of this is terrible. Not to mention the registration side. It's great. Ah okay, it's funny. Um so so at the time it was really, really bad. They they were doing a huge amount of business, but the DNS side in particular was pretty horrendous because that wasn't their focus. Their focus was get people in registering domains quickly, upsell them on different products, including web hosting, things like that. And I was like, I just want to focus on the DNS side. So I started just doing that. And I had already written at that point two DNS servers, two authoritative DNS servers. Um and so I was like, okay, I know enough about the operations that I think I can do this. Uh as I mentioned, I started the business with my with my brother, though, and he's actually the one that set up the infrastructure. So initially we were running open source DNS software, because there is authoritative DNS software that's open source. We were running that on single VPS servers. So these were virtual private servers that were running for 20 bucks a month. We ran four of them. Uh we ran a network that was it's called Unicast, so that means every IP address is mapped to only one single name server. And that was the start. So it was really a very minimal setup. And the Rails app talked to a database and it pushed into a database that those name servers use directly. So it was surprisingly simple conceptually. It grew very quickly beyond that because there are scalability issues with Unicast, there are scalability issues with virtual private servers, and and we knew that we were gonna have to do more than that. So we eventually started moving to managed hardware, started moving to what's called an AnyCast network, which is where a single IP address can actually uh go to many different machines. Um and so there was all kinds of changes that occurred over time, but it started off pretty simply actually.
SPEAKER_01:Interesting. Um yeah, okay, so part of why I'm interested in this stuff, one reason is because I've always been interested in going like further and further toward like the bare metal, like the smaller, more fundamental building blocks of the internet. Um and just like when you type in a domain name in your browser and hit enter, like what happens exactly? Um, another reason why I'm interested is because I'm building a product, it's a um CI platform, which is also very much not just like a straightforward crud app. Indeed. And and one thing that I like about this idea, I don't know if you had the same feeling about what you did. I'm curious if you did. Um something I like about my idea is it's kind of a moat in that it's you have to be kind of insane to go after it. Um like I don't think building a CI service is something that would even occur to most people as like a realistic undertaking for a solo dev. Um and I wasn't even sure how viable it was, but I I headed down the path, and turns out it's not that hard. At least, you know, I've been programming for 20 years, and so I have some somewhat of a boost from that, and then AI has been helping a ton, and and that shortened the path a lot too. Um but I'm like this is great because like I don't think a lot of people are gonna follow me and try to and try to beat me at this. Not that I not that I was very afraid of that anyway. But for you, um, was that part of your thought process at all? Like this is something that like not a lot of other people are gonna go after?
SPEAKER_00:I would definitely say the if that running an authoritative DNS service didn't seem like something that a bunch of a bunch of people would go, ooh, I want to do that, right? I mean, because it you're talking about 24-7, 365 operations. Can never go, you can't really go down. You're talking about something that is core and fundamental to the to the internet. And so you have to have, I think, a good long-term drive to make it work and then keep it working. We just can't just go, oh, this didn't, you know, at least maybe early on we could have, but even doing that, once people start using it, they're depending on you. And I think that made me feel, okay, maybe not a lot of people are going to do this. At the time, I think also there we were at a transition phase where there was a lot of old guard, right? So there were a lot of companies that had already been around for 10 years doing authoritative DNS, um, doing domain registration. And they had, they were kind of set in their ways. So I think a more for me, the motivation wasn't, well, I have a moat. It's that I didn't think that they were doing a very good job. And that was broadly. Like I didn't, I think across the entire industry, it felt at the time that things had kind of stagnated. And I was like, let's shake this up a little bit. Let's take away all the crud, the junk that has been associated with domain registration, that's associated with managing DNS, and trim it back to its most basic possible use case and experience. And so that meant, for example, uh registering a domain name. I dropped a bunch of the things that you would normally collect. So it used to be, and I don't know how many folks remember back then, and some still do this, but it used to be that you have to go through and fill out who you wanted the administrative contact to be, who you wanted the billing contact to be, who you wanted the technical contact to be, who you wanted the registrant to be. Even if they were all the same person, you'd have to do it over and over and over again. I was like, well, that's a waste of time. Let's just collect one and just assume for now that's the same, the same entity is gonna do all these things. And it got us surprisingly far. You know, it's like it, it just the dis the distinguishment, the distinguishing factors between those contacts wasn't enough for the vast majority of our customers. They just didn't care. Same thing with setting up name servers. Instead of forcing everybody to pick what name servers they were gonna use when they're when we registered, we just said, well, let's just use our name servers and make them work right away. So you just you use it and then you're on the interface and you start setting it up. Um, or I want to connect to specific services. So at the time, you know, Heroku was was an up-and-coming service. Lots of people were starting to use that. There were other services that people were using for building web pages. So, well, let's just make it so that you have a one-click and you create the DNS records. So I think a lot of it was just driven by an opportunity to innovate a little, not to mention the fact that none of those services had APIs that were worth a darn. Right. And so all of these were factors and they corresponded well with kind of where the web apps were going at the time. Um DN Simple's written in Ruby on Rails for the front end application. And at the time, there was a lot of energy behind Rails of have a have a UI, but also have an API and make them both functionally cover everything that you're going to be doing. And so I went in with that mindset when I started working on the API as well. And again, I think this was just looking at the competition and saying there's a lot of opportunity here. They're not really paying attention, so let's go do it.
SPEAKER_01:And it worked. Yeah, yeah, that's great. Um, you might call that something like a uh revolutionary application of common sense. Like everybody else is doing it in a way that's like, I don't know, I call it reaching over your screw reaching over your shoulder to scratch your ass. It's like going through all these extra steps for like no good reason or whatsoever. And it's like obviously, clearly, it would be better to do it this way instead of this way, and yet nobody's doing it. That's how I feel about the existing CI providers, um, mainly just GitHub Actions and Circle CI. Um what's the like main reason a CI service exists so that when a test run fails, you can see what went wrong. It's like a you had one job kind of thing. And when a test run fails in those products, you have to like go through several layers of stuff and then scroll manually, and it's like, hey, you're a computer, like you could have done this job for me, but you're making me do it several times a day, and this is just so dumb. So my uh revolutionary application of common sense was that when a test run fails, it shows you what failed.
SPEAKER_00:Imagine that.
SPEAKER_01:Yeah, exactly. Um, yeah, and my um you know that the thing about emote definitely ranks low on my reasons for doing what I'm doing. It's more just like a frustration or even contempt for the way that the other products do it. And something I've noticed, and I'm sure you've noticed this too, is that the the risk of one of the incumbents improving so much that they beat you is negligible.
SPEAKER_00:Correct. Yes, that is absolutely the case because there's they don't have a financial incentive to do so. They actually have a financial incentive to remain stable because they have a customer base that has a set of expectations. And if you have a customer base that has a set of expectations, you can't just keep changing your system because you're gonna make them frustrated because they have a set of expectations, and if you don't live up to those, you're in big trouble. I do think that there the bigger risk is that new competitors come along. And in fact, we saw that in our industry when D Insible was launched in 2010. Um, Amazon wasn't in the DNS business yet, Microsoft wasn't in the DNS business yet, Google wasn't in the DNS business yet. So you're talking about three, uh the three 800-pound gorillas all joining in at a later date. And so that clearly is a factor in what we saw in terms of our growth. Those companies come in and it would, it becomes much more difficult to go after a certain class or a certain type of customer. But what's interesting is that there's still there was still a lot to go around. Not everybody wants to use one of those services for a variety of reasons, right? And then even more recently, some people want to use all of those services, maybe not for DNS or maybe for DNS, but they want to be able to have some diversity in their in their cloud infrastructure. And so we started looking at that and said, well, let's adapt our systems so that we can look into those different infrastructures and see them all together. And that actually resulted in what we call the domain control plane, which was this idea that you could connect to Amazon and you could connect to Azure, and you could actually see your zones that are there from within DNS simple as well, alongside your other zones. And you can actually move DNS records back and forth between them. And so I think you're right that the incumbents aren't the real like the this the real incumbents, the ones that have been there for a long time, aren't going to change. And instead you have the new group that's gonna come in, and then they become the incumbents and they don't have the incentive to change, and the cycle continues, right? At least as long as the technology is still viable.
SPEAKER_01:Yeah, and the um the cynical asshole in me, which is most of me, um knows that like even though they aren't motivated to change, like they couldn't even do it if they wanted to. Um because very difficult. Yeah, because from a technical perspective, like everything you do gets so like ossified over time. Um, your early decisions get buried under the weight of your later decisions, and the idea of like, oh, we like fundamentally misnamed this this um like really fundamental concept, so let's clean that up. That like never happens, um, or like a certain UI. Like once your app grows into like all these different pages and stuff like that, um you can't really change the like okay, but there there's there's the like superficial appearance of your UI, but then there's your conceptual model of the product, and that's a much deeper thing. And the the visual appearance of the UI and how the UI works and stuff like that, all that stuff is downstream of the conceptual model of the program. And your conceptual model is very hard to change, and you're never ever gonna get it right the first time. And so, unless right from the very beginning you're willing to continually step back and reassess and do the like painful, expensive work of reconciling your conceptual model with the new reality, then years are gonna pass and there's gonna be so much weight on top of those early decisions that they're never gonna be changeable.
SPEAKER_00:Absolutely. There's I can tell you there are still some design decisions inside the heart of the unsimple that could could they warrant an update, but it's the cost of doing so outweighs the benefits so greatly that they don't we don't usually look to it to tackle those things. We might slowly chip away at them, and then one day we get to the point where the you know cost-benefit analysis flips the other way, and the benefit becomes so great over the cost that it's worth investing in. And I think we've seen that internally in Dean Simple on a couple concepts that we've changed over time. The the most obvious one was some of our early implementations of users and accounts. So we bound everything together initially where a user was an account. So you logged in, and those credentials that you use were tied to things like billing and access control, right? And that at first that was fine, but over the years, that binding started to get more and more difficult to uh it started blocking us from building new things. And so at one point we had to decouple those. And that's not an easy thing to do when you've built this stuff all throughout your application. But we managed to pull it off and got to the point where we now have a uh a many-to-many relationship between users and accounts. So many users can be part of many different accounts, which I think is interesting because we have a lot of folks that use us for their personal domains. So I have domain names, but I also work on DN Simple's domain names. And in DN Simple, we segment domains for certain reasons, like we might have our production domains in one account where it's highly restricted, but then we have other domains that we're experimenting with for fun, right? We might build a site or run something off of it that we don't even know if it's gonna live. And so we can run these different accounts, and I can use my single user to get at those different accounts and have different access control. But when the two were bound together, that wasn't even possible. So you're right, there are fundamental design decisions that we put into any application code. And the bigger that code gets or the longer it lives, the harder it becomes to change. I I think also there's something more fundamental though, which is if a business has to continually race towards the next goal, whether that's raising the next round of funding, uh getting the next round of debt, um, going public, you know, growing to the next revenue target that they have, the last thing they're gonna do is let's update our core systems because it's hard to move. No, they're not gonna do that. They're more likely gonna go build around it until you can get rid of it because we don't care. We just need the business to keep moving forward. Whereas a smaller business like ours that's profitable, that we don't, we're not, we never raised any funds, we didn't need to. We have the the choice and the leeway to say, no, actually, we're gonna fix this. It's gonna take some time, we're gonna continue servicing our customers, but we're gonna go in and we're gonna change this core fundamental model or relationship, and we're okay with that.
SPEAKER_01:Yeah, yeah, because I think it's the I mean I mean there's asterisks to this statement, but like I think it's the smart thing to do. I think it's a a short-term, long-term question. Um, like if you just take your take your early um the stuff that you build early on that's maybe like uh in need of a change, but you just build on top of it even though it's no good anymore, um and and and and make that part of it frozen so that it can never be changed, um, you get that short-term benefit, but you hurt hurt yourself in the long term and lower the ceiling of your future potential. Um whereas if you do the opposite, then you get the opposite result and and you can grow more later and you can go faster later than you could have instead of continually slowing yourself down more and more. Um, and I think it's one thing to make a conscious decision between those two things. Um, you can say, like, okay, I know this is gonna handcuff us for the rest of eternity, but we're gonna do it this way anyway, because we're gonna sell the business in two years and I don't care because I won't be around for that. That's a valid choice. What really bothers me and and what I'm building in reaction to is when people are uh dishonest with themselves or or they're not intellectually honest about the causes and effects and stuff like that, and they say like, oh, we'll uh we'll just build on top of this crap now, but we'll clean it up later. But it's like, no, no, you're not. You're not ever gonna clean it up later. Nobody ever cleans it up later. So uh just tell the truth and and admit that you're gonna handcuff yourself forever because of this. Um, don't pretend that you're gonna come back and clean it up because nobody ever does.
SPEAKER_00:You're you you're you're correct in that it very rarely happens. I can tell you though, that that again, if if you build systems in your business, so if you're if your business gets the point where it is sustainable, so that means it's profitable, you don't have debt, you can, you know, you're growing even if it's very slow or you're stable, and it's satisfying your needs as the owner or the owners of the business, then you have an opportunity to put processes in place where you can say, and we're going to invest a specific amount of time in maintenance. And where maintenance is not just making sure everything is up to date, but also fixing broken windows. Um you're never gonna hit everything. Like there's always gonna be more things in your software that you're gonna hate that you're gonna want to change, then you have the time to change. That's the that is a that is a fact. But it doesn't mean that you still can't invest time to change things that you that are strategically valuable to change. And that's really the difference between uh a company that is rocketing towards something and and taking all, like they don't they'll just say, we don't care about the damage we cause along the way, we have a goal and we're getting to that goal, versus a company that says we're on a slow, stable path. And as part of that, we're going to build for the long run and we're going to continuously work on improving software, processes, whatever it might be that you want to improve at the business level. In a lot of ways, business is like software, right? It has a lot of moving components, it has a lot of people putting their hands into it, it has a lot of processes. It can be just as unmaintained as software. You can have businesses that you go and all it is is dead bodies everywhere. Like if you go start digging, you just it's terrible. You find like the accounting is terrible and the legal structures are terrible, and the the way they treat people is terrible. And you know, I've never seen that. Every place I've ever worked has been great. I'm sensing a bit of sarcasm here. Yeah, exactly. No, I mean, every it it's there's cracks in every foundation. Foundation for whether it's for software, for business, or anything else. There's always gonna be cracks. And sometimes those cracks have to be fixed in order to move forward, or they have to be built around, is what it comes down to. And as a business owner or a software developer or whatever you might be, it's your choice to decide if you're gonna invest in that or not. And that's a choice. Like you said, there's no right or wrong answer. The right or wrong answer is at the end of the day, are you getting what you want out of this thing? If it's a piece of software, does it do what you want to do in a way that you're happy with? If it's a business, does it make your life and the lives of the people around you better? If it does, then okay, it's a problem, maybe doing what you want. You know, so yeah, that's my approach at least.
SPEAKER_01:Yeah. Um, yeah, and again, that's a totally valid choice. A lot of products, uh I might even say most products are just trying to build things that that check the box, and it's like, okay, we need a feature that does X. We don't care how it accomplishes that, we just need that to be physically possible with the product. Um, and like you say, that's a valid choice to operate that way. Um I am extremely tired of operating that way, and I I want to build something that's actually good. Um, even though it has become like kind of a cliche at this point, um the more I think about it, um, the more I think about it, the more I admire Steve Jobs and Apple and the whole philosophy around that stuff because they put out truly excellent products. And I feel like Steve Jobs looked at everything in just a completely different way than most people look at things. Um and I feel like most people, either consciously or unconsciously, believe that making something truly excellent is not an option. Um and maybe they're right, but I don't want to believe that. And with what I'm building now, I'm like, let's see about that. Like, is it really true that I have to slap some garbage together and like I just have to make it work somehow, and it can't be actually an excellent product? Um, is is that a trade-off that I have to make? Or can I make it excellent and a great business success, and maybe even a bigger business success precisely because it's excellent right from day one. Um, that's what I'm interested in.
SPEAKER_00:Well, let me know how I look forward to seeing how it turns out because I think it's you've you've set a very high bar for yourself that is going to be challenging to meet your needs at your desire sort of for this excellent system and your customers' needs, if you whether you have them now or have them in the future, to solve a problem. Because at the end of the day, your customers, the only quality they care about is their experience from the outside. They'll never see the details that you care about. That doesn't mean you can't care about them. As the business owner, you get to make that choice. And by the way, that's the greatest thing about building your own business versus working for somebody else. Is it's on you to decide where you're gonna invest your time, right? And what matters to you.
SPEAKER_01:Yeah, and to be clear, the the parts that I'm trying to make excellent are specifically the parts that they care about.
SPEAKER_00:Good. But then then that's if you're gonna focus on one thing, focus on the thing that your customers care about, and you have to keep asking them because what they care about today might be different than what they care about a year from now or two years from now, right?
SPEAKER_01:Yeah, and you know, I'll even put a nuance on that. Um there's you know, that book, The Lean Startup and that whole movement and stuff like that. There's there's a lot to be liked in that. Um, but I feel like there's been this um unfortunate uh takeaway from all that that is it's it's not quite exactly correct. Um people people quite rightly um highly value the idea of talking with customers and responding to feedback and and acting based on that. Um but I think it's one layer too shallow. Um and again this goes back to the Steve Jobs thing. Um like a lot of businesses ask their customers what they want and then build that stuff. I I I think that um what is really needed is you have to go a layer deeper and don't ask people, I mean, ask people what they want, but like also don't ask what they want. Go in and understand them and their jobs. Like, who are these people? What are they doing all day, every day? Um, I've suggested to my consulting clients, and more than zero of them have actually taken me up on this, uh, actually go fly physically to them and spend time with them in person and like go to their like warehouse and let them show you around and show you their work and stuff like that. Sit next to them while they're on the computer and watch them click around and stuff, because they are going to abuse your software in surprising, horrifying ways that you never could have guessed, and that they will never tell you about because they don't even realize that they're like doing they don't realize that that's worth mentioning, they just think they're doing the natural thing that they would do. Um and then take that and be the product designer, like don't outsource your job to the customer and let the customer design the product because they probably don't know how to do that. It's your job to instead understand what their job is and then design a product that can help meet uh their needs. And I'm not saying that because I don't think you knew that stuff, um, but there's a lot of people out there who um, again, go one layer too shallow.
SPEAKER_00:Sure. There there are it's it's easy to ask somebody what they want and they will tell you all kinds of things that they want. It's not necessarily what they need. I think that's this the one of the things you're talking about is to truly understand what somebody needs, you have to truly understand the problem that they're facing. And you can only do that by seeing them, not hearing them tell you, by seeing what they're doing. Um, it's also very costly to do that, right? Like you talk about I'm gonna travel to a client or many clients in that case, that costs time and it costs money. And a lot of small businesses don't have that. So what they do is they that we look on our own experiences and say, I'm doing this thing as well, so I'm gonna solve this problem because I'm doing this thing, which is a valid way to start a business, right? It's very common that a lot of folks start a business based on something they're already technically savvy in, whether that's writing software, baking bread, or whatever it might be, um, because they know the area and they know the problems they face and then they try to solve those problems. At some point, though, your business moves beyond you, and now you have people that have problems that you don't even see or understand without getting out there. But it's tough. Like I do love getting out and getting to events where I can talk to people and actually see some of the things that they're doing. Like they might show me, hey, I'm they'll like pull up D and Simple and they're like, I this I went here and this thing happened and it was really weird. And I look at it, I'm like, uh, I didn't even know we were doing that. Or I'll go through myself and I'll be trying to manage a domain, and I was like, something doesn't work the way I would expect it to work. And I and so it's important, I think, to get regular feedback from folks who are actually using the thing, see where they're they're having trouble with it. And then what we do is so we I don't know what I don't know if you've heard of the ShapeUp process that came out of Basecamp. So we use ShapeUp at DN Simple now for a couple years. And one of the things that was added to ShapeUp after the initial book came out was this notion of framing. And framing is describing the problem in a document in words. Not describing a solution, but describing the problem and iterating on understanding the problem in that document until you've really reached what you believe is enough of an understanding to then go into the shape part where you talk about the product. Is like you now I'm designing the product, the piece for that product, the feature, um, because I understand the problem. And initially we didn't have that piece and it felt like we were missing something. And when we added it in, it was like, oh, okay, this makes a lot of sense. And it took some retraining because we're almost all engineers at DN Simple who are working at the product level. It took some retraining to not jump straight to solutions. We actually had to stop ourselves from writing solutions and instead focus in on the problem and the people that are impacted by this problem and what they imagine is the world after that problem is fixed. So that that was very helpful for me is adopting the framing portion of ShapeUp and adding into our workflows so that we could better understand the types of problems that we have. And I think it's been helpful for building better systems. Sometimes it produces weird output. Like if the frame is off, then the design of the solution is gonna be off as well. But more than not, it's been super beneficial to be forced to think this way.
SPEAKER_01:Yeah, I think there's a lot of wisdom in that. Um understanding the problem before coming up with the solution. Um in most work situations, most of the time, my experience is that those two things are very muddied. Um, the solution is mixed up with the problem, and it's uh people talk about what they're gonna do, um, but it's it's not clear what parts of that are um are the solution and what's if if you ask, like, okay, we're doing this thing, but like what exactly is this all about? What's the problem and why this solution and not some other solution? And that stuff is not always thought through. And if you separate it and make a clear statement of the problem, then it's like you you I look at some of these things as like writing to disk so that you can free up your RAM. It's like you take the problem and you can write that to disk, and now you can take all of your now free RAM and bring that to being. Yeah, yeah. Yeah, and that goes back to the um, you know, doing research with customers and stuff like that, spending time physically with them and and that kind of thing. Um because all that is like upstream of your understanding of the problems and the kinds of solutions you're gonna come up with and stuff like that. And it's just so depressing the way it works most of the time, like people making product decisions based on like telemetry, and they think that that's that's a way to do it. It's like, well, uh, they're spending 54% of their time on this page, so that means we need to. And it's like, no, that's like so superficial. You gotta actually understand what's going on, not just look at the most surface level stuff.
SPEAKER_00:Well, I wouldn't get too depressed about it. I see it as opportunities, right? I see it as opportunity to make the world better, to help people who are trying to be problem solvers to understand problems better and give them systems to do so. That's one of the reasons why I appreciate something like ShapeUp, is because it's it's a system, is what it is, right? It's something that's designed. It works in certain cases, it doesn't work in other cases, but gives us a framework within which we can think and which we can operate and which we can try to do better. Sometimes we'll fail, sometimes we'll succeed, but all in all, at least we're moving in some direction where we're trying to make improvements. And I think that's a good thing. I don't feel uh yes, there are a lot of people out there that are stuck in environments or are fostering environments that are not healthy, I would say, healthy for the business, healthy for their customers, healthy for their team members. Um but the only thing we can do is we can keep pushing that envelope, trying new things, see what works, and then get out there and share that this thing worked for me. And you caveat everything that you do that this worked for us. When I go out and talk about this, I always say it worked for us, and here's where it didn't work for us. Like I'm totally honest about it. There are certain cases where we've tried ShapeUp and it has been a flop for us. But it doesn't mean that ShapeUp was the problem. It just it's again, it's like trying to try to you have the solution. What is the actual problem first? So take a step back and and frame that problem. And I think I found it extremely enjoyable to to have continuous improvement in the business or to foster and attempt continuous improvement in the business, even if it doesn't always work out the way I'd hoped.
SPEAKER_01:Yeah, yeah. I mean, at least making an effort is is um it gets you a lot of the ways there. Um I have a completely different question, which is in those early days, how did you get your first users and customers?
SPEAKER_00:So that came the first folks were in the community that I was already pretty strongly involved with, which was the Ruby community. So at the time I had been uh speaking at Ruby conferences and Rails conferences uh in different places. I had been um heavily active in a number of open source projects, some that I had created myself, some that I helped others on. Um and so and I was active on social media uh where I could go and say, I'm building this thing, and the people that I knew were like, oh, cool, I'll give it a try. And so those were the earliest customers at DN Simple, was people that we knew. And I think for the first 20 or 30 people, it would, they were all people that we knew. And then it very quickly became people that they knew because they started telling other people that were in the space, and I didn't necessarily know them, but now we were, you know, one person removed, but they were like, Oh, I'm trying it out, and then I'm trying it out. And so that that became a nice early cycle where we didn't because we didn't have any money to invest in advertising or much marketing, anyways. All the marketing that I did was me going out to events and basically guerrilla marketing, going and talking to whoever I could talk to, whoever would listen and tell them, hey, this is what I'm doing. Uh, you know, if you need something like this, it might work for you. If you're unhappy with whoever you're using now, it might work for you. And so that was really the early days for the first customers.
SPEAKER_01:Yeah, that's interesting because that's very close to my plans for getting customers for my product. So my my my first objective um was to get just anybody using it in any fashion, like even if they weren't paying anything, just get somebody onboarded onto the platform just to prove that from a technical perspective it could work for somebody who's not me. Um and I got like four or five people who who did that, so that was nice. Um, and then recently, and and so then my next objective from there was to get an actual paying customer. Um, and I recently got my first one of those. Congratulations. Thank you. And now I'm dealing with scaling issues because this is like a real project, and apparently my system can't scale from zero users to one.
SPEAKER_00:Um, so I'm it's one of the hardest parts to get. You got to get that first one, right? Before you go beyond that. And then it's just N. So, right? Like zero to one and then one to N.
SPEAKER_01:Right. Yeah. So surely the second customer, unless I get a huge one, which great problem to have, but that'll that'll be easier. Um and these these all were like people, not necessarily people I had known personally, but like people in my orbit. Um they like maybe I didn't know about them, but they knew of me. And so when I like put out a tweet, they're like, Oh, okay, I'll check out that thing or whatever. Yeah. Um, and then this first customer is somebody I've known for a long time. Um and I'm I'm intending and expecting that my first handful of customers will people will be people I get that way, just like manually going out into the world and grabbing people and being like, Hey, do you want to try out this thing? And then it's interesting what you said that kind of the next wave of users or whatever are people who those people knew. Um, I think maybe a lot of people, certainly myself in the past, like I was thinking about like scalable ways to get customers. And I realize now, or at least I'm of the opinion now, that like in the beginning, scalability is kind of irrelevant. Correct. But the the point is to get somebody uh and to get that kind of um I don't know, kernel of a user base, and if you can expand that by 10%, then good. Because like at every stage, what got you to that stage is gonna be different stuff than what gets you to the next stage. It's not gonna be one thing that gets you from zero all the way to a hundred million dollars, it's gonna be different stuff every couple months or every year or something like that. You're gonna have to adopt a completely different strategy. And what's appropriate for getting from a hundred customers to a thousand is not appropriate for getting to from zero customers to ten or ten customers to a hundred.
SPEAKER_00:Yeah, every time you add a zero onto something, whether that's the number of customers that you have, the amount of revenue that you're pulling in, the amount of traffic you're pulling in, whatever it might be, the the requirements are going to be very different. Like getting to that next step and the things that come after getting there, right? I was joking about the zero to one and then one to n. I mean, that's the dream, but the reality is that you know, one to a hundred might put you into a different scalability problem that you didn't foresee. And then a hundred to a thousand will be a different one, and a thousand to ten thousand will be a different one, right? So one of the things that you have to have, and everybody who wants to be an entrepreneur who wants to run a business has to have, is you have to have a drive to be able to stay through the hard things. You have to be willing to keep going when things don't work out the way you expect them to. Um otherwise, it's really hard to build a long-term business, unless you also do have to get lucky too, right? Like there's a huge component of being in the right place at the right time, and that can't be understated. So all these things have to come together. Your own drive combined with being in the right place at the right time, which is essentially what luck is, really. Um, and then on top of that, you also do still have to get out there and sell, right? Like it's gonna be this, it's like you said, you're your your first customers are people that you're you might have to go out and get at events or whatever, and you have to convince them that what you're doing is gonna bring them enough value to stop doing whatever it is they're doing now, right? To make a change. And that's not an easy thing to do, especially if your software requires setup, if it requires an investment of time or money. These types of things make it really difficult. And one of the fortunate things about DN Simple is in the early days, you could play with it and get value out of it without having to change everything else that you were doing. So, because most people have more than one domain name and they want to then maybe get another domain name and play with it. So they could do that at a very low cost. Um, the only difference is I never had a free tier. I I personally was because I had run the startup that I talked about earlier, we had done a free model for a long time, and I made the conscious decision that anybody who's gonna use the end simple was going to pay. Now I might discount it heavily for certain people, I might give them credit so they could try it out for an extended period of time, but everybody was gonna commit to put their credit card in in order to pay. And that's still something we do today. We've never dropped that. You know, 15 years later, you can't start using the end simple unless you at least commit to putting your card in there.
SPEAKER_01:That's the that's my exact plan for my product. Um currently, there's no it's it's physically impossible to give me money through the system, but when that exists, that's my plan for how to do it. Um because like, oh, what is my rationale for that? Well, what's your rationale for that?
SPEAKER_00:Well, my rationale was that I'm running a business, I'm investing my time, there's infrastructure that needs to be in place to run this. If I'm bringing somebody value, then they and they see that value, they will commit to putting their card on file. Full stop. And anything else, any free product, you don't know if you're actually bringing value to your customers because the the investment that you had that they have is their time. And granted, time is very valuable, especially nowadays. But there's a difference between it's the weekend, so I have an hour or so I can dork around with it. Do I'm willing to put my card in and potentially pay a few dollars? Like that gap, that leap for someone to make is a big leap. And if you're not getting them to if you don't know early on that they're making that leap, then you don't actually know if you have the potential for a successful business.
SPEAKER_01:Yeah. Yeah, I think a big part of my rationale is like I don't want to waste my very limited time and energy early or later on false positives. Like if somebody signs up as a free user and starts using it and I like get all excited because like maybe I have a customer, that's only like maybe I have a customer. Um, whereas if you gate it with requiring a credit card from up front, then it's like not a maybe. It's like you have that person's credit card info. They can obviously cancel anytime or whatever. Um, but they've they've already gone over that much higher threshold, and so their presence is much more meaningful.
SPEAKER_00:It's also going to greatly limit the amount of people you get in the front door in the first place. That's why folks argue for the freemium model as being so valuable, is because you can get more people in the front door to learn from them, especially early in the project. So I get that. Like I'm not knocking that as one of the ways to do it, but there's there is a those people that you get in the front door, the vast majority of them will do nothing with your product. They will walk in the front door and then they will never come back again, right?
SPEAKER_01:Yeah, that rings true to me. Um, and and I think that's another thing that speaks to the value of like getting your first customers manually, as I put it. Um, like it takes not only does it take a lot to get somebody to like switch from what they're doing now to doing a new thing, but when an endeavor is brand new, it's an even bigger risk because it's like, okay, I'm gonna switch for the from this thing I've been using for a long time that's working okay to this new unproven thing that might not even be around in three months. Like, that's a lot to ask of a person. And if you have a personal relationship with the person, then that greases the chute a lot, so that they're gonna be a lot more likely to um it's kind of doing you a favor, so they're gonna be a lot more likely to do you that favor.
SPEAKER_00:Yeah, it's it's you're it there you have a different kind of capital that you're spending, and that's a relationship capital. You know, you're you are spending a little bit of that to get somebody to come in in those early days who knows you, um, because they they're you're asking them to do something which is trust you, which is a big unknown. And so they trust you because it's social capital that you have with them already. Um, so but it you can only spend so much of it and burn through so many relationships, which also puts a lot of pressure on that you as a developer or the person starting this. You feel like an extra burden of responsibility. You're just like, oh my gosh, like the you know, my friend John, he signed up six months ago and I still haven't done these things I told him I was gonna do. I'm such a bad person, right? So it's like this extra layer of stress, um, which may or not may or may not suit what you want out of your business. It depends on you, depends on each person, right? What they want.
SPEAKER_01:Yeah, but another thing I was gonna say is there's definitely a direct correlation between like how nasty and unpleasant and like life-consuming the business idea is and how um how valuable it is. Because like, you know, DNS hosting can't ever go down, has to always be up. Like that sounds like kind of a nightmare, but like that's because it's like actually a truly valuable thing. Whereas some something where if it doesn't matter if it goes down for three hours in the middle of a weekday, people can live without that, so it's probably not that valuable.
SPEAKER_00:Or or it definitely was one of the factors in in their their consideration of the value of that service. So maybe they won't compensate you as well because they don't see the value there. Um and that may be okay if you're going to scale. I mean, like I know a lot of of products out there that they didn't care about being something that was going to be up all the time, yet they still did very well as a business because they still managed to bring value in some other way, right? And there's a whole bunch of products that they just think of video games. Like people don't need a video game to be up. But then you watch anybody who plays a video game. Yeah, they do actually. They need it to be up right now because right now is when they want to play it. So you you have this thing that seemingly is not a life critical thing, or it's not something that they have to have, but in fact, they're so emotionally tied to it and they have that need for it that it is actually something that they need. Uh, so I I find it to be fascinating when you look at all these businesses that you wouldn't expect to be something that where it's it somebody will consider that highly valuable and something critical to their life that becomes, in fact, it really is a piece of software or service that they need.
SPEAKER_01:Yeah. Well, nothing is rational, everything is emotional.
SPEAKER_00:It's it's true. There's emotional components to all of this that we can't understate.
SPEAKER_01:Yeah, yeah, because it's like, why do you buy a nice car instead of a crappy car? Like a crappy car will get you there just the same, but you buy a nice car for emotional reasons, and it's like just like everything. Um, anyway, it's probably about time for us to start wrapping up. Um, one quick question uh before we go, because you know, you and I have known each other for for a long time, like almost 60 minutes at this point. Um, so I figure we have a strong enough relationship now that like after this call, I was thinking you could like just abandon whatever CI that you're using for D simple and just entirely switch over to my product. Um, does that sound good? Uh while I wish I could say yes, that decision is out of my hands. Got it.
SPEAKER_00:Um we're gonna hear that response a lot, by the way. But it's actually a really important thing, it was worth a shot. It's actually a really important thing to remember as you're starting to grow and starting to deploy your business. You need to find your champion inside any business or organization that you want to sell into. And you want your champion to be clearly identified. You want it to be somebody that you build a relationship with, even if they're not going to write the check. Even if at the end of the day, in that particular environment, you don't close that deal, you need to connect with champions because they are the ones that are going to get you in with the gatekeepers and the buyers. And if you don't have the champions, then well, then let's just put it this way you pretty much have to have a much bigger marketing budget because you have to reach those buyers and those gatekeepers through a massive amount of marketing and sales. But if you have your champions and you know who they are and you treat them well, those champions will become the ones that take you into the businesses that they work at. They will be the ones who will be with you for the for a long time in your business. So look for your champions.
SPEAKER_01:That's an interesting and I think better perspective than the one I've been familiar with, which is like that sales advice of get in front of the decision maker, um, which obviously is like good advice, but also it seems a little bit uh lacking in nuance of how reality is, because like you can't it's it's not always realistic to get in front of the decision maker. So many times I've had instead a champion who is like, okay, like I'm the one who wants to do this, like I'm the one who cares about this thing. The the actual purse string holder doesn't really care about the thing, they are the official decision maker, but it's not their thing. Um, the champion has to go and they have to be be the one to make the case to the to the purse string holder. Um and you're never gonna like directly talk to that person in a lot of cases. So I think that makes a lot of sense.
SPEAKER_00:Yeah. You will eventually have to get in front of the buyer. So that's the one that's writing the check. And you will have to go through gatekeepers. Those are the ones that are gonna block you from getting at the buyer because of their other relationships that already exist with other vendors or what have you. They have all different kinds of reasons. But the way that you get there, especially in this day and age where there's so much noise, is not trying to like kick down the front door and go straight to that group. You first have to service those champions and make sure that they're getting what they need, even if it's not in the context of the business they work for. I can't tell you how many people use DN Simple who still have never taken it to their Fortune 500 enterprise company. And I'm okay with that. I'd love it if eventually they do. But my first goal is to make sure that we continue trying to do well for them and still have a successful business. And so we make some decisions just to try to make sure that our champions continue what they need, even though it may not be the thing that gets us into an enterprise contract or what have you.
SPEAKER_01:Um the last thing I want to ask you before we go is is there anywhere you want to send listeners to learn more about you and Dean Simple and anything else?
SPEAKER_00:Well, I'm in I'm on LinkedIn, so they can come find me on LinkedIn. If they just search for Anthony Eden, I'll be there. Um they can email me directly if they want. I'm Anthony at Dean Simple.com. Although I just ask, don't try to pitch me or sell me on anything because I have a very strict policy of how what I do with unsolicited sales messages, and usually it results in getting click the spam. So if you want to talk to me about something, if you're interested about what we talked about today or some of the other topics that I've posted about or talk about, by all means reach out. Totally cool with that. Um, I want to help more people do well. I want to have them see them do whatever it is that makes them happy, whether it's a successful business, a long career in engineering, anything else. But if you come and you open with, hey, I have this service, buy it, um, you're gonna go straight to spam. But otherwise, yeah, reach out to me that way. And of course, dnsimple.com is where you can find out everything about DNSimple and what we do.
SPEAKER_01:Well, Anthony, thanks so much for coming on the show. Thanks, Jason. Thank you for having me.