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 Sonier 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 nonsense monthly dot com.

I'll say it one more time nonsense monthly dot com.

And now without further ado, here is today's episode.

Hey today I'm here with Sean Shirtel, founder of Code Pilot.

Sean, welcome.

Thanks for having me.

Yeah, I appreciate you being here.

Um so you're here because we found each other on Reddit.

I put out a post that I was seeking guests, and I'm really glad that you responded.

I had a handful of people reach out, maybe five or ten people at this point and counting.

Um, but tell us a little bit about yourself and Codepilot.

Yeah, so um CodePilot is a web application development agency based in San Francisco.

And we specialize in fully custom uh database-backed web and mobile applications.

And I've been a web developer since the 90s, actually.

And when I saw your post, I I thought it I thought, huh, that might be kind of perfect, actually, for me to jump in there because uh I've kind of an interesting history with Rails in that I I actually started using Rails and shipped my first production application before Rails went 1.0.

Oh, wow.

It was still in beta.

Uh so that was back in 2005, I believe.

And uh was really happy with Rails for a while.

I mean, obviously, when it came along, it just kind of blew everybody's minds.

Uh we who were you know trying to stitch together pieces of PHP or even Perl before that.

Like it was just a nightmare.

And then Rails came along, blew everyone's minds.

Uh, I embraced it immediately, and then somehow kind of went off and started doing other things for the next 20 years and recently uh came back to Rails.

And so my agency code pilot is now uh doing all new green field projects, unless there's some really specific reason not to.

Uh we're just doing Rails, Rails, Rails all day, every day, and I could not be happier with it.

Yeah, that's great.

It's always great to hear people hear about people who are doing not just maintaining existing Rails applications, but doing new stuff in Rails.

Um and I feel like there's been kind of a renaissance in recent years.

Do you feel that way too?

I hope so, because I I'm on fire about it and I don't want to be the only one.

Yeah.

Um, and is this, you know, you you're on fire about it.

Has that been like a sustained feeling going back many years, or like do you feel like recently a renewed energy about it or something like that?

Yeah, well, like I said, I I kind of went out into the wilderness for a couple of decades and didn't touch Rails at all, and even kind of quietly thought from my you know, JavaScript uh stack perch, React, and then Svelte and uh Meteor before that, you know, all of these this whole ecosystem.

Uh there was this sense for people that are in, or at least at that time, and at least for me, there was a sense that like we were the future, like we understood how web applications were supposed to be built, and the only people still using Rails were you know people who just didn't keep up.

They're they're still like stuck in the old school way of doing stuff.

And uh, you know, obviously I don't feel that way now.

I I came around the other side to that and and just um completely um I don't know, just really happy with server-side rendering, working with the web as a platform, embracing the the standards of HTTP and you know, just like I said, working with the platform feels so freeing.

It's it's so so much less friction.

And uh yeah, so it's just a complete reversal, you know, where where I was a few years ago, thinking like these people are too old school to keep up with the future.

Uh, I now feel like these people had it going on the whole time and I was missing out.

Interesting.

And and was there like some catalyst that brought you back, or was it just coincidence, or how did you come back to Rails?

Well, like I said, I went through this um, you know, not not to trash talk JavaScript too much, but I kind of have to a little bit just because that is my my personal you know experience.

Um just getting stuck in node module hell, you know.

At one point, I I remember I ran you know a WC command or something to to count up uh how many node modules were actually in there.

Because if you look at your package.json, that'll show you what's at the top level, but it doesn't show you all of the dependencies, dependencies that you're bringing in too.

And I saw that for this really simple little project, I had like 1200 node modules, you know.

And half of them were like done by some guy named Bob, you know, like like there's no guarantee that any of this is going to be working in a year.

And in fact, there's almost a guarantee that it won't be.

Um and so I just encountered that a few too many times.

A client would come back after six months or something and say, Hey, can we have this little tweak?

And the build process wouldn't work.

And, you know, I'd have to report back that we're six hours in and not any closer, you know.

And it's just not satisfying.

It wasn't fun anymore.

Yeah, that hurts.

Um, yeah, for me, I've become increasingly anti-third party dependency in general, um, for for very similar reasons.

Um it's just another thing to have to update.

Um, and it's it you know, um, I think a lot about entropy, and and we're constantly having entropy rain down upon us, and we have to work against entropy to have our little, you know, entropy is is is the law that says that uh disorder in a system never decreases over time.

So we we have our um little bubble of order, and this disorder is coming at us from all directions, and we have to constantly be doing work to take the disorder from our bubble and push it outside of the bubble so that the bubble can maintain order.

Um and a web application or any program is you you can think of it as a bubble of order in a sea of entropy.

And third-party dependencies are a great way to leak entropy into your world and create more it increases the amount of work that you have to do to keep the amount of to keep entropy at bay and stop the disorder in your orderly system from increasing.

Wow.

I I've never heard it put quite like that, but I I completely agree.

Uh it's not just JavaScript, it's really everything.

I mean, even Ruby on Rails to some extent.

And I maybe I wasn't around for this era, but from the you know, Rails 5, Rails 6 era with Webpacker and stuff, I've heard the horror stories.

And so I think that um yeah, it's it's everywhere.

I mean, maybe it's everywhere, everywhere, but it's certainly everywhere in programming.

And it's always a struggle, I think, to try to pull back, try to find the simplest solutions.

Don't engineer workarounds for the workarounds, you know.

Um there's a whole category of WordPress plugins that are meant to solve the problems that other WordPress plugins introduce.

Oh, Christ.

I know exactly what you're talking about.

Oh, if if uh if you'll indulge me for a second, I have another metaphor that I really like.

Yeah, go ahead.

Um I I I came up so so I recently started putting together this list of development principles that I try to follow.

Um, and I'd not finished with the blog post because it just keeps growing as as I'm like, oh yeah, this too, obviously.

Um, but one of my rules is no epicycles.

So if anybody's not familiar with with epicycles, um hundreds of years ago before um before people knew knew about uh the heliocentric model of the solar system, um, we had the geocentric model.

And it could uh uh the this model could explain the positions of the planets pretty well.

Um because even though the model was mistaken, um and if you diagram it out, instead of having these neat concentric circles around the sun in the center, you have lines just going uh squiggly all over you know with the earth at the center.

It's a significantly more convoluted diagram than the heliocentric models diagram.

But again, it it produced pretty accurate numbers uh because what these guys did um was they had circles around the earth.

Um and then on those circles, if if you imagine a point uh moving around a circle, uh around that point was another smaller circle with a point on it.

So we had circles on circles, and these little circles were called epicycles.

And turns out if you put enough epicycles inside of epicycles, you can approximate any uh curve uh to an arbitrary degree of precision.

So they had they had enough epicycles on their on their model that it gave very accurate numbers.

Um but two problems.

It it didn't correspond with reality, their their model didn't correspond with reality, uh, and their model was way more complicated than it needed to be.

And I've heard that uh there's become like a uh a little derogatory saying in science uh where if somebody has like some convoluted theory and they're like, oh, okay, well, I can account for that by like blah blah blah.

People say, Oh, you're just adding epicycles.

Um, because the only reason you need any epicycles at all is because your model is wrong.

And so I have a rule of of no epicycles, like this WordPress thing.

WordPress is a great example of a terrible, terrible piece of software.

Um and you said it, not me.

This this phenomenon of these plugins to address the problems of other plugins is a great example of epicycles or even the core.

Yeah.

Oh man, everything is a post, just everything.

Um, and and what they really should do, obviously, never gonna happen now, way too late, is go back and change the model.

You know, WordPress has a geocentric model metaphorically, but they're never gonna change to a heliocentric model.

It's just way too late.

Everything depends on this uh incorrect model.

Anyway, that's that's my no epicycles rule.

Well, yeah, that makes perfect sense.

Have you spent much time in kind of React Node Svelte View World?

No, no.

Well, I mean, based on everything I just heard, I I think it would be, shall we say, not a great fit for you.

Yeah, it's because it's all of that.

It's just like we oh well, here's a problem.

Oh, okay.

Well, let's stack this on there to fix that.

And oh, well, now that causes this problem.

No problem.

Let's just stack this on top of that and rinse and repeat over and over again.

And, you know, again, like not to to be to throw too much shade at at JavaScript or JavaScript developers.

I use JavaScript every day.

I kind of like it.

Uh I don't like TypeScript.

I kind of hate TypeScript, uh, which makes me which which already makes JavaScript not a good fit for me because the whole world has moved to TypeScript now.

And if you try to just do JavaScript in a TypeScript world, uh it's you're kind of swimming upstream.

You know, some tools say they'll also work with JavaScript, but they don't very well, you know.

But getting back to the original point, there's just so much layered complexity.

And it's always uh, you know, I think I don't know if if uh I made up the term or if I heard it somewhere, but it all it always feels like it's adding complexity in the pursuit of simplicity.

There, you know, like Svelte, for example, Svelte is kind of a beautiful thing, especially compared to React.

If you're coming from React and you go to Spelte, you're like, oh wow, breath of fresh air, you know, because you're not writing JSX inside of, you know, essentially JavaScript files.

Uh you're writing basically HTML templates.

It feels familiar, but it's kind of a trick because what you're really writing are instructions to a compiler that's going to spit out a bunch of very complex JavaScript.

And so, you know, for the most part, that's transparent to the developer.

You don't really see it a lot.

It it feels like you're just writing regular HTML and CSS.

Uh, but the devil's always in the details.

And sometimes when you hit that thing that just isn't quite working right, it's you know, you you're you feel almost powerless to try to figure out what it is that's going on.

And so, like I said, you know, this is where I I just reached this point where I just felt like there was so much um just layered complexity.

And and so I I I started it really started when I uh started reading Carson Gross's stuff and taking a look at HTMX.

Have you ever played with HTMX?

No.

HTMX is a brilliant idea.

It's why don't we just go back to Ajax but do it in a declarative way?

That's basically what it is.

What if we it would be really nice if HTML just added this ability uh to, for example, trigger server-side events without posting a form?

You know, what if you could just attach some, you know, put some attributes on a button and have that make a request and then do something with a response.

And what if you could just do that in a really clean declarative way?

It'd be really nice if HTML just added that.

Uh since they won't, HTMX is a 13k, I think, library.

Uh you can just use it from a CDN.

You don't have to like sign up for the whole node.

Modules, ecosystem, you know, just a line in your head, your HTML head, and now your HTML has these superpowers.

And that kind of blew my mind just because it was going the opposite direction from all of this layered complexity.

And so, you know, there's there's a lot in the middle that I'm about to skip over, but that was really about three or so years ago where I realized I want to go back to server rendered.

And I tried a whole bunch of stuff, including developing my own uh JavaScript frameworks that really were just trying to build Rails in JavaScript.

Uh and I went through quite a long journey before I finally um realized that you know Rails has been there all along.

It's it's exactly what I want.

And with Hotwire, which is by the way, very similar to HTMX, uh, the turbo frames and turbo streams part are implemented differently, but same kind of concept.

The concept being we can get spa-like interfaces and interactivity uh without throwing the baby out with the bathwater and rendering everything on the client side.

Like that there's a there's a third option that didn't really exist when things like React came out because browsers weren't that good.

CSS transitions weren't that good.

You know, we there was with view transitions didn't even exist.

And so there's really a lot that we can do now to uh compete on a uh a polish level uh with React websites and spelt websites that wasn't possible when React came out.

It used to be if you want your site, your your app to feel modern and and just be you know really kind of that level of fit and finish, you had to sign up for all of those layers of of complexity.

There was no other way.

Um now there is a way.

HTMX sort of got me excited about it, and I and I even to this day, I kind of like HTMX's approach a little better than Hotwire.

I know that some people are even using HTMX with Rails.

Uh but part of the thing for me, you know, with the the finally getting out off of the choose your own adventure JavaScript stack train where you have to kind of mix and match all these different pieces and hope they play nice together today, and then hope they continue to play nice together in two weeks, you know.

Um because I got off that train, what I decided to do was go all in on Rails and really just go in with all of the conventions.

Don't reinvent anything.

Uh and so that even meant giving up my beloved HTMX and uh and signing up for Hotwire.

Even though I don't love Hotwire quite as much, um it's it's fine.

And it it works perfectly with Rails.

It's a it's a hand-in-glove fit.

So um, yeah, it's it's just really uh it's just really a breath of fresh air to have this whole system work.

I don't have to go choose my own ORM.

I don't have to go choose my own auth system.

Uh I don't have to spend half the day battling NPM modules because my ORM no longer plays very nicely with my auth system.

You know, it all just works.

Yeah, this is this is really nice to hear.

Um something that I think is good about this podcast is that I happen to be a Rails guy.

You know, you're a Rails guy, I have a lot of Rails guests, um, but it's not a Rails podcast, it's it's called Code with Jason, not Rails with Jason.

It used to be called that actually.

Um but my my hope, and I know that this happens more than zero.

I know for a fact that it does happen, is people come to the podcast even though they're not Rails people, but then they hear about Rails stuff.

One guy told me your podcast is my favorite podcast, even though I'm I'm not a Rails programmer, and that made me really happy.

And my hope is that some of those people who come and listen uh are are tempted to try out Rails, and then they become Rails people also.

Yeah, it's funny.

I have a a really good friend named Jesse.

Uh we've actually been friends for a very, very long time, decades.

And uh he he's starting to kind of warm to Rails.

You know, he saw me go through what every JavaScript developer goes through, which is you know, shiny object syndrome, where you're like, whoa, Svelte, Svelte is awesome.

And then three weeks later, you know, whoa, uh fresh JS, the Dino one, like that's really awesome, you know.

And so when I got into Rails, uh he just assumed fairly so, you know, totally, I completely understand why he would uh that this was just the the flavor of the week for me.

Um that's another big benefit, I think, is just getting off of that hype cycle and and just kind of settling in.

But uh yeah, that's that's kind of uh where I landed with it all.

Uh it just I just don't want to deal with complexity anymore.

That's basically it.

And and I can't and I've tried everything, and I just can't find anything else that comes.

You know, really, even if you just look at Active Record, like Active Record is genuinely beautiful, I think.

And and nothing else comes close.

Like, have you tried to play with something like Prisma or um I haven't tried anything else in a long time because nothing has come across my radar that that looked like it had a shot of being comparable?

And I mean, maybe it's not even really that, it's just that like I'm not really in the market for anything to switch to.

And then also it's it's not like I just have heard about like, oh, there's this new ORM that's like actually pretty good.

Go check it out just because it's interesting or whatever.

I hadn't I haven't heard of anything like that besides maybe the the closest thing that that I've heard about to like the Rails philosophies and stuff like that outside of Rails is Laravel.

Um but then you gotta use PHP.

Exactly.

Exactly, and it and it's like why?

Like it's everything's just as good, except the language is a much worse language, no offense to the PHP enthusiasts out there, all like 17 of you.

Um, there's a lot more than that with Laravel, I think.

I I've never tried Laravel myself, but I have heard that it's really good, and especially the the batteries included part.

From what I understand, there are just a lot more batteries uh that are yeah, really well connected.

But I mean, I I've looked at some tutorials before, and I'm just like, yeah, that would be nice if it wasn't in PHP.

It's simply because it's just I I don't want to type that many characters to accomplish such a simple thing.

But that's all it is.

Exactly.

Yeah, it it just feels like as DHH always says, it's a lot of blind noise.

Well, I think there are two concepts that are very closely related.

Um, and and I think like DHH must really get these concepts, um, and those are abstraction and leverage.

Um, you know, Hotwire is a great example.

Um, it it abstracts away a lot of the like JavaScript boilerplate that may we might otherwise have to write, and that abstraction gives us a lot of leverage, or I'll give another example too.

Um uh like generating um scaffolds, scaffold generators.

Um it abstracts away the process, you know, you still end up with with code, but abstracts away the process of writing that code.

It's gonna be very similar every time, so why not just take the one part that's different, which is the entity name and the attribute names and stuff like that?

It can extrapolate everything else based on that.

So why should I have to do anything more than that?

Every single time.

Yeah, so it abstracts it away and gives me leverage.

I I think that's like the big thing.

Yeah, and really though, if I just kind of zoom out, I mean I'm kind of going off on all the details that I love about Rails, but the the number one thing for me really has nothing to do with Rails.

It's I want to be able to build projects, you know, products or applications, either for my personal projects or for my clients' projects.

I want to be able to do it fast.

And and I want it to not be this very brittle house of cards that, you know, even if you don't do anything to it, it might break in a couple of weeks if you try to, if you have to rebuild the node modules for any reason.

Um and yeah, so it's really just about productivity for me.

And I gotta say, I have developers on my team who are steeped in JavaScript stacks.

And when I told them uh that we're gonna be using Rails for projects given, you know, obviously sometimes it doesn't, it's not the right fit, but for most projects, it is the right fit for the kinds of projects that come to us.

When I told my devs that that we're gonna start doing stuff in Rails, I I think you know they're they're polite, but I think that what they were thinking is like, oh my God, Sean's lost it.

Like he's he's getting too old, he's like going, he's embracing like the old ways of doing stuff.

And uh they were resistant to the idea, but they've come around.

You know, they they are coming back and saying uh, and again, it's about productivity.

And and just in real world, I had a project that started uh well that it came through the door about six months ago, and he asked uh my client, you know, asked for an estimate of of what the timeline would be.

And I said, two developers and a project manager, you're probably looking at about six months for that project.

And we use usually we use halftime developers.

Uh, I find that we get much more productivity that way.

It's just kind of the right pace for most projects.

And so I predicted six months.

That got postponed.

The client didn't want to start after all at that point.

And so we actually just started two months ago.

I assigned one developer instead of two, and it's nearly finished, it's almost launch ready.

There's like some I's to dot and T's to cross, but the it's basically done.

So, I mean, that's not quite an order of magnitude, but it is substantially faster.

Yeah, yeah, that's so great.

Um some ways that I think about it um are like fewer moving parts.

And it sounds like even though you didn't use those exact words, it it sounds like maybe that's that's part of how you view it.

And that thing I said earlier about like entropy and third-party dependencies, um, those were like vague thoughts in my head.

I've I'd never said exactly that out loud before.

Um, but a thought that I'm having now is the concept of like, you know, in in security they talk about like a risk surface area um or an attack surface area or whatever.

Um you might also talk about like an entropy surface area.

So if you have a lot of third-party libraries, that's a larger entropy surface area.

Um and and and just however much like incidental complexity you have in your application, just anything that's susceptible to software rot, uh, because software rot, I think, is basically just entropy by a different name.

Um the more you have of that, the bigger your entropy surface area.

I just wanted to make a note of that because I'm like, oh, that's maybe a useful little tidbit for later.

Yeah, no, it's it's a great lens to see this through.

Uh I I just remember, you know, in in the in the olden days.

Let me tell you, Sonny.

In the in the olden days, uh, you would write your PHP in a text editor.

Uh if you're really lucky it had some kind of syntax highlighting, you would drag it into what was it called, like transmit FTP, and and it would go up to the server and then it would just work.

Like that was your deployment process, you know.

And when the client wanted something fixed, you fixed it in that one or two files that needed to be touched, and then dragged those into the FTP and it was deployed.

You know, it was just it it was it was a lot simpler.

And obviously, like Web 1.0 was not a paradise in terms of what we were actually delivering to users.

Uh, but that simplicity is is is missing today.

Uh and especially now that CAMAL 2 is out, and especially now that CAMAL, I think it's 2.1 or 2.2, is out, uh, which doesn't require a remote Docker container registry.

It uses your local machine as the container registry.

That makes it so simple.

Have you have you had a chance to play around with CAMAL much for deployment?

No, I use Kubernetes.

That's what I've used for several years at this point.

So I've never gotten deep into CAMAL.

Well, I was resistant to it at first because it involves Docker.

And I've always felt like, and I still kind of do, just philosophically, that uh Docker is a container system.

It's for containerizing your uh I think software.

And it's uh kind of arguable whether that uh means that it's naturally a good fit for deployment.

I used to argue no.

I I used to argue it's overkill for deployment.

You know, why do I need to upload essentially my entire tech stack along with my code?

You know, somebody wants to remove the middle initial from the name and the footer, and that means I've got to re-upload the whole tech stack too.

But I've come to embrace it.

The the benefit of it is that you get all this simplicity on the other side.

The the server is just a dumb Ubuntu box with Docker installed, and that's and a proxy server.

And that's it.

That's all it is.

And everything else in your app lives in that Docker container, and you don't even really need to think about it because Kamal takes care of it all for you.

And it's pretty fast, takes a minute or two for me to deploy a typical app.

Uh it that's the first time, you know, then it caches layers and it's faster after that.

And it builds your whole server for you.

All you need is literally just sign up at DigitalOcean or Hetzner or whatever and get your IP address, make sure you have an SSH key, you know, access, and type a CAMAL command.

It's it's Camal setup.

That's what you type at the at the terminal, and it installs Docker and does all the stuff you need on the server, it's fast, and then you can start uploading your applications.

And it's not just Rails applications, you can upload Laravel applications and WordPress sites and whatever, because it just bundles it all together and then shoves it up as a container.

And what's also really nice about that is portability.

So if Hetzner gets bought by Microsoft tomorrow and just starts sucking from that day forward, um, it's not a big deal to just point it to some other blank Ubuntu box, and you're back in action and it will be identical.

Okay.

Yeah, um I I totally resonate with everything you just said.

And those those reasons are basically the the same reasons that uh attracted me to containerized deployments.

Um things things kind of clicked for me.

Um, you know, people talk about Dockerizing an application, and that framing of it uh gave me a confused idea for a long time.

Um I I realized later that at least my view now is you don't really Dockerize an application exactly, you Dockeriz an environment, and it there's there's pretty much two use cases.

You can Dockerize your local development environment and or you can Dockerize your production environment.

And once I understood that and framed it as I'm Dockerizing my environment rather than I'm Dockerizing my application, it made more sense to me.

Um something that I uh am curious about with Kamal is um is um can you do like things like blue-green deployments and stuff like that?

Like those are some things that um attract me to to Kubernetes, because you can do that, you can have like uh during a deployment, you can have um a readiness probe where it's like hit this one certain endpoint, if you get a 200 response, proceed with the deploy.

If you don't abort the deploy uh so that you can um stop yourself from having downtime events because you're doing a bad deploy and stuff like that.

Um, it's the default behavior.

Okay.

That is the default behavior.

So it it pushes up a new container, and then it uh you know, it in your default Rails app, there's a slash up route.

Right.

And and it's for that purpose.

I mean, I don't know if it's specifically for Kamal, but it's it's for checking if your if your site is up.

And uh Kamal uses that by default.

So if it's not getting a 200 back, then uh you get an error message and nothing happens.

Your previous container just continues to run.

So the way it works, I'm I hope I'm getting this right.

I'm I'm not really an expert on this, but uh the way I understand it to work is Camal pushes up the new container, spins it up uh kind of in the background, checks for that up route.

If that all looks good, then it updates the proxy to point to the new one and then renames the old one, I think.

So there's also a rollback option.

Oh, I think I'm starting to understand something that I didn't understand before.

Um, might it be the case that?

Like you have one Ubuntu server or whatever it is, and then inside that you have a container running with your application.

Then when you do a deployment, a second container in the same machine uh spins up, and then if that's good, then traffic starts pointing to this new container, and then the original container falls away.

Is that the idea?

That's right.

And then also at the same time, things like your database connections will also swap over in kind of the same split second.

And I didn't mention, too, which is also pretty cool, that you can have as many Camal applications as your server can support, and they don't even all have to be the same kind of application.

You can have a a WordPress site running alongside a Rails site next to a Django site, all on the same server.

Okay.

So if you wanted to just uh provision a gigantic VM and host you know five different applications on there because for some reason that's what you want to do, you can do that.

Yeah.

I mean I do that.

Yeah, so uh I have just a it's not even that big of a box.

It's like a$40 Hetzner box.

And I'm running like 10 little applications there.

You know, it's fine.

If you're if it's a high traffic one, then you probably want to shift that over.

But again, Kamal makes all this stuff so portable that that's just not a big deal.

If if one of those applications grows to be too big, it's like a you know, maybe an hour-long project to and probably less than that, really.

It's it's just easy.

You just shift it over.

Okay.

And something I always think about is redundancy.

So I I have to imagine that's probably pretty easy if you're nervous about just having one server instance.

You can have two or more, and they probably just all run Camal.

And when you do a deployment, each Camal instance picks up the new deployment and does it in about the same way.

Is that how that works?

Actually, Camal supports that natively.

So you can when the the command is commal deploy, and in your config, you can either set your in your YAML file uh a server or a list of servers.

And it works either way.

So you can just by default without even really thinking about it much, you can deploy it to multiple servers.

Okay.

And do you know how it handles load balancing?

Uh I don't actually.

It's not something I've had to deal with yet.

This is another thing that gets me so excited about uh just kind of the modern day that we're living in.

You can scale so far up vertically.

You know, I I don't know the last time I really had to think much about horizontal scaling or you know, sharding a database or something.

Uh a single, you know, I'll just say Rails app, but it it could be a node app or whatever, uh on a big Hetzner box can really support a ton of concurrency.

And you know, if it if you're for if you outgrow your$40 box, not a big deal.

Like bump it up to the$120 box.

And on Hetzner, for example, when you get into the I think it's like$320 or something, it's just a monster.

You know, you've got I think 128 gigs of RAM or something, and and uh 64 virtual CPUs or something crazy like that.

So I think uh, you know, unless you're getting into the really huge enterprise territory, you can really go far with just a single box these days.

Man, um I'm I'm having a problem right now.

Um I'm I'm paying so much for for hosting for my app that I've been building.

So I mentioned pre-show that I'm building this thing, and I haven't told you anything about it yet.

Um it's a CI platform.

And so when it when it runs tests, uh, like I said, I'm using Kubernetes, and there's the Kubernetes production infrastructure for the web instances, and then there's a different Kubernetes infrastructure for running people's test suites.

Um and so there's there's uh you know it's it's not like there's just one single server, there's there's multiple for different purposes.

And in December, uh, which as we record this was last month, uh my digital ocean bill was like 1400 or 1500 bucks, which is not sustainable.

My my monthly revenue is twenty dollars per month at this very moment, um, which is less than fifteen hundred by a lot.

Um and and I I did some optimizations, and so now congratulations, my January bill is looking like it's gonna be about twelve hundred bucks instead of fifteen hundred.

So yay.

Um, but I need to do some some serious things to get that built down.

Well, I think moving to Hetzner might be a good start.

Have you used them before?

No.

Uh I I've been using DigitalOcean since they came out like 10 years ago.

I I've been a long time fan of Digital Ocean.

I still am.

I really like them and run some servers at DigitalOcean.

But Hetzner is, you know, I I was less intrigued by the lower pricing.

Uh but if you just turn that upside down and think about it differently, I started getting really intrigued by wait, for the same price, I can get a server that's four times as powerful.

You know.

So and it really is about that, maybe three or four times.

You know, you're you're getting twice as much RAM, twice as many virtual CPUs.

It's all NVMe, uh fast SSDs.

And you know, it's it's basically the same level of service.

I I've never seen any downtime at all.

So their uh dashboards and stuff are not quite as polished as DigitalOcean.

But uh yeah, well worth it.

And if uh yeah, if you get if you go one for one and get the same hardware or virtual hardware that you've got now at Hatsnery, uh that alone would probably cut your bill in a third.

Yeah.

Yeah.

Um the the dashboard UI and stuff like that is less of a priority for me than the price of it because not only is there the challenge of being a bootstrapper and paying your expenses out of your own pocket, um, but there's there's like the margin that I that I need to make, you know.

Basically, people expect to pay for these things per unit of compute time or whatever.

And so uh I I think Circle CI for the specific tier I was looking at, it's like uh 0.6 cents per hour or something like that.

And so if if I want to roughly be a parody with them, that kind of dictates my pricing, and so my compute cost can't be more than that, or else that's that's no good.

Ain't gonna work.

Yeah, yeah, exactly.

Um yeah, well, can you tell me more about your uh your CI platform?

That sounds really interesting.

Yeah, yeah.

Um, so the reason why I wanted to create it is out of frustration with like Circle CI and GitHub Actions and stuff like that.

Um I uh my personality, I'm I'm particularly sensitive to like UI um pains and stuff like that.

Just anything that is like designed in a dumb way really frustrates me.

Right.

Um I don't know why this is coming to my mind as like the quintessential example, but when Tim Cook took the 3.5 millimeter headphone jack away from us in the iPhone, that to me that was like an inflection point in the history of Apple as a company.

They went from they super You're still bitter about that.

Oh yeah, it's it's like a daily bitterness because like I I've never stopped wanting to plug headphones into my phone, you know?

Right.

Um and and I, you know, I'm old enough to have had a phone in the early 2000s before the iPhone.

I had you know like the Motorola flip phone, and it was a piece of shit.

I hated it.

Um and then when the iPhone came out, it had a headphone jack, and it's like, yes, these people get it.

And then when Tim took that away, it's like, no, they don't get it anymore.

Well, he gave you AirPods at the same time, right?

No, thank you.

That's not what I want.

Um Yeah, and and you know, that's uh Steve Jobs, I think, talked about like the the cool factor, like you and and people just it looks no offense to anybody who wears AirPods, but it looks kind of weird.

It's like it doesn't look as cool as like making what wearing headphones can like make you look cooler.

And wearing wait, are you wearing are you wearing the the no no I would never?

Yeah, I am yeah, but you know why?

Let me tell you this.

You know why?

Uh functionality, it's unbeatable.

I I have this uh fairly nice large diaphragm vocal mic next to me, and before we started talking, I did a couple little test recordings just to make sure because I haven't used it in a while.

And sounds fine.

But then I was like, let's just see how the airpods sound, too.

They sound better, they sound better than my large diaphragm vocal mic.

So okay, maybe I could be persuaded on that particular thing, but I will die on the hill of the headphone jack in the phone.

Um because obviously you could you can have airpods additionally.

Um anyway, um I am personally and deeply offended by CircleCI, GitHub Actions, Jenkins, all these tools.

Uh they're just so frustrating to use.

And I think I started using Circle CI in like 2013 or something like that.

So I've had this pain for years, and in the back of my mind, I'm like, I want to fucking drive these guys out of business and and build my own thing because fuck you guys for making such a shitty product.

Um, but I I kept not doing it because it's kind of an insane idea.

It's like a big complicated thing.

I'm just one guy, I'm not gonna do that.

And then GitHub Actions came out whenever that was like 2018 or whatever, and I'm like, okay, yeah, like this buries the idea because anything that I could do, GitHub with their resources, they could just do my thing better, and just like I'm redundant, you know.

There's this there's no way.

And then years passed, and I kept being frustrated with these products that never changed, they never got any better.

And finally, I'm like, you know what?

Uh, I don't even care anymore if it's a viable business idea.

I'm just like so upset about this that I'm gonna build my own thing just as like a mode of self-expression or something like that.

I just want this thing to exist for myself.

Uh, this was like mid-2023, and so this timing also kind of coincided with the rise of AI-assisted programming.

And so I'm like, you know what?

Now that we have this increased leverage that we didn't have before, maybe this crazy idea is a bit more tractable, and that turned out to be totally true.

I've I've like zipped right through things that otherwise would have been really difficult and I wouldn't even know where to start and stuff like that.

Um so so that's that's kind of where that came from.

And I'm trying to build something that has like as nice of a UI as a Steve Jobs-era Apple product.

Um, and some of my um principles are like it needs to be like really, really fast, um, and it needs to be easy to use.

Not just easy, but it should be like a joy to use.

Um, it should look beautiful, and I don't want this like modern flat design bullshit.

Like I think the world has gone very much in the wrong direction.

And I'm gonna go for the brushed aluminum?

Heck yeah.

Or or the leather bound.

I mean, I I I don't want to copy Apple, you know, don't copy the masters, seek what they sought, that kind of thing.

Um, so I need it to be my own unique thing, otherwise, like I I've seen the rip-off Apple UIs, like that that's a lame way to go, I think.

I I you need to do your own thing.

Um, but the same spirit.

Uh the the same spirit, and I'm again offended by things like you have a flat design toggle button, and you have like two shades of gray, and one means on and one means off.

It's like, okay, asshole.

Like we used to have a 3D button, and it would be either depressed or um uh what's the word, beveled or whatever, you know?

Yeah, yeah.

You had an indication, a visual indication of if it's on or off, and now I just have light gray and dark gray, and it's like which is which?

Like on my smart TV, uh, you get a dialogue box and you have okay and cancel.

One's light gray, one's dark gray.

It's like, okay, well, which one is selected right now?

I have to like hit right and left a couple times to get to like figure out.

Okay.

I I'm uh No, it's not that bad, but it is it is kind of to your point about it should just be clear and obvious, and it used to be uh it it does feel like they're gonna they're going the wrong way.

Yeah, exactly.

It's like I could understand like trading aesthetic beauty for function or trading function for aesthetic beauty.

I I don't necessarily think that's a good way to go, but there at least is a case.

But what the world has done is they've made things look worse and less functional.

And I'm just so upset by that.

And and so I I could sit here and like complain all day about that, and I do.

Um, but I don't want to just be a complainer.

I want to try to be a net positive and put something into the world that that follows these principles, you know, be the change you want to see in the world kind of thing.

So I want to put a product out there and have people use it and be like, wow, I haven't seen software like this in 20 years.

This, you know, we can have cool stuff again.

That's that's what I'm going for with this.

I think that's you know, you you said earlier on that uh when GitHub Actions came out, you you felt like there's kind of no point.

I don't think that's necessarily true.

You you don't really have to compete with you know GitHub for 100% of the marketplace.

For I mean, if it's a lifestyle business, you'd probably be very, very happy with half of a percent of the marketplace.

You know?

I totally agree.

Or or certainly one or two percent.

And those people are out there, I think.

It's it's not even that you're gonna outdo them, it's that you're gonna do it a little differently.

Right.

I I totally agree.

Um the the the minimum condition is just that there has to be a reason for somebody to use my product instead of a different one.

Back then, maybe I didn't have a strong differentiator.

And or no, that's not it.

Because I did.

I already did.

I'm like, I can make this easier, more logical, more pleasant to use, that kind of stuff.

So I had the differentiator.

I think I was just naive enough to think that GitHub might copy me and and or or just improve of their own accord and wipe out my differentiator.

Right.

I'm a different person now than I was in 2018, and I understand how the world works a little bit better, and GitHub's not gonna improve their product.

They're they're gonna keep it the way it is, and it's gonna take them all they can do just to just to stave off entropy, you know.

Yeah, I mean the the there's also this idea that oh, there's such a you know, there's a massive whale out there, and I'm just a little fish, so how am I gonna compete?

A little fish can is way more agile than a massive whale.

You can you can hear customers and roll new features later that day in a way that the big whales can't.

And we're gonna we're hoping to benefit from that with a startup that I'm involved with now, too, called ZMap, which is uh it's like a mobile first uh field documentation platform, uh specifically for land surveyors and civil engineers.

When they're out in the field, they need to gather information and to talk about it with each other and kind of keep all that stuff organized.

And there are tools out there for it right now.

There are big whales out there, but they're way too expensive.

They have 1,200 features that most people don't even need.

You know, it it's that's another thing.

Is sometimes you you feel like, oh, well, to compete with them, I would have to spend the rest of my life building all 1,200 of those features.

If you can just identify the features that your users are most after and make it just a cleaner, more pleasant user experience.

You know, that's one of the focuses with um the project that I'm working on is the the big dog in the space that that we're going after is called Trimble.

And it they're just it's an overwhelming interface.

You you look at it and you and you just immediately are um motivated to do anything but try to figure out how to use that.

And so uh yeah, with with Zia Map, it's not necessarily that we're gonna do it bigger and better and with more features, and uh or even that we're just gonna compete with them on their own terms.

It it's taking advantage of the fact that uh we're the little fish and we're gonna listen to our users and give them exactly what they want, and it will be uncluttered and easy to use and pretty, uh, because that's not a thing in the civil engineering and world.

I can imagine.

Yeah.

Interesting.

Yeah.

I think there's advantages to being the little guy.

Yeah.

So for context, is this like a client project or is this a project of your of your own that you're directly working on, or what's the story there?

Funny enough, that's there's not an easy Answer to that.

It was a client project 10 years ago when this client came to us and we uh built this um dumpster fire.

Sorry, Brian, but he he he's the client that is now my business partner.

Um it it you know, we were doing the best we could with the technology we had available to us at the time.

So of course we built it all in React, and I think it was initially a Python backend of some kind, and we wired it all together with HTTP requests, you know, and it just wasn't you know gonna be that great uh just by virtue of what we were building it in, partly what we were building it in, and partly uh how much um my client was willing to spend at the time because it was a kind of hobby project for him at the time, a little side project.

And especially with using technology where everything takes 10 times as long, uh, we we kind of needed at least 10 times that budget to really make it sing.

And uh it just never quite got there.

And eventually he uh you know smartly decided, I think I'm gonna stop throwing thousands of dollars a month at this thing uh and and just you know, maybe I could just take it out back and burn it instead, and that would be more efficient.

And so I had been looking for a project that would fit some very specific um parameters.

I I really wanted uh I was kind of following the the Rob Walling gospel, uh and uh which for people who don't know is uh the SaaS playbook author.

And he has some very straightforward ideas about if you're if you're a solopreneur trying to bootstrap your own company, you know, or or even just a few partners, uh, you don't want to try to build this thing and get a ton of VC money and all that stuff.

If you just want to bootstrap it, there is a way to do that.

Number one, B2B, no B2C, B2B.

And you know, it's not that B2C can't be done, it's just you have big advantages if you go B2B.

Number two, it should be a specific vertical, vertical that you're targeting.

Uh and uh and there are other kind of tips that he has.

And so Brian's project, Zia Map, fit all of those for me.

I'm like, this is exactly the kind of thing I need, and it comes with um you know, a domain space expert because Brian is a civil engineer, and so he this is why he came up with this hobby project in the first place, because he saw the kinds of things that you saw.

He's like, why does this suck so bad?

And also, why is it so freaking expensive?

It's just like you know, people are paying thousands of dollars a month for this garbage software.

And so yeah, so because he's an expert in that space and because this project kind of fit everything that I was looking for, I approached him and said, instead of throwing this away, why don't we partner up and figure out an arrangement that works for both of us?

Uh I basically will provide development at cost plus my own uh input, you know, involvement for obviously no charge, and and then we'll do an equity split on the thing.

And uh we haven't launched yet, we're getting pretty close to launching, but we're we're excited about it because uh there does seem to be a big hole waiting to be filled here.

Yeah, that's really interesting.

I uh and I'm very curious, and I don't know how deep you are into this part of it yet, um, but I'm curious about the sales and marketing of it.

I I from like 2011 to 2015, I worked on this startup, you could generously call it, uh, which was scheduling software for hair salons.

And building the software, you know, it wasn't easy, but compared to the sales and marketing, it was very straightforward.

Um, and the sales and marketing required things that I couldn't really afford to do.

Um like you basically have to do door-to-door sales, um, or or go to conferences and and stuff like that.

Like you can't you can't really do online marketing to stylists because they're not on the computer.

Um like some of them don't even have email addresses.

Uh like it's it's crazy.

Um and and then once you get past all that, even though it's technically B2B, they have B2B, uh, sorry, they have B2C style uh B2C level money and B2C thinking.

Um so that made it all really hard.

But anyway, the the path to sales and marketing was just like really not a good one for me and and where I was at and stuff like that.

So I'm I'm curious how you're thinking about that part.

Uh well that did occur to me.

Uh I I suck at marketing, I hate marketing.

It's it's my the least favorite thing uh that I do with uh my agency code pilot.

Uh it's all I can do to just you know try to get a decent looking site launched for code pilot.

Like I yeah, the the outreach and the convincing people and and getting introducing people to our stuff is just not where I excel.

Uh and I I knew that going into this, and and I know that uh that's not Brian's thing either.

Brian is a civil engineer, he's not gonna excel at marketing, probably.

And so uh so happens though that you know, in being in the Bay Area, you you know people that do stuff, and I happen to know uh very talented um he he's kind of a uh the perfect uh jack of all trades.

He he wears the SEO hat, the marketing hat, and the design hat.

And uh he's got a long history.

He did all of the initial branding, I think, for e-trade.

Um, so you know, he's kind of a heavy hitter in that space.

And I I've known him for a long time, so I reached out and said, Um, hey Kurt, I've got this crazy thing.

Is there any chance you might want to get involved in it?

And he's like, Well, I'd I'd take a minute to learn more about it and told him a little more about it.

And he's like, This sounds kind of like a gold mine.

Yes, I want in.

Yeah.

So uh we ended up doing uh yeah, so the three of us are now uh the three partners in this in this startup.

Yeah, that's great.

And it's kind of I think that's a really uh it's part of why I'm really optimistic about this, because I do feel like we've got all our bases covered.

There's no holes.

You know, we have the domain space expert.

We we need that.

Like Art and I don't know the first freaking thing about what's gonna turn the crank for a civil engineer in the field and like what what kind of tooling they need or how they work.

Um and uh yeah, so we have the the domain space expert uh who's also good at at general business stuff.

So he's sort of filling the CEO slot, I'm filling the CTO slot, and then uh Kurt is filling the CMO spot.

So I think that that's kind of the the three legs of the stool.

And I think we've I I think whether you do it with three separate people or or whether you are adaptable enough to wear all three hats yourself, uh I think you kind of need all three of those for a product to be successful.

All three being the uh domain expertise, the sales and marketing, and the ability to build it.

Yep.

Yeah, exactly.

Yeah, um, and I have a million questions about that, and I'm very curious uh about your sales and marketing for for Code Pilot, because you know, obviously, even though you said that's maybe not your favorite thing, uh you've done it well enough to be in business and stay in business and all that, and and so I'm always eager to hear people's stories in in that area.

Um, and there's just a lot of things that we could go deeper into, and and I hope we can in the future.

Um I've got four more hours, and then I gotta call it.

Um yeah, but uh hopefully we can we can do this again if you're up for it.

Um, but as for now, it's it's probably time to head toward a conclusion.

Um, is there anywhere you would like to send people to learn more about you, uh CodePilot, any of that stuff?

Um yeah, I mean, I don't really do a whole lot of social media stuff.

Again, to my point about hating marketing and and all things even peripherally related to it.

But uh yeah, codepilot.com is is my company.

Uh we've been around for quite a while, um, 10 years or so.

I mean, really, we've been around for more than 20 years, but it used to be under a different name, and I changed the name at some point.

So codepilot.com uh and yeah, the the new startup that we're working on is called Zia Map.

It's Z-I-A-M-A-P.com.

And that's not up yet.

Uh so I think yeah, if you go there, you'll just get a not found.

Uh it's we're getting ready though.

I think we'll we'll probably be launching.

When does this air?

A couple weeks or something?

Uh believe it or not, it might air as soon as later today.

Oh, sweet.

Okay.

Well, it definitely won't be up by later today.

Uh but it might be up uh in a couple of weeks or so.

Yeah.

Okay.

Okay, well, we can put a link and uh the people of the future will be able to visit that link.

Um, it's been a real pleasure talking with you.

And Sean, thanks so much for coming on the show.

Thanks for having me on, Jason.

It was really nice to meet you.