Smash Notes

IndieRails · Notes

Full Transcript for Anthony Eden - Making Business Look Simple

People

Get the key moments without reading the whole transcript

  1. How Did a Few Months Building a Knowledge Base Pull Dnsimple Back to Staying Focused?1:02:12

Episode page

Full transcript

Speaker 1

And so you start to train yourself to think about what is the impact of these changes that I'm making on other people. Where is the value, like it might, it's, it's what I'm spending my time is money, time is super, it's always, in fact, it's more important than money because we have a very finite amount of it. Is this time I'm spending good for me and everybody else who's using this thing? It created, it's a very good in terms of the lessons that you can learn and the consequences generally are nobody traded money for it.

So you can also go, I hate this, I'm walking away from it and somebody else can decide to take it up or not. Hey

Speaker 2

everybody, I'm Jeremy.

Speaker 3

And I'm Jess.

Speaker 2

And we're two developers, business owners, and friends exploring the world of independent business and rails.

Speaker 3

Welcome to Indie Rails. Hello, everyone, and welcome to another episode of IndieRails. Today, we're excited to be talking to Anthony Eden, founder and CEO of DNSimple. For those who haven't come across it yet, DNSimple is a service that makes managing domains in DNS simple and developer-friendly. I first met Anthony years back at Less Conference in Atlanta, around the time that DNSimple was just getting off the ground, I believe.

We also got to reconnect recently at XO Ruby here in Atlanta, where DNSimple was one of their sponsors. There's a lot of fun topics to cover today, so let's get started. Welcome to the show, Anthony.

Speaker 1

Hi, thanks for having me on. I appreciate it.

Speaker 3

Recently, we were just at XO Ruby, and I noticed that you guys are going to be in New Orleans as well. Why do you sponsor so many conferences?

Speaker 1

So, so yeah, we're actually sponsoring the entire cycle, so we, we will be sponsoring all six of the events, and assuming it continues to be as successful as it has been so far, I really hope that we'll see more of these. Our philosophy has, has always been we want to support developers. Dinsimple was built for developers, by developers, like that was the origin, right? It was really there because it was scratching my itch and my itch from a developer perspective.

And it's kind of gone with us throughout our life that, that we know a great place to meet and talk with other developers, learn about the problems they're facing, the challenges they face, are at live events. And I've known Jim for many, many years. I've been to a number of conferences that he's put on, and I knew that ExoRuby was going to be very good, both in terms of quality of speakers and uniqueness in the style of event.

And frankly, I wasn't disappointed. It was small enough to be personal. I met every single person there. But large enough to have speakers who actually had relevant topics to talk about, especially technology topics around Ruby, that you would see at a larger conference, a thousand-person conference. The speakers that were there could easily get up on stage at big events, and here they were spending their time on a Saturday event, one-day event, in front of a small audience.

And that kind of fits with the same belief that we have at DNSimple, which is support our customers one by one, try to make sure everybody's happy, and give them the level of service they would expect from somebody that has a thousand-person company.

Speaker 3

Yeah, I also had a good time at that conference. It was pretty cool. It was very diverse, too. I met several business owners, reconnected with you, met some, like, really quality developers and just people, met with some existing friends, so pretty nice setup.

Speaker 1

It was fantastic. And what I really loved about it was that typical of an event that Jim puts on, it wasn't just people getting up and talking, getting down, going back up and talking. We had Chance where we did a little exercise together. I don't want to spoil it for anybody who hasn't yet gone. If you're going to go to one, I don't want to, and maybe it'll be different.

But the, the, the personal nature of it and the fact that there was clearly a human A very good sense of the humanity of it was, was really helpful, even from the talks. I mean, there were, as typical fashion in a gym conference, there are some talks that are going to be about Ruby and some talks that have nothing to do with Ruby. And that's awesome.

Like, that's a good mix in my opinion. And, and he did it again, even for a single day conference.

Speaker 2

I was, especially blown away by my friend Thomas Cannon. He's a fellow Greenville, South Carolina, Rubyist, and we drove down together, and it was his first talk, and just blew me away.

Speaker 1

I can't, right? Yeah, the, the level of quality, both the quality of the preparation and his delivery were fantastic. I was inspired at the end of that talk.

Speaker 2

Same, yeah. I saw so many people nodding their heads along. He was talking about the, the challenges we have with sort of the future of Ruby, junior Ruby developers, and, what that means for our ecosystem, and just fantastic. Super passionate, had a lot of good data, and a lot of good action items as well. It was, it was so well done. So, hoping to see him more, but that was just like Yeah, just a highlight and a really great day.

Speaker 3

And so let's take a step back and Anthony, tell us like where'd you grow up in the world and then how did you get into DNS?

Speaker 1

My first introduction into the domain namespace was actually back in 1999, which was during the deregulation of the dot com. So this is back, there used to be one company, Network Solutions, which managed the entirety of the dot com namespace. And it was deregulated in 99 and I was coming, I was actually in France at the time. We were planning on coming back stateside and I was looking for work and I found somebody and he's like, okay, I, I have a task for you.

I need you to be able to accomplish the technical parts of becoming a domain registrar. I've already done all the administrative part. I need you to get this done, and we have seven days. I was like, cool, let's tackle this challenge.

Speaker 3

So you're supposed to create a domain registrar in seven days?

Speaker 1

Yeah, well, at least pass the technical accreditation test, because even back then they had, and so I had to learn the APIs. I was writing in Java at the time, and I was a little crazy, and here's why it's a bit crazy. I didn't just write some Java code that did it. I wrote a swing-based Java UI where I could run Jython code, which is a version of Python that runs in Java.

And in my head, I never said, well, I could just run Jython from the command line or Python for that matter. No, no, no, no. I need an interface where I had like the visual, I could run it, I could make changes, I had a text editor inside the interface. So, so this was my sort of introduction to the domain namespace, and we passed. We passed the accreditation.

We became one of the first seven registrars to be accredited to sell.com, and the next couple months were just crazy, like, it was just madness how quickly we grew, and then, of course, the next big event was the .com burst, the bubble burst, right? Did,

Speaker 3

did that product have to, handle, like, the orders and the registration, and, like, do the, the, I don't even know how you do it, but you create a domain name in the, in the internet.

Speaker 1

Yep. So essentially we had to, to, I had to build out a, a full web app. And, and so once, once we passed the accreditation, I built a, a, a JSP-based web app. I think actually at the time it may have been serverless because I'm not sure JSP had fully come out yet. And basically wrote it so that people could sign up, they could select it, like they could type in and search for a domain name, enter all the information they need to enter, enter their payment details and complete the transaction.

And it was just one flow like that. And it worked and we did very well, very quickly. So well in fact that there, and this shows you how green I was, we're, we're going along and things are cruising along and we're working out of this, it was a, art studio because the guy who did it was actually owned an art studio. That was his original business.

And we had a little server that was sitting over in one of the rooms with the artwork and we're like, do you smell smoke?

And the server was literally smoking. And I was like, oh my God, what is going on? And so I reached out to my brother who was, who was actually trained as a, as a computer science, like, engineer type. And I said, I don't know what's going on, but like the CPU's going nuts, it's crazy. He's like, he's like, okay, well, you have a database, right? I said, yeah, yeah, we have MySQL.

And he was like, do you have indexes? And I said, what's an index?

And that, that pretty much was it. I was like, oh, oh, oh, those are what those do.

Speaker 2

That's funny.

Speaker 1

So, definitely learned trial by fire, almost an actual fire in this case. And then we decided to move everything out to data centers. So I spent the next couple of years sort of Continuing to grow the business as the CTO, learning all about how to operate, you know, internet infrastructure, including going out and like racking units and everything.

And I, after I did that for a while, I said, I, I'm never going to rack units again. Gosh, I hope I never have to buy hardware again.

Speaker 2

Yeah.

Speaker 1

And fortunately, things have changed in the world so much that I don't really have to rack hardware, which is great. Yeah. So that was, that was the start of it. And then early on, I started working with the DNS protocol and, and I wrote, a DNS server. I wrote one in Java in the beginning, and then, I wrote another one later in life, in a different language.

So it was just something that I keep coming back to. I left for a while. I've done government contracting. I did, I worked for Yahoo for a short sprint. Done lots of different things, but I keep getting pulled back. And in 2010, I was just finishing up a different domain business, which was for the dot NP domain, so the Marianas Pacific Islands.

And at that point, 2010, we had already been, we'd used Rails for dot NP. I used it for another registrar or registry as well as a front end, and it was amazing. Like, we were accomplishing things that we couldn't accomplish with Java at the rate, it was just ridiculous.

Speaker 3

But could you run Python in it?

Speaker 1

I could have, and well, funny story, I'm pretty sure at one point we were running Grails inside of it as well. Okay, okay, that's funny. There's this, yeah, and I think I ran JRuby in it for a while as well, like trying to, it's a, I don't know, there's this silliness of like, let's make languages play together that keeps coming up over and over again.

Yeah, that's interesting. But suffice to say that 2010, I was coming off of that, I had already been working now for 17 years, and I was like, I think I know enough, and I think one, at one point I was using GoDaddy. Cause at the time, like they were, they were pretty much it, right? And I, and I was so frustrated with the experience of constantly being sold different things along just trying to set up a domain.

And then I went to their DNS interface and I was like, this is terrible. I'm going to do something different. So that was the origin. Started it April 2010. and then three months later in July at the first, at a RubyConf, we launched it.

Speaker 2

That's wild. It seems like there's a, you have this history of a sudden spark of something and then a rush to like get something built maybe. I, maybe I'm pattern matching too much, but it seems like that initial like, hey, can you do this in seven days? Yeah, I can do that. And then you pull it off.

Speaker 1

Well, funny enough, yes, the, the story that got me into .mp was the same type of situation, which is I got an email. Actually, I think I got a phone call even on, I can't remember if it was an email or phone call. I think it might have been email. Anyway, on New Year's Day, and it was from somebody out in Hawaii, and he's, he's like writing the story.

He's like, I have an app, a job application that somebody built for me, and this was, I think, 2004 it would have been, so January 2004. And, and he said, I have this job application, and the person that built it for me Encrypted all of the code and then took the key and now he's trying to extort me for money. He's like, can you take a look at it and see if you can reverse engineer it and maybe get through so I can get the code back? And I said, well, you know, most likely you're not going to be able to because if it's, if it's encrypted like that, it's pretty much lost.

And I said, give me a couple weeks, and let me take a look at it. And so I looked at it and I said, this doesn't do that much. So two weeks later I went back to him, I said, I couldn't deal with the, I couldn't break into it. So I just rewrote it for you.

Speaker 2

And he's like,

Speaker 1

holy crap, you're hired, come out to Hawaii. And that was the start of working on dot MP for the next few years was just because I was, I was able to do that quickly. And yeah, that's a common theme. It's like I get inspired to do something and then just go hack it out. And often it doesn't work at all, but sometimes it works really well.

Speaker 2

I would guess that also means that early in your career, you had an eye for unique opportunities that maybe other people... Like, I'm thinking, if someone came to me and said, "Hey, I've got this really big problem that needs to be solved in seven days," I'd be like, "I'm sorry." Like, you're gonna have to find somebody else. I'm not gonna, like, kill...

Speaker 3

It's gonna take you seven days to get on the calendar. Yeah, I'm just not...

Speaker 2

I'm not gonna kill myself to, like, try to... Like, who knows if this is gonna pan out or not, if I can actually accomplish it. But it sounds like... You either got really lucky with these things, or my guess is you probably have an eye for unique opportunities that are coming your way. do you, do you think that's true? And, do you have any, if so, do you have any advice or ideas of like what, how that, what other people can look for in those circumstances?

Speaker 1

So I think it's a combination of all those things. It's a bit of naivety, you know, the, the, the willingness to just go, I don't, I don't care, I'm just going to try to do a thing. It's also luck. It is very much the, luck and privilege have a ton to do with where I am today. And then hard work, like not being able to say, I'm just going to go heads down and do something.

I think that came from a lot of contribution to open source software. So for many years, even while I was working and doing whatever, I'd co, I'd have multiple open source projects on the side that I'd be writing and publishing and contributing to. and I think that, that sort of got the, this, this idea for me at least was build something.

It is always Maybe better to build something, even if it's a hot mess, it's a disaster, it doesn't work at all, build something because you're learning along the way and you're seeing what really sticks and what doesn't. And I would say for anybody else out there, if you have the skills to build things, then you should try to build them. And, and now, like I'm gonna, I'm gonna, I'm gonna blow a few people's mind because I've been pretty negative against generative AI.

Although I, I acknowledge that like this is part of our life now, this is going to be something we're going to be seeing going forward. I think in terms of builders, it's actually going to be even more impactful than we even understand yet because it's going to make a lot more people builders than who ever could be before. And I think that's a good thing.

And I think it's good to get, to try those things. It's also good to accept when you hit your limits and then find people who can do it better and take what you've done and take it to production. Assuming you're not building just for yourself. There's a theory right now that says a lot of what people are going to be building over the next Well, from here on out are going to be applications that are for one or two people.

They'll just like throw something together with generative AI, they'll run it, it'll do the job, and then they move on to the next thing. I've heard it called like disposable software. And maybe that's the direction things are going to be heading from the creators, and a few of those creators are going to make something and go, it's not just useful for me, but look at all my other people over here that had the same problem, and I wonder if this problem's bigger.

And it's, it's the same thing that we see over and over again in the world of, of business is that you start by solving something small, and, and it's, it, if it's really, really valuable to a bunch of people and you follow it through, it'll grow. It'll naturally take that. And if it's not, that's okay.

Speaker 2

It's like a Cambrian explosion, and you end up with a lot of, inefficiency and like genetic variation that turns out not to be useful and gets like, you know, killed off or whatever. But in the end, you end up with a lot of diversity and more Ecosystem health, like something larger, something bigger than, than you had previously.

Speaker 3

So Anthony, when you decided to start your company, it, it seems like there were these just big giants in the industry. You mentioned GoDaddy, Network Solutions, and I'm assuming like the average purchase cost of a customer is, I don't know, under fifty bucks, right? How, did you look at the economics and say like, how can I compete with these guys? And like, how long is it going to take me to build up enough revenue to be meaningful?

Speaker 1

Like I didn't, at the point in time, I didn't really care that much. My goal was, how can I build something where I can, one, I'm in control. So when I was, I control my own destiny, I can make choices that fit with my ethical and moral direction. Like this is a big part of it. At the same time, I had a very specific goal of being able to live the life that I wanted to live.

My, my wife and I knew that we wanted to continue traveling because, she's French. And I'm American, and, and our, a good portion of our life we've moved around to different places for the, the joy of moving around, and so we wanted to be able to keep that and, and run the business. The business was designed more to satisfy our needs rather than to just solve a problem.

Now it just so happens that at that point in time, we were at a transition phase. So if you think back to 2010, at least in our space, and I, some people out there may know the history, but we were about to transition away from these companies that had been doing this for twenty years, the Network Solutions, Register.com, those folks, over to the next generation, which would be Amazon, Microsoft, CloudFlare, that were taking, like they're basically scaling up, and they're not, domains was just one little bit of it, right? And, and GoDaddy is still a massive player in the domain space, but Google quickly became a big player in the domain space until they sold it off.

The, you know, Squarespace is a big player, has been even before they bought Google's domains, right? So, so the point is, is that we were at a transition phase in 2010. And the angle I took was niched down because I was listening to people like Rob Walling who were talking and it was like, my niche was going to be for developers because that's who I know.

I can build stuff for them, so that means I'm going to be building an interface that is bare bones, just enough to get it done. It's going to be at least not hideous, but it's definitely going to not be in your way. And then an API. And I knew right away from the beginning I wanted an API. And of course at the time everyone's like, REST APIs.

And I was like, cool, REST APIs. I'm going to do REST APIs. And it worked out. You know, it was a good cross, like it was a good time to start and that's where the luck part comes in, right? I got lucky to be there at a transition period when we, when the industry was moving from one set of, of companies to another set.

Speaker 2

Was it just luck or did you see that happening and thought, okay, now's the time to jump?

Speaker 1

It was mostly luck. I'm, I'm going to be quite honest. I didn't see, what I felt it, because I was using those, and that's part of it. Like, if you feel that something is wrong, if you're, if you're a builder and you're using tools and you're like, God, I, I can't find something that doesn't suck. Guess what? You probably have stumbled onto a, a place where there's a, a, a room for improvement.

Speaker 3

I think the first time I saw the Nsimple, I was at Atlanta Ruby meetup and somebody was, presenting and they like pulled the interface up on the screen and they were like tweaking the settings of something and I was like, whoa, what is that? And it was just, it just looked so nice and like, and then all, when I started talking to people, all my friends were using it, like all my developer friends.

And so that, that's pretty cool how you were able to just infiltrate that niche.

Speaker 1

Well, I, it helped that, so the Ruby community and I had a already a strong Thought, like sort of interaction with the Ruby community. I'd spoken at events. I'd written lots of open source software in the Ruby world. I'd contributed to various things in the Ruby world as well. And so it, it was a nice, it was a, it was a great environment for both of us, myself and the Ruby community to have benefits from this.

and those types of symbiotic relationships actually are really helpful for encouraging things to happen, good things to happen. And it's also part of the reason why fifteen years later, I still, I don't write Ruby code much anymore unless I'm playing around for something outside of work. I don't write code at work. that's an intentional decision.

but I love going to Ruby events still. And I, cause I, I understand what's going on and it still excites me. And every time I come out of a Ruby event, I'm like, I'm like, man, now I remember why I love the Ruby community so much, right? It's great. Fantastic.

Speaker 2

I had to listen to another podcast where you were talking about how, you know, you'd, you'd built maybe an audience or however you want to say it, you know, you'd earned the attention of Rubius, through a lot of the things you did. And I know a lot of people who want to build products or businesses see that too. Like, okay, I need to, you know, build an audience.

I need to gain attention from other people. Cause how else, you know, will I be able to sell something if no one knows who I am? And I'm curious if, if you noticed like that there was a point where, hey, if I, if I did release a product or a service, people would pay attention. People would know, like people would, was there a place where you kind of hit a threshold where it was sort of obvious to you that that would be the case? And maybe prior to which you'd be like, well, maybe not yet.

Speaker 1

Yeah, I think when I was presenting open source work that I was working on and like fleshed out projects, so these are projects that other people, and, and people were coming and say, yeah, we're using this in production. I think that kind of made me realize, okay, I can productize some of this stuff. And in fact, the first attempt I, I was doing was to try to productize some of the things that I had open source stuff for.

didn't really work out well. I wasn't ready to do the business side of it, but I think that was kind of the impetus for pushing me and made me feel more comfortable with the notion of, okay, I can actually build a product. And then that collided with the, the sort of the growth of SaaS and the acceptance that web applications were going to be a good way to deliver products for the foreseeable future.

So again, Being in the right place at the right time and getting lucky, and this was part of it as well. But yeah, I think there was, there was definitely, seeing the open source stuff being used makes a huge difference. And I see that now. The folks that I see up there talking at, at, at RailsConf or at RailsWorld or at smaller movies event, almost all of them who are talking like deep technical talks also are building open source stuff around those deep technical or contributing to it, those deep technical concepts.

And most of them I see have, if, if they choose to do so, they could take that to a business. But not everybody wants to build a business, and I totally accept that. Used to be I thought everybody wanted to build a business, and then I met a bunch of people that didn't. I was like, that's okay. You don't want to build a business.

Speaker 2

This, this is helpful because I think what I've heard a lot is like, how do I, you know, how do I, Monetize open source. You know, there's all these like, you know, what are the models for monetizing? And what you're telling us is like open source was a big factor for you like in, in your success with Dan Simple, but it wasn't ultimately, it wasn't an open source product, you know, in the end.

But it was still like a major contributor to what you were doing that kind of got you to, to Dan Simple as a, as a product. And maybe without it...

Speaker 1

In a lot of ways it makes sense, right? Because open, if you, if you build something that's open source and it, it goes ever past one person using it, you then have to think about all the things that happen when having a customer. Because the second person who uses it is essentially a customer, right? And so you start to train yourself to think about what is the impact of these changes that I'm going to make on other people.

Where is the value, like in my, is, is when I'm spending my time, because time is money, time is super, it's all, in fact, it's more important than money because we have a very finite amount of it. Is this time I'm spending good for me and everybody else who's using this thing? It creates, it's a very good in terms of the lessons that you can learn, and the consequences generally are, because nobody traded money for it.

So you can also go, I hate this, I'm walking away from it, and somebody else can decide to take it up or not.

Speaker 2

Yeah, I guess I hadn't really thought about that. I, I have not done much open source. I actually just released my first Ruby gem this summer and most of what I've always wanted to do is build products and monetizing has been something more recently, but mainly just to be able to continue to build products. But I really like this idea and I wonder if I, if I was going back now, maybe I would, spend more time trying to build open source.

Even, even thinking about the Ruby events site, you know, it's like an open source. It is a product, you know, but it's open source as well. And because you have this chance to impact lots of other people and hit all those other parts of the product management role because you're having to think about customers and changes and what's important and all that kind of stuff, which is exercising all those skills that you really need.

that's cool.

Speaker 3

Anthony, tell us about what are your core product offerings these days?

Speaker 1

So we still remain focused even today on intellectual property domain. So the domain name side is about intellectual property. It's like being able to buy, transfer, And renew domain names. So that's still a big portion of what we do. The other major component is the operational side. That's the, the authoritative DNS, the stuff that we have to do 24-7, 365 would protect from attacks and things like that.

We have a few ancillary things, like for example, we have integrations for doing SSL certificates because they kind of weave in well with domain names. Whenever you have a domain, you probably need a certificate. And the path we've chosen is really to fully embrace Let's Encrypt and make it part of something that is included inside of every Dan Simple account at different levels.

Like you, it's, it's, it's tiered based on the features and functionality. Because we figure our solo plan, which is really for an individual developer, the odds on them needing wildcard certificates for themselves are pretty slim, right? So we, we wall that off into a higher tier. And the odds that they're going to need multi-domain certificates are pretty slim, right? These, these are all things that you need once you get into more, I'm building a business, I'm building a product.

And then we also do little things like email forwarding and then all And that, and again, it's just there to support what we expect people to do with domain names. And the core, though, remains domains and DNS. That's what we, we want to help people connect those domains to the services they use. That's kind of the fundamental thing that we do.

Speaker 3

Oh, I got one cool story is, I, I remember, DNSimple was one of the only companies I knew that could route a root domain to like a Heroku, where you needed to, a C name. And, I always thought that was pretty, pretty cool.

Speaker 1

That was, that feature came from the DNSimple customer base. So we had somebody that we knew that, I think, if I recall correctly, I think he was actually at Heroku. And he was like, this, he's like, this is such a pain. Can't you guys do something to fix this? I said, I, well, explain it to me. He's like, well, we want to run a website on the root, but we want to be able to give those people a domain name, like a name, a host name that they can point at, not IP addresses, because we want to be able to swap those IP addresses regularly.

And we're like, okay, let's see if we can solve it. So we started working to solve it and went through some iterations and just slowly improved it. And at the time, yeah, we were one of the few. Now it's kind of par for the course and so much so that there's even an RFC specifically for how to deal with this. Far more complex than anything that we ever came up with, but there's, there's a, an RFC that talks about a specific DNS record that's designed to handle this particular case that's, that's growing in adoption.

Speaker 3

But yeah, it, it was such a, a weird thing to have to explain to a customer that already had their domain somewhere else. And I like, I built them this nice Heroku web app and they were like, well, we, we just want to, we don't want to type the www. And I was like, well, we're going to have to do something because you can't just map it directly to Heroku.

I hated having to, having to explain that.

Speaker 1

It was, it's such a, it's, it's always, the devil's always in the details, right? Like that's one of the things that I've seen time in, time in, time out. Here at the Unsimple is that the things that we do well are fixing those little edge cases that are really hard to deal with unless you solve that one problem. And it's hard for a bigger company to do that, but a small company like us, we could just pick one of those and go, yeah, we can, we can do that.

We can try that. And a lot of the features that we got over the years were, yeah, we can try that.

Speaker 2

When you're figuring out something like that, like, oh, can we build, can we build this? How are you doing? Are you doing like some kind of like lab, internal lab that you're Is that how you, like, do this kind of stuff, or I can't even imagine?

Speaker 1

I, I wish I, I wish I could say we do it the same every time.

But I can say this. So, so what we generally do now, at least, is that we adopted ShapeUp a couple years back, which came out of the folks at Basecamp. everybody here has probably heard about it. If you're using Rails, you've probably heard about it. And specifically, we use the extended idea of framing problems. So Ryan Singer talks about framing problems as a precursor to shaping a solution.

And we grabbed that and we ran with it. So what we do now is anytime we see something Like have this idea that something doesn't quite work the way we want it to, whether it's internally, externally, whatever we want to do, the first thing we say is, okay, I'm going to write a frame for it. And the frame basically describes the problem in writing.

It describes who the, like who cares about it and what do they care about. And it, and it describes a future world where it works properly. And we spend time iterating just on the frame. So like, do we understand this problem? Then we go into the shaping part and, and even framing, shaping, we might do things like you were talking about, we might, do a spike that's going to be thrown away.

So we might spike something just to see if it's even feasible. we might write a prototype for something, just to understand what the different interactions are. And then ultimately we agree and we bet to build something, and then we go ahead and build it. And we do have mechanisms inside of the Insymbol for controlling who sees what, so that we can, cause obviously one of the, the tenants is to get stuff out there as quickly as possible with ShapeUp, like Shipping is the goal.

And so what we do is we have feature flags. We have what we call canaries. So when we talk about DNS traffic, some of our DNS servers are, are declared as canaries, which means we can deploy stuff to them first with the full understanding that if it doesn't work the way we want it to, after getting large amounts of traffic into it, we can pull down those canaries, we can revert them back without having to impact the entirety of our production systems.

So over the years, we've built up these mechanisms that allow us to progressively test the things that we want to put into production and make sure that they're not gonna, gonna do something that unexpected when they hit high volumes of traffic or unusual types of traffic, which we see a lot of in the world of DNS. And, and it's worked out pretty well.

Speaker 2

Did you have to build a lot of your own tooling around like domain servers, the, the name servers like running in production? I, I heard you in another podcast had talked about like the latency with your, the furthest, name server in like Australia or whatever. And trying to like make that as, as low as possible. I mean, I was just imagining you must have ways of, that you had to build like measurement into that.

Or was, or would you, were there stock tools out there?

Speaker 1

So there were not, so we've tried things early with stock tools, but we found that, that when you deal with that larger type of distribution of systems, it, some of those things don't work as well as you would like them to or at the speed you would like them to, and, and can be a strategic advantage to be able to do something fast. So what we ended up doing, and we still run this design today, is we have, sort of our core application written in Rails with a Postgres database that backs it.

And when we want to deploy changes of a zone to our edges, that notification goes out through a little Go application that lives in, like we have those living at each of our edges, and then that fans out the notification to all of our name servers, which are written in Erlang. And then those name servers can reach back and say, give me the, the changes that I need if they're not in the payload.

They, we also started replicating a portion of our Postgres database to our edges, so that when we have, like, one of the bigger problems we found with the ones that the, the name servers in Australia was reload times. So it would be variable reload Times because it would connect to our core database to pull all the zone data, and so it could take almost an hour to reload an edge in Australia, whereas in Chicago it would take four minutes, and we're like, okay, well, that's, that's pretty bad.

Let's, and so what we worked on over time is, especially as Postgres got better and better at replicating portions of its data, is we now replicate our zone data to our edges so that at each edge they have a full copy of that, and they just go at the edge, and now we have basically everything works at the same time, like they, four minutes is what we expect a full reload of an edge to, to take.

Speaker 3

Man, I, I gotta say, I don't think you guys need to worry about a moat because nobody's just gonna wake up and say, I'm gonna start a DNS business. This sounds complicated.

Speaker 1

You'd be surprised how many people wake up and go, I'm gonna start a DNS business. Does that get you not? To run it at, at any sort of scale, you have to be willing to continue evolving over time. Because our initial infrastructure didn't look anything like this. We, the first one we rolled out was four Unicast servers running on VPSs. Like we were, I don't know if you remember some of these names, we were using Linode, we were using a small orange, like these really tiny companies doing VPSs, and it was terrible.

It, it could not scale at all. It was Unicast, so like if one went down, like all of a sudden everybody was impacted, it was hot mess. But we had to start somewhere. And so I think any sort of infrastructure company, you have to be ready to be in it for the long haul and to be willing to continuously evolve and do it in a way where realizing that your customers can't be impacted by these changes ideally, right? You want to be able to continue evolving it without bringing things down as a whole.

And that's something you only learn after operating it for a while.

Speaker 2

Oh, that's interesting. Jeremy, I was just thinking of Zeke and, what's his last name? Gabriels? Yes. He, he has, I don't know if you know him, Anthony, but he has a business that is for licensing, and so they can deploy. And, he had that challenge of convincing people that he was going to be in it for the long term. Like, they weren't going to build this tool around his licensing software, and then, you know, two years later, he was going to be gone.

And he ended up opening, open sourcing, and what's his open source license called, Jeremy?

Speaker 3

It's called FairSource, so it's not quite open source, but yeah, FairSource. Did

Speaker 2

you run into that with, especially like with any larger customers or institutions being a smaller company?

Speaker 1

That's actually a really good question. I think early on there, we weren't considered by many companies. They would look at us and they would just walk away because they would say, okay, this company's not big enough, they're, they're too playful, they're not going to be, they're not going to be able to support our needs. So undoubtedly, we probably lost, significant large contracts that never even Open the door to talk to us.

We weren't even considered. The good news is, is that because the, the original audience for DNSimple were developers, like we satisfied their need and there's a lot of them out there.

Speaker 2

Oh, I was looking at your sponsors and I was like, all those people are like were developers using DNSimple before and now they own these big awesome companies.

Speaker 1

Yeah. That's,

Speaker 3

that's very cool. And in fact,

Speaker 1

we have a lot of customers who, who went on to build massive companies who are still with us today. because of the Ruby, again, this is the part that blows my mind. Because we focused on engineers and went out there and talked to them, they trusted us because they saw a person standing there and showing real code and doing real things and being a real person.

Speaker 3

Yeah, I mean, just looking at the logos on your homepage, like so many of those are Ruby and Rail shops. It's

Speaker 1

very cool. And so, so yeah, it's, it's, Over the years, I think as we've grown as a company, we have people started trusting us because we've been there through hard events, and we've always come out and said afterwards, like, that happened, we're okay, like, this is on us, here's what we're doing to fix it. And I think over the years, if you, it's rare that you find companies that are willing to accept that they made mistakes and then tell you how they're going to make it better.

But in the world of infrastructure, you kind of expect that, like you need companies you can trust to be there, whether it's for licensing or for DNS.

Speaker 3

It's so true, and actually, like, this, this Zeke that, that we just mentioned, he, the, one of the things that got Him on my radar was he did a postmortem as a blog post. It was one of the best postmortems I'd ever read. And they're such terrible experiences, like when it's your fault or when, you know, like when it's on you in that way, but the forthrightness and the clarity and the, the, commitment to improvement comes across so well, I think, and, and speaks, speaks a lot, I think, to customers and, and to non-customers as like, that's a sign of someone like I'd want to, you know, I'd want to give my business to.

And, and it's interesting to think that that's not, that's not even a, a thing that once you decide to do it, it always stays that way. Cause there are companies, I'm thinking of one right now, where their postmortems these days just are terrible.

Or they're lacking, they don't have one, you know? And I'm just thinking like, come on, you know, like I'm losing trust every time you have an outage now. And,

That's not a static thing. It's a like, it must be an on.

Speaker 1

Oh yeah. Yeah. It has to be part of, in fact, so what we did is we institutionalized those processes at the end simple. And every single incident that we have, even if you all never see it, like these, these are things that happen internally, everyone and then gets a PIR, which is post incident review. Everyone follows, like we have a very, very set process because it's the only way we're going to get better is by recording what happened in a blameless post incident report and saying we will take action.

And we, it's never perfect. Like we've had times where we've done post incident reports that we haven't resolved in a way that has been satisfactory to us, but we've learned from that. And so we continue to evolve it and to get better and better. And no company, no person, no entity is ever going to be perfect, but we can always strive to get better and admitting that incidents happen, which apparently a lot of companies just really don't want to admit, is the first step.

To getting better as a company. Unfortunately, it has a stigma associated with it. It's like, well, if we admit to this, well, now we're going to get sued, right? And that's unfortunate because one, I don't think it happens as often as people would like to believe. Yeah, there are cases where big companies have made the news for being sued, but for every one of those, there's been tens of thousands of other ones that have had incidents that haven't been sued.

So it's not about lawsuits. Oftentimes it's about saving face. It's about feeling, oh, we don't want to look bad. No, we want to look perfect. Well, you're not perfect. Just accept that mistakes happen, learn from them, and, and then make yourself better.

Speaker 3

I think especially, maybe especially when your audience or your customers are developers, they also are in the same boat. We all, we've all, we've all had incidents. We've all caused outages, you know, like, so it's If you haven't shared those things, it's kind of like, well, I don't know if I believe you. You know, it's like, it's, it helps, helps me identify and trust.

Speaker 2

while, while we're on the topic, do you have any more stories of servers on fire that you want to share?

Speaker 1

so I've talked about this before, a while back, it's been a long time since it happened, but early on, we had, some pretty major denial of service attacks. And one particular denial of service attack started and didn't let up for, I think, at least 12 hours. And I stayed up that, it was, I was in France at the time, and I stayed up through the entire night, and my kids saw me, they saw me when they went to bed, and they saw me when they woke up, still in the same spot.

And that was really a, a moment where I questioned whether or not I'd be able to do this. Like, I, I don't know if I can do this. And it also coincided with a whole bunch of other bad stuff happening. So it's, you know, when, that's gonna happen. I think anytime you're doing something in life that's hard, you're gonna run across those moments that are gonna make you question whether you should even be doing this thing.

And I was fortunate enough that I spoke with a friend who referred me to somebody else who gives advice. And some of you might know the person from the community, his name's J.B. Rainsburger. he's a long time engineer, and so I spoke with him and he, he, he sat down, like we were talking on the phone cause he was in the US and I was in France, and he said, why are you doing this? I said, is this, is this business for you? Because he's like, he's like, what you're, what I'm hearing right now is not somebody, he's like, first of all, when bad stuff happens and you feel this way, don't do anything.

Don't ever make a decision when you're under duress. That was a great piece of advice, by the way. And so then after he said that, he's like, why are you doing this? This business is supposed to serve you and your family too. Like, I appreciate that you have customers that you want to serve them, but it's also here for you and your family.

So do the things you need to do to take care of your family. And this, at this point, we were driving around in a, in like this beat up car that would, if, if my, my wife came home one day, she's, it had been raining and she was just like, it's raining in the car. Like it's leaking into the car. And this was all happening while we were like, oh man, yeah.

And it was just, and he, and he, JB was like, just take some money out and go get a better car. Like do these, it's, it's just not, you're allowed to do this. This is your business. And that changed a lot of my perspective and made me realize that, that I and my team are part of this as well. I still feel like you obviously have to cater to your customers because your customers, like you're there in service of them for a business.

And, but the owners and the team who run the business also have to be factored into this and have to be a component of this and need to be taken care of. And if they're not, then you have to start to question like, are you doing things a way that is sustainable? So that was a, that was a pivotal moment. That was really, really hard, by the way.

That was super hard. That, that, those were dark times.

Speaker 2

I can't imagine that, just being a, a software developer and having a, a product that needs to be up most of the time, I can't imagine how, how you guys can handle that stress of needing to be up all the time.

Speaker 1

I mean, it's, I think the, when you're past those situations where it's, it's a stress, is it like distressful and where you, you're under duress, I think the, the next step is to go, okay, let's make some changes. Let's improve some things. And, and so we did, and that, and we slowly started making changes to the, to the business about how we operated, how our technical operations worked, what other types of partnerships we're willing to make to protect the, these types of things.

Like it was, and what investments we were willing to make to try to make this not happen. Again, it, we've had other incidents in the past. We've done a really good job, I think, of alleviating a lot of that, but there's always the risk, right? If somebody wants you down hard enough, like if they really want it, let's say like a government really wants to take you down, they will do that.

It's kind of hard. Anybody who thinks that they can survive that, just hasn't had a big enough enemy yet come after them. You

Speaker 2

have to be worried about governments.

Speaker 1

Well, we, we, we once got blocked by Kazakhstan. So this was hilarious. I got an email, a random email, another little story here. I got this random email that was like, This site is not something that we allow in Kazakhstan. You must take it down or we will block you. But it was really weird because it wasn't from an official government agency.

It wasn't from anything official. It was almost like it was from a, a Gmail address, right? Or something like that. And I was like, I was like, come on, don't eat this.

About a week later, I get a message from a customer. It was like, hey, we have customers in Kazakhstan who can't access our site anymore. And we're like, what? And, and in fact, yes, this had been a real thing and they had blocked us at, I guess they had sort of ingress into the country that was controlled through certain routing rules and they had blocked anything that was from us and thus blocking DNS resolution.

They'd done like a complete block. And I reached back out and couldn't get them to fix anything. Eventually, the customer that of ours that was the reason behind this left and went elsewhere. And nobody ever responded to it, never heard anything. Two years later, somebody was like, "Hey, we're back on in Kazakhstan." So it's like, what is going on here? That's so weird,

Speaker 3

huh?

Speaker 1

Super weird, super weird. So yeah, governments can come after you if you run a business that is like global and there's something they don't like.

Speaker 3

One thing I was thinking about, decision to build a business, but also even the lifestyle choices you made, like to live in lots of different places,

that's also not easy. You know, like if you stay in your hometown, that's kind of like the easiest thing you can do, like you kind of... Have your community, but when you have to move, when you're moving, you know, like move to US, move to France, move to Hawaii, that's kind of like doing things on hard mode in your life. So you're doing things on hard mode in your business, you know, building a business, building a product that's hard, then probably also, maybe not hard in the same way if your wife's French, maybe that helps some, but it's still like big transitions in your life too.

I, I'm guessing that you like to push yourself that way. but I'm wondering what you've learned about, about that, about the, doing things in multiple spheres of life that are hard and sometimes at the same time.

Speaker 1

Yeah, I, I, I get bored. That's what it comes down to. And I think being able to be, having the, the flexible mindset, being, and being willing to just Change things up is something that is, it, maybe there's some innate drive in there, but it's also a learned skill, right? You learn to become flexible. So for example, you learn to not care as much about possessions, because when you move from one country to another, it's a hard to take all of your possessions with you.

It's doable, it's just very expensive, right? So you learn to, to, to decide what really matters the most to you, and things just don't, they stop mattering. Things that, that can be replaced, things that help, you know, just like your house, furniture, cars, those types of things never really have meant much to me. But Being able to be with my kids and see them in some new place and learning another language and then developing into their own, having sort of that same drive to, like, to experience life and do things differently, that's the stuff that actually matter.

And so, yeah, it definitely, we definitely were playing on hard mode for a while. When we moved, the first move that we did, so my, we had triplets, the first group were triplets, and they were born in 2001, and we were in Miami at the time, and in 2000, I'm pretty sure it was 2004, we moved to Hawaii. So our triplets were like three years old when we decided to lift them up and move them to an island.

Speaker 3

That's not hard.

Speaker 1

No, right? And so we thought about, like, what were the things that we would need to bring for them, and we did that instead of really caring about the stuff that we were bringing for us.

and same as when we went to France, we would, we would like, okay, what do we really need? We would live, we live, we always lived comfortably because as a software engineer, the good thing is, is that it's in high demand. And I, I, I was Able to work as a software engineer, whether it was on Dan Simple or for other companies, and be paid well for it.

And so we lived well, but we didn't live like a king's lifestyle. We didn't have all the things that some people would say are important for living a good life.

Speaker 3

Sometimes rain was coming into the car.

Speaker 1

Yeah, sometimes rain came pouring into the car, right? Yeah,

Speaker 3

yeah.

Speaker 1

But the fact is we were always able to at least do the things that really mattered, which was have these experiences and live our life the way we wanted to, whether it was working for somebody else or working for our own business.

Speaker 3

Yeah, that makes sense. I'm just guessing here that sometimes, though, with the living on hard mode and being willing to do that yourself, maybe from a leadership perspective, meant like changing things so that not everyone wants life on hard mode. Not everyone can handle that. And then being like Having to adjust things so that they are easier for other people maybe, or who can't be quite as flexible or, or, or don't want to be.

And

Speaker 1

we never demand, yeah, we never demanded any of our people, our team members to live the way that we live. The beauty was, is that because we were living on hard mode, the company was designed to be completely distributed, completely asynchronous, a-as much as we possibly could. So all of the processes that we were building were supporting this, which means that we could hire somebody that Would wanted to stay in one place, but someplace really far away from where we were, and that was okay.

Yeah, and I think part of it is that when you build, when you structure an organization so that it, it has that flexibility for you as the founder, the rest of the team can benefit from that because you don't have any hard and fast rules that say, well, now you have to live where I live, or you have to come to an office, things like that.

So in that sense, we created an environment, and that environment also worked out well, I think, for our team members.

Speaker 3

It seems like there's a lot of resources out there nowadays for how to, how to do remote async, but back then when you were figuring this out, it seems like there's probably less. How, how were you... Yeah,

Speaker 1

there were definitely less.

Speaker 3

Who were you going to, like, were there any companies that you were looking at that were like, I'd like to do it like this, or other, you know, were, were you just kind of figuring it out, like, as you went?

Speaker 1

A little of both. I was listening to podcasts, so like the Tropical MBA podcast was a big one early on in the days because they were kind of living that. They were living over in Vietnam and doing these type of things, and so that was a, a inspirational thing to listen to. There were early companies that were talking about remote working, and so I can't remember ex- even GitHub when they first started were kind of talking about, hey, we're, we're building this company.

We have this amazing office, very cool, but you don't have to be at the office, right? And so their companies were experimenting and talking about hybrid work. and in fact, when I worked at LivingSocial, so I spent a little time working at LivingSocial, during the early days of Dinsemble, they accepted the fact that I would be working at home in France, even though the company was based out of DC, and it was challenging, but that was kind of the learning experience along the way.

Oh, okay, so these are the things that are going to work, these are the things that aren't going to work. So it was just kind of paying attention to what was going on. Listening to some of the podcasts and reading what some of the other companies were talking about in their blogs that, that made me say, okay, I'm going to, I'm going to keep going with this.

And then a willingness to say, we're going to build the company this way, which means we're going to write more than we're going to have in-person meetings, right? We're going to, we're going to make, we're going to document decisions rather than having them around the water cooler, things like that.

Speaker 3

Which is all stuff you probably had to, you, you experienced the, the worst of it being the one non, the one remote employee at LivingSocial or remote dev.

Speaker 1

Oh yeah, that was super hard. Yeah, so you got to

Speaker 3

experience all the downsides of that and then knew to like plan for that.

Speaker 2

Anthony, before we got started on the show, you promised me you were going to come back and talk about the term indie.

Speaker 1

Yes.

Speaker 2

Let's jump into that. I was a little hesitant to label D and Simple as indie, but you, you sort of shot back and said, no, we consider ourselves indie. What does that mean to you?

Speaker 1

So for me, Indy's independent, right? That's how I see it. And in the case of the ensemble, independence is in the form of we've never taken really outside money.

so we're, we're, we're a traditional bootstrap company. didn't take money from anybody to get where we were. I, I've sold off little bits of the company just to, to, to put some cash in my pocket, but that's about it. I'm still the majority, like my wife and I are the majority shareholder through a trust. We are independent in the financial sense.

From having others tell us how to run the business. And because of that, we can make decisions that logically other businesses can't make, because we're not driven by a pure profit motive, right? We can have other drivers. And so, for example, one of those drivers can be a continued lifestyle that allows us to balance work and our life well.

So that if we need to, if we or other team members need to take time off, we can do that comfortably. It could mean that, that continuing with the distributed nature. Like there, it would have been very easy to say, well, we're going to settle down in a location, therefore our team is going to settle down in that same location. But that just wasn't part of how we were going to run the business.

So independence comes in a lot of different forms, but for us, it was the financial independence of running the business, being a profitable business from early on. and that allowed us to make decisions independent from other factors that were outside factors that, that we didn't really care that much about. We're still small. Like that's the other part.

Indie doesn't mean one person. You can have Companies of, of any size, really. We're 25, I think, right now in total, and part of what's really cool about what we do is that we can, we can just like zig when everybody else zags. Like, I say that often. I say, everybody else is gonna, everybody else in our industry is doing this thing, we don't want to do that.

We're gonna do this other thing over here, and sometimes it works out, and sometimes it's a disaster, but it's okay, because we are the ones, we, the team, myself, my wife, the, the other, the other people that are in the management team, we get to make these decisions along with all the other team members, and if it doesn't work, we can go, well, let's stop doing that.

Let's do something different.

Speaker 3

The momentum, isn't as great. Yes. You can kind of switch gears faster than other companies could. There's trade-offs, right?

Speaker 1

Like, Dan Simple, the way we have the business right now, is probably never gonna be a billion-dollar company, and that's, that's, that's just a fact. Right? Like, I didn't design this company to be that. I don't even know if I'd want to run a company like that because you have to make so many trade-offs. But who knows? You never know. But this company is not designed to be that, and that's okay.

The momentum of this company is like, let's keep it steady and solid. Let's care what our customers want. Let's make sure we pay attention to them. And that's, that's how we're going to run this business. And if we, if we grow more in one year or less in one year, yeah, I mean, that's, that's just natural. We should always be trying. Like, this isn't an excuse to stop trying to do the best work that we can.

It's just an acknowledgement that we're not going to be like this high-paced startup that's going to go and have to, you know, oh, well, we need to raise our next round or we need to do that. That's not us.

Speaker 3

Were you focused mostly on the customer-facing product or operations or support? Like, where, where was the bulk of your time when you first got going?

Speaker 1

So when I first started, I was spending, I would basically write some code, and so I was doing it on Rails, right? And so I'd write some interfaces, maybe a little backend, just to make something work, right? And then I would launch it, I would push it out, and then I'd say, okay, what do I need to do, where do I need to post about this? I might write up a blog post, right? And then I'd go back and I'd write some more, so I'd spent a lot of time, when I say a lot, I mean I iterated on the product and messaged it out during each of those iterations.

That was the early days. My, I founded the company with my brother, and he was more focused on the technical operations side, so he was the one setting up servers, you know, deploying that, and then we had worked together to figure out how we're going to get these two things to talk to each other. And so I didn't have to think about the technical operations other than what message, where I need to put stuff or what messages I might need to send, where I might need to make an HP call or what have you.

And instead, I could just focus on iterating the product. One early decision I made was I'm going to charge for this from day one. And so, so one thing was before I even launched, I was like, I'm going to build a little simple payment collection. I think I used Chargeify at the time because they were out and, and, and that with AuthorizeNet in the backend.

And just, it was a This is the thing, I want to charge for it. And meanwhile, I would be out on social media and I'd be like, hey, what do you, like, what do you all think about this next? Like, I'm thinking about this as something, do you want this? Do you not want this? So for example, the first iteration was only the DNS components. It was like A records, CNAME records, MX, NS, all that, right? There was no domain registration part.

And I said, I said, so how do you all feel about your domain registrars? And I got a lot of feedback from my friends who were like, oh, it sucks, please solve that problem, right? And we'd already had some customers at this point who were subscribers. I was like, okay. And so then I try, went out and I figure out and I iterate on how do I register just.com names? And what else does that get me? Oh, okay, well I can do these things.

Okay, what about transfers? So I just was iterating, writing about the blog, iterating, writing about the blog, iterating. In the very early days, it was just that. It was a lot of the back and forth on the product.

Speaker 3

Were there any other key professional experiences early on that set you up? For the things that you need to know to run DNS simple, either in, in the space that you're in with,

DNS or, or just in terms of like leading a team and, and product and all that.

Speaker 1

I spent a lot of time, so my history was, a lot of my history was working in domain industry. I was there when, you know, things were deregulated. I worked on a registry, a registrar, and I kept getting pulled back into it. So undoubtedly from a technology standpoint, I was deeply in that area.

Speaker 3

That really gave you a specialty that other people would not have had.

Speaker 1

Correct. Yeah. And I, I used other people's DNS software. I wrote my own DNS software. I did that multiple times. Like, so, so I had a lot of experience there. From the business side, I think that the, the, I saw a lot of people run businesses both well and poorly. I saw people make good choices and bad choices. So, for example, there was a, at one point, I saw my CEO at a company decide not to pay a contractor.

And I was like, well, I'm not going to be that person. So I'm, I'm not going to build a company where I have to make that choice, hopefully. If I'm going to be able to pay a contractor, it's because I'm going to have the cash in the bank that I'm not earmarking for something else to pay that contractor. So one of the things that happened, and still happens to this day, is Dinsible runs with a pretty positive bank account.

Like, we don't, we don't sit there and leverage ourselves and overspend. We spend at a rate that is appropriate for our business. But that was because that one time where a contractor wasn't paid, and I said, that just doesn't sit well with me, because I knew the contractor, and he had done his work. He deserved to get paid. I'm not going to be the guy that doesn't pay somebody that does their work.

So that, that would be to me an example of a lesson that where ethics aligns with business decisions.

Speaker 3

Yeah, and, and you formed those principles. It sounds like when you were close in proximity to someone in a leadership position.

Speaker 1

Correct, yeah. As, as a CTO or as a, I've always been curious as well, so I, I don't, and I also, I don't have a lot of, I, I have more filters now than I used to have, but I don't have a lot of filters. I will, I will go up and talk to a CEO and, and like there's no Starstruck or any, I just have a conversation. And so I would be willing to do that throughout my career, whether I was at a big company or a small company.

I would talk to leaders and just, and actually there was, so this is, this, there was an important part also in my career away from the domain industry where I was working for a company that contracted for the Department of Defense. And I was working with, people that were ex-military or military, and I saw a very different approach to,

to work than I had seen when I was working just with other people, right? Where it was like the people who were military and ex-military were like, I'm going to get this job done and then whatever it takes. Like there was this, this drive and this, this, they, they just would not Stop until the thing they had to do got done. And I thought, yeah, like I really appreciate what, I, I appreciate that attitude and I want to kind of take that attitude with me, which is this kind of like, I'm not going to give up when stuff gets hard.

I'm just going to keep trying to go with it and be a bit stubborn almost about it. And, and really it was, that was also foundational in kind of how I wanted to run businesses. I didn't want to just like, whatever, you know, whoever gets hurt along the way, I don't really care. No, no, no, no. I, I want to take care of my people and accomplish goals.

Speaker 2

I do have one more question. I've been wanting to ask, earlier I asked you about your core product offerings and, I can imagine, I think a lot of people struggle with this, that the temptation might have been to keep adding additional products to this. I mean, a website builder, email, or this, or this, or this. Is that something that you had to tell yourself, no, because I want this extreme focus, or were you just like, I don't care about that stuff? Or did you have to stay disciplined? What was your reasoning behind it?

Speaker 1

So it was a conscious decision. We said we're going to do these things and we're going to do them well. And so that was part of it. And then we strayed away from that. At one point we, my CTO and I, we were like, wow, knowledge bases suck. We're going to build a knowledge base. So we went off and spent like a few months building a knowledge base.

And that really quickly taught us like, oh, wait a minute, this is a distraction. Like making this other business seem like a good idea, but in fact, no, it was a very bad idea because it's a complete distraction. So that quickly pulled me back into this, oh yeah, there's a reason why we stay focused. Now, we will release new products. so for example, something we worked on a cou- like last year and the year before was our domain control plane concept, which is essentially this concept where you can connect to other DNS providers and other domain providers and see it all from within DNSimple.

So we connect to Amazon, we connect over to, to Azure, we even connect to like CoreDNS for on-prem stuff. So that's another, it's like doing a connection like that is a different product, but it's still orthogonal to what we do, right? It's still, you can see the, the time. So everything we do, we try to keep logically at the, the one fundamental belief, which is we want to help people connect domains to the services they use.

If we are doing that in some way, then we're on the right path. But a knowledge base was not that. So, so we killed that project.

Speaker 3

What do you, what do you think was, the temptation there? I, I can imagine, like, I would want to, yeah, boredom, yeah.

Speaker 1

That was it. It was like, we were tempted because, like, we see something that's not great. We're bored a little because, you know, because we have to run a steady, stable business. Oh, let's, you know, feed the creative juices by trying this other thing.

Speaker 3

But how, how do you, like, you still have to answer the boredom somehow. So what do you do? Like, do you do that in your personal life? Do you do that in some, like, that's what I would think about doing is trying to move back to France.

Speaker 1

No, that definitely was part of it. I think you find other things to do, in your, in your life to keep you from staying focused. And then you, you, as opportunities come that are actually in line with your business, those are where you put that creative energy. You know, you see, like, the problems within your own business. That are, okay, if I'm solving this, it's not just the business, but it's actually going to help my customers, and it's still in line with our, our, our vision for the future, go for it.

Do creative things there.

Speaker 3

Find yourself satisfied with those problems.

Speaker 2

And if you say no, then that means that you have the margin to, to execute on the things, the opportunities when they do come along.

Speaker 1

Correct. Yeah, yeah. There's a term, which I'm sure anybody who's read, I, I can't remember the author's name, but as soon as I say this, you probably know it. It's optionality, right? It's from the, the, the, the books that are about black swan events. And I can't remember the author's name, but anyway, Nassim, I think, is the last name.

But anyway, bottom line is that book, it was really one that, that when I read it, I was like, oh, I like optionality. And optionality means that you prepare, you, you open up so you're ready for these things. And if you're doing, if you're doing too much to fill all of your time, you have no optionality. You get optionality by leaving space open so that you can explore something else, whether that's inside your business or outside your business, at work, at home, in your hobbies, it doesn't matter.

You've got to leave those moments for inspiration to, to come and go, oh yeah, I'm going to follow that and see what happens. And you only do that if you actually plan for it, that, that you, or get really lucky.

Speaker 3

Anthony, thanks so much for, this great conversation. It was great to, meet you at XO Ruby, just briefly and then really get to dive into your story today and hear all about Dan Simple. So thanks for, thanks for joining us. where can people find out more about Dan Simple and about you and, where are you going to be coming up and any conferences coming up that, that we should know about?

Speaker 1

Yep. So first of all, thank you for having me on. It's been a blast. They can find more about The Unsimple pretty much at theunsimple.com. If they have questions for me about The Unsimple, they're welcome to reach out at my personal address, anthony at theunsimple.com or anthony dot eden at theunsimple.com. Both will work. I only ask, please don't spam me.

I'm a very big proponent of not, of not getting spam, and when I get spam, I market as much. So don't do that. But if you have legitimate questions or things that you want to talk about that are related to this, this podcast or, or running an indie business, or just be genuine, just don't try to sell me something, but if you want to actually talk, I'm there.

I'm also on LinkedIn, so aeden on LinkedIn, a e d e n. I will be at MicroConf, next week, so MicroConf Europe. We're going to be in Turkey and Istanbul. both my wife and I will be there, hanging out with our MicroConf folks, which we love, talking about businesses, independent businesses, small businesses, tech businesses, things like That.

and then we have team members who are going to be at the various XO Ruby events coming up. we pretty much have every event covered from here on out. So one of our new folks grant is going to be over in New Orleans. So if you're there, if, if, if this probably all going to be published after that. So, so if that's the case, then find one of our folks and talk to them at one of these XO events.

and I'm going to be around as, as, as I more I can get out to events, the more I will. I love seeing people in person. I love the inspiration of being at events. so just keep following along. I talk about it a lot on LinkedIn. So you'll know I'm going to be somewhere if I'm going to be there.

Speaker 3

Okay, cool. Great.

Speaker 2

Thanks so much for joining us, Anthony.

Speaker 1

Thank you again for having me. Appreciate it.

Speaker 3

That was great.

Related episodes