Jonathan Stark is based in Providence, Rhode Island. He attended the Berkeley College or Music, with a dual major in song writing. He ended up going back to computers to make ends meet while he was gigging - and he figured out he really enjoyed watching people use the software he built. Outside of tech and professional life, he's married with 2 kids and 2 dogs. He is an avid martial artist, as are his kids, and got his 2nd degree black belt at age 53.At his prior company, Jonathan was leading teams to build software. He wanted to hire senior engineers, but was told junior engineers would better fit the budget. He couldn't figure out why, but then it dawned on him - hourly billing a junior created more margin. He wanted to pivot away from hourly billing as a company and went solo to figure out how to do this. Once he did, he never looked back.This is the creation story of Jonathan Stark and Ditching Hourly.SponsorsSpeakeasyQA WolfSnapTradeLinkshttps://jonathanstark.com/https://www.linkedin.com/in/jonathanstark/Our Sponsors:* Check out Kinsta: https://kinsta.com* Check out Vanta: https://vanta.com/CODESTORYSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
I didn't know what I was going to do, but I knew it wasn't going to be hourly. And that was all I knew. Back then, there were still these things called bookstores. And I was standing in a bookstore and came across a book called Value-Based Fees by Alan Weiss. And that thing was my Bible for a couple of years. Every single page has notes on it. It's a great book.
It's for management consultants, which wasn't at all what I was doing, but it was adaptable enough that I could figure it out and apply it for software projects. So that was my main, air quotes, tool. And then I had to develop a bunch of frameworks that were specific to software development and consulting that made it make sense.
Hey, it's Jonathan Stark here, and I am the Ditching Hourly Guy over at JonathanStark.com.
This is Code Story, a podcast bringing you interviews with tech visionaries who share what it takes to change an industry, who built the teams that have their back, keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as we grow. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve.
Took off the shelf and dusted it off and tried to begin. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on CodeStory. I'm your host, Noah Labhart. And today, how Jonathan Stark is known as the ditching hourly guy, teaching you how to price based on value. This episode is sponsored by Speakeasy.
Grow your API user adoption and improve engineering velocity with friction-free integration experiences. With Speakeasy's platform, you can now automatically generate SDKs in 10 languages and Terraform providers in minutes. Visit speakeasy.com slash codestory and generate your first SDK for free. This message is sponsored by QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Grotta, and Autotrader, you're in good hands. Join the Wolfpack at QAwolf.com. Jonathan Stark is based in Providence, Rhode Island.
He attended the Berklee College of Music with a dual major in songwriting. He ended up going back to computers to make ends meet while he was gigging, and he figured out he really enjoyed watching people use the software he built. Outside of tech and professional life, he's married with two kids and two dogs.
He is an avid martial artist, as are his kids, and he got his second degree black belt at the age of 53. At his prior company, Jonathan was leading teams to build software. He wanted to hire senior engineers, but was told junior engineers would better fit the budget. Then it dawned on him. Hourly billing for a junior created more margin.
He wanted to pivot away from hourly billing as a company and went solo to figure out the best way to do this. Once he did, he never looked back. This is the creation story of Jonathan Stark and Ditching Hourly.
After music school, I ended up going back to computers, which I had done as a kid, to make ends meet while I was trying to get gigs and that sort of thing. So I ended up really liking the database programming I was doing. I call it programming. It was ScriptKitty stuff in an application called FileMaker.
that I had a lot of fun with, really enjoyed seeing big teams of people using software that I had put together. So I went off and did that for a few years with a popular consulting firm, a FileMaker consulting firm. And at that firm, we build hourly, and eventually I was managing the teams. There was about 10 developers at the time. And we build them all out at a blended hourly rate.
I realized at one point that if we were going to hire more employees, we would want someone that looked more like our most junior developer, who really wasn't that good, but had a very low salary. And it would be foolish to hire a really high-end developer like our best developer, because he was really expensive and he was really fast. So...
it was tough to keep him busy enough to break even on his salary where with our junior person as long as they kept their clients happy which they did and we were making maybe four times more profit off of a mediocre developer not even mediocre and then i was like wait a second i don't want to have a firm full of junior devs that barely know what they're doing
And I couldn't wrap my head around this. I was like, this doesn't make sense. Why wouldn't we want to have really good developers? We're like a high end dev shop. It seems like you'd want the best developers you could get. And it took me about two weeks of puzzling over this until I finally realized it was because we were billing by the hour. We were trading time for money.
And as soon as I saw that, I was like, I couldn't unsee it. And I said to the owner, what I just told you was like, we should hire more people like a junior. And he was like, what? So he said, I see what you're saying. I understand it intellectually, but what would we actually do? And I did not have an answer for that. This would have been 2005.
So I went solo to find out what the answer to that would be without risking 10 people's mortgage payments. I'd rather just risk my own. So I went solo in 2006, January 1st, 2006 and never looked back.
So this is really interesting because, you know, as we talked about, normally I ask questions around the MVP of your product, but I'm really curious about what the MVP was about this non-hourly model, right? When you stepped out and you started figuring out how to do this, what was your MVP and how long did it take you to come up with it and what sort of tools were helping you bring it to life?
And coincidentally, I didn't know what I was going to do, but I knew it wasn't going to be hourly. And that was all I knew. Back then, there were still these things called bookstores. And I was standing in a bookstore and came across a book called Value-Based Fees by Alan Weiss. And that book was the answer that I was looking for. That thing was my Bible for a couple of years.
Every single page has notes on it. It's a great book. It's for management consultants, which wasn't at all what I was doing, but it was adaptable enough that I could figure it out and apply it for software projects. So that that was my main air quotes tool. And then I had to develop a bunch of frameworks that were specific to software development and consulting that made it make sense.
There's some nuances in software that are different from more straight advisory services because you are building things. I was still building things at the time. So the main tool was that book, honestly. And I had worked out a deal with my past employer where I had clients that I worked with directly and they wanted to come with me. So we worked out a revenue sharing thing.
So I had clients immediately. I continued working with them on an hourly basis. I converted one to a more of a fixed fee, more retainery kind of thing. But then I set about trying to attract new clients that were not hourly ever. Rather than trying to convert existing reasonably profitable clients, I decided I'll keep them as is and then I'll switch over to something else with new clients.
And then I was like, okay, how do I attract new clients? And started investigating tactics that would attract leads to me so that they were expecting already to be paying a lot of money. Like my intention was to be the guy who wrote the book about the thing and then attract people who really needed that thing.
The MVP was really probably the first time I started to, I tried to write a value price proposal and working through that because it takes a while to figure out how to do it right.
I want to dive in a little bit to, you know, you grabbed the book that was your Bible, and that's what you're using to sort of build your own framework before you did your first proposal. And you mentioned some nuances there. You had to shift towards building things. Tell me about some of those nuances.
And I suspect in those nuances, you probably had to make decisions and tradeoffs around how you're going to, you know, shift from the service-based, value-based pricing to what you were wanting to do. And tell me about some of those that you had to work through.
So there was some pretty straightforward stuff that anyone would get out of that book. For example, when you give a project proposal, give them three options. They're deciding what's the best way to work with you instead of should we or should we not work with this person or should we go to someone else? That piece of advice alone, having three incremental options like good, better, best.
is a game changer in terms of your ability to i don't want to say upsell but if you're not super great at value-based pricing which no one is when they first start then it gives you a way to not leave as much money on the table as you might if you just gave them like one lowball option or something like that that one thing was super helpful and straight out of the book
The things that I had to figure out, the main thing I had to figure out was that since I was giving quotes, fixed prices, not, oh, I think it might take me 100 hours, but whoops, it was 200. Sorry, it cost you twice as much. So since I was going to give prices and stick to them, in fact, it said in my proposal, whichever price you choose of these three options, you will not pay a dime more.
So then for a software person, immediately you're like, how do I control scope? That became the biggest problem to work out. Like, how do you figure out how to manage scope creep? When a client's coming along, they run a shoe store or pizza place and they don't know anything about software. You can't get all the scope you need from talking to them in an hour.
So you're automatically not going to have all the information that you need before you get started. So what do you do to address that? And those are the sort of frameworks that I've created around that. But also this thing called the why conversation to help in the sales meeting and then a major mind shift that I call scope last.
So if you're in a sales meeting, you do not try and do not even try to scope the project in the sales meeting. You're going to scope it later after you know what the value is. You set some prices based on the value. Then you decide what scope you're going to do based on what the desired outcome is and which price they choose.
So I would say the why conversation and scope last are like two terms or phrases that I use a lot when I'm teaching this to people. And both are pretty mind blowing and take a while for people to fully integrate into their processes or their business.
This message is sponsored by SnapTrade. Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's Unified Brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This episode is sponsored by Speakeasy.
Whether you're growing the user adoption of your public API or streamlining internal development, SDKs can turn the chore of API integration into effortless implementation. Unburden your API users from guessing their way around your API while keeping your team focused on your product. Shorten the time to live integration and provide a delightful experience for your customers.
With Speakeasy's platform, you can now automatically generate up-to-date, robust, idiomatic SDKs in 10 languages and Terraform providers in just a matter of minutes. SDKs are feature-rich with type safety, auto-retries, and pagination. Everything you need to give your API the developer experience it deserves. Deliver a premium API experience without the premium price tag.
Visit speakeasy.com slash codestory to get started and generate your first SDK for free. So if we've moved forward from that point, right, you've gone out, you're solo, you figure out how to do the value-based pricing, you're getting clients, you're succeeding, right? And at some point, you decide to teach others how to do this. And I think...
I think I'm going to liken that to maybe like a, you know, a company roadmap or a product roadmap, right? Like, how did you decide it was time to do that? Or how did you decide it was time to take a next maturation step in the process for, you know, ditching hourly?
I think like any good product company, it was demand. It wasn't my plan at all. I was pretty well known when I was at that firm when we were still billing hourly because I wrote for the Trade Journal, which was a physical magazine at the time. They had a monthly column there. I was a tech editor. I spoke at the annual conference a few times, maybe four times.
And so when I left, everyone was like, are you crazy? What are you doing? And I told them about this sort of ditching hourly thing. And they were like, oh, yeah. And I think in their minds, they're like, he's going to come crawling back in a year. But my first year went great.
One of my colleagues wanted to put together a panel to talk about this sort of unofficial at the conference, but an unofficial thing in like a side room. And it was standing room only packed. And then I was getting invited to talk to user groups of people from the FileMaker space who had seen me, been following me from the sidelines, following what was going on.
And there was one time up in Boston, I presented to a room, maybe 40 people. And at the end, we had to leave the room because someone else was coming in after us. But I was still getting questions. So I told everyone to just email your questions to me and I'll blog about it every Monday.
And so I did that for weeks and weeks, maybe months, where people would just send in questions and then I would answer them on the blog so they can then share it with everyone. And then finally, someone just offered to pay me to coach them directly. And I was still doing my normal business, my normal software consulting business during the day.
But since I wasn't trading time for money and I was giving fixed prices, I wasn't really very busy and I was doing really well. So I had plenty of time and money to help these people out pro bono. And then people were offering to pay me to do it. It was just real natural progression.
Then eventually I collected everything I had written about the subject and published a self-published book called Hourly Billing is Nuts. That was the year when I was like, okay, I'm officially going to switch my business. I'm going to pivot from doing software consulting into doing more like business coaching or price consulting for service businesses.
We had talked before about team, right? And I think you have an interesting viewpoint on team. And I'd really like to hear how you view team. You know, team can be important for some things and not important for others. But tell me, tell me how you view team. Do you ever plan to add a team to help run things at JonathanStark.com? Tell me about that there.
I'm a soloist. I am a lone wolf personality-wise. I don't like meetings. I especially don't like recurring meetings. So no, I intend to never have employees. I'm not against other people having teams. It's just not the, it doesn't, for the kind of business I have now, it doesn't make sense to scale that way. And for even the software people I coach, that's just one approach to scaling.
It's really the only approach to scaling if you are trading time for money is to hire a bunch of bodies. But you really need to get up to 50 before you start to get the benefit. And then you've got just a completely different lifestyle. You're a manager, you're a boss, you're a leader. I never talk about leadership concepts on my daily mailing list.
And it's just about pricing and ways to scale without hiring. Pretty much all business books assume you're going to hire. So no one needs another book about how to hire and how to lead a team and how to have your engineers in harmony with each other and all of that. My approach to scaling for myself and the people I work with is to increase the altitude of involvement with your clients.
If people out there are listening, have running a SaaS or something, you probably pay a team or you have an outsource, some sort of outsource, a dev shop or something where they are writing code. They are implementing new features. They are squashing bugs. And it's the coal mining of the software business. It's the typing semicolons.
And if that's what if you're a dev shop and that's what you do, especially as a soloist, but even as a dev shop, if that's what you do and you like it and it's profitable, then great. Keep doing that. That's fine.
But your path to scaling without hiring or without growing the team would be to increase your altitude of involvement so that you are doing more high level strategic types of engagements with your clients and not so much the implementation or the execution of the plan.
And I think of it, especially in software, it's really easy to map to kind of building metaphor, physical house type of thing, where you've got these three altitudes of involvement with a client. One that most people operate at is the middle tier, but there's a bottom tier. So the bottom tier are called maintenance. So that's like a support maintenance contract, that sort of thing.
where somebody's got a software application and they just need someone to keep it from breaking down or when an OS upgrade creates a bug or something, they just need to keep working the way it's working. They're not looking for necessarily for new features. That's the bottom level.
It's the least profitable, perhaps the most predictable, but it's a very specific kind of business, the volume business. The middle tier where I would call implementation or building or execution is where you're making the new status quo so that if the maintenance level, the bottom level is maintaining the current status quo, the middle level is making a new status quo real.
It's adding a new feature. It's adding a new module. It's building another SaaS, a companion app. It's some new feature development or new product development where you're creating a new status quo, which eventually will fall into the maintenance level, but someone else can do that. And then the top level is helping the client decide what the new status quo should be.
That could be something like a CTO would do, maybe a software architect, could be a product person, senior product person. You're helping the client decide what to do next. And then you hand some sort of a blueprint or diagrams or some sort of roadmap to an implementation team at the layer below you, the altitude below you. And so you've got these three layers.
And if you want to scale up without a team, it's easiest to do it at the highest level. where you're really selling your thinking, your expertise. You have built up a reputation that people trust to not steer them wrong. So you're helping clients decrease their risk, basically, because what they're going to do after you're done is hand off some sort of a plan to a very expensive team to build it.
In many cases, they want to de-risk that, whether it's a budgetary thing or if it's some sort of hard deadline type of thing. Maybe there's a certain window of opportunity that is going to close because Amazon or OpenAI is about to come into your space. So they're like, oh...
We need to do this right away so that that middle layer where you're building this stuff, it can be very high revenue, but it's not very high profit because you have to pay all these salaries. It's really an arbitrage model where you're buying hours cheap and selling them for more.
So if you want to scale up without hiring, that middle tier, the implementation tier, to me is like a transition phase. Maybe it's what you do now, but the idea is to transition up to something a little bit more strategic and advisory so that you're selling your brains and not your hands.
You're a startup founder. Finding product market fit is probably your number one priority. But to land bigger customers, you also need security compliance. And obtaining your SOC 2 or ISO 27001 certification can open those big doors. But they take time and energy pulling you away from building and shipping. And that's where Vanta comes in.
Vanta is the all-in-one compliance solution helping startups like yours get audit ready and build a strong security foundation quickly and painlessly. How, you ask? Vanta automates the manual security tasks that slow you down, helping you streamline your audit.
And the platform connects you with trusted vCISOs to build your program, auditors to get you through audits quickly, and a marketplace for essentials like pen testing. Join over 8,000 companies, including many Y Combinator and Techstars startups who trust Vanta. Simplify compliance and get $1,000 off at vanta.com slash codestory. That's V-A-N-T-A dot com slash codestory.
This message is sponsored by QA Wolf. If slow QA processes bottleneck your software engineering team and you're releasing slower because of it, you need a solution. You need QA Wolf. QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes.
With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Drada, Autotrader, and many more, you're in good hands. Ready to ship faster with fewer bugs? Join the Wolfpack at QAwolf.com to see if they can help you squash the QA bottleneck. This message is sponsored by SnapTrade.
Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory.
This will be interesting because you've done a lot in this space, but I'm really curious about, you know, if you look across all that you've built and all that you've figured out and all that you're teaching others, what are you most proud of?
It's got to be the testimonials, like the actual transformations that I get from people that are in my Ditcherville community or on my mailing list. I got an email yesterday, it was over the weekend, about someone who was just like, oh, it's a longtime reader, first time I've replied.
I just wanted to let you know that I've been reading your list for a long time and it's just totally transformed my business. And I have a page on my site, jonathansdart.com slash testimonials. It's like, I don't know, hundreds of testimonials like that.
That's where it's at because you're like, wow, I'm definitely like maybe I charge a lot of money, but I am definitely having a difference, making a difference or helping people transform from the hourly model to something that is much, much better. Their lifestyle, client relationship is better in so many ways. You have to get it right.
But once you get it right, it's so great for your peace of mind, customer satisfaction, client satisfaction, all of that. And they generally end up working a lot less because when you only get paid when you're working, you end up working a lot because you need the money.
As your standard of living increases over time, you're probably not raising your hourly rates as fast as your lifestyle and inflation. So what ends up happening is... You're like, geez, I need more money. I have to put in more hours. And before you know it, you're 45, two kids at home and you're working 60 hours a week just to make ends meet.
And people in that situation are like, I don't see a way out of this. If I raise my rates, everyone's going to leave me. They're going to go with someone cheaper. I can't work anymore. I'm already burning out. So I can't make more money that way. And either I don't want to hire or hiring is going to be too much work. It's going to take too long to dig me out of this hole.
I'll end up working 120 hour weeks while I try to get a couple new employees spun up. So they're trapped in this, I call it the hourly trap. When they escape and they see the light and then they finally reach the light and they tell me about it, that is definitely what I'm most proud of.
Okay, so let's flip the script a little bit. Tell me about a mistake you made and how you responded to it.
The thing that everybody's scared of when they think about doing a software project for a fixed price is that there's going to be bad scope creep. I've had a few sort of fixed price things happen that seem like, from the outside, they seem like they'd be really bad, but they weren't really.
One of the things that's unusual about giving a price for a project, instead of saying, I think it'll be about this much, but I'll bill you every week as we go, and ultimately we'll find out how much it really cost. The difference with giving them a price upfront is they can pay you upfront. So you don't have to wait. You don't have to wait for that last invoice to get paid.
You don't have to any of that. They just send you a check and you get started. Two instances, one instance, someone sent me a check. The CEO hired me that I don't know if that was the title, but it was basically like the second in command and five figure check. And we get into the kickoff meeting and the CEO rolls into the room and it was immediately apparent that it was not going to work.
Like I was not going to be able to work with this person. I had to send the money back. So that was a little bit weird. It worked out fine, but it's one of those things that people are like, what happens if you get on the project and it's awful?
Another time I had taken this 100% upfront payment and I agreed to do a project with a technology that I was not familiar with, but I knew I wanted to learn it. I felt it was important for me to know this technology. Someone needed this technology in their application and they were willing to pay me to do it, knowing that I wasn't an expert, but I needed to figure it out.
After months, it just turned out that it was the wrong choice of technology for the project. And so I had worked for months and had to give the money back. So that was my own fault, but that's the kind of thing that can happen. As long as it's very rare, it's no big deal.
The one that seems the most dramatic would be one where I thought a project was going to take me about a year, but it ended up taking me about two years.
When you have the experience of working on a fixed price project, if you've never worked on a fixed price project and you've only worked on hourly, when a project goes long, longer than the client expected or certainly past your hours estimate, the client starts to become a monster.
And they should because you've demonstrated that you are poor at estimating how long it's going to take you to do something. They are now spending more money than they agreed to. If it goes really long, they're going to spend more money than it was worth to them. And they will only continue paying you due to sunk cost fallacy. If they still have to keep paying you, I've seen people get fired.
I've seen lawsuits. It can get really messy. But when the project I'm talking about went long... The client was totally fine. They didn't care. They would have been happier if it was done earlier, but 80% of the application was working. They were using it in production.
There were just some sort of senior level executive reporting features that were really tricky and I was having a real hard time with in terms of getting the performance and the features balanced so that the features that they wanted were there, but it didn't crush the performance of the entire system. It was very tricky.
But the client wasn't freaking out and I wasn't really freaking out because it wasn't full-time work. I was only working a few hours a week. And ultimately the amount of money I got divided by the hours I worked, I was still getting paid probably a hundred bucks an hour. It wasn't like a disaster. It wasn't like I was going to go out of business or anything close.
And I was still taking on other clients to do other things. I think at that point I was selling advisory retainers. So it was still, I was bringing in 10 or $20,000 a month just to answer the phone. And then it was almost like a hobby. In my other hours, I would work on these reports for this client, and it was fine. And it sounds really bad, but it wasn't bad at all. But it wasn't great.
It would have been better if I'd finished it in the year or even earlier.
Okay, so this will be super interesting to hear. What does the future look like for all that you offer? You've written many books, you've got courses, you're teaching, you have community that you've built. What does the future look like for all those things?
I am on a mission to rid the world of hourly billing, and I can't do that one person at a time with one on one coaching. I used to do one on one coaching, but I don't take on new private coaching students. I need to do it in more of a leveraged way so that more people get the message faster.
Maybe they don't benefit from my specific assistance in an ongoing way or accountability calls every other week. But writing books and giving workshops and having a community of people who have drunk the Kool-Aid and are practicing and some are more advanced, some are less advanced, they're more new. So they can help each other in a way where the more senior people can help the more junior people.
And it doesn't have to be me all the time answering every question or solving every problem. And to me, that is the way to actually make progress toward that mission, toward that vision. More of that, more books, more workshops. Of course, you talk about the future, you got to talk about AI. I've experimented with training in AI on my Q&A sessions.
So inside the community, ever since 2017, I've been doing live Q&A sessions that are recorded. I've trained in AI on seven years worth of, it's like a thousand hours of people asking me questions and me answering questions. I've got this sort of AI librarian or this AI bot thing that can do a really good job answering pretty much the way I would answer almost everything.
It's not perfect, of course, but it's the kind of thing that people can get access to. If I died tomorrow, like people would have access to it and would still give them pretty good answers.
Wherever it got the answer from, it points you to, you know, it might be a free thing, it might be a paid thing, but I'd say, oh, you know, this answer came from that book or this answer came from that video call or this answer came from that podcast episode or whatever it was. More like that.
More like trying to scale the reach of the expertise, even if that means not going as deep with any individual person. I think spreading the idea is really the most important piece.
So let's switch to you, Jonathan. What influences the way that you work? Are there any sort of methods that you follow or rituals?
So I have a really novel way of managing my time or like being productive, which a student referred to as ruthless simplicity, which I liked. Pretty much every year, basically every year in January, I set a theme for the year. Like what is going to be my theme for this year? Because as a soloist, I can't do everything.
Since I'm a software developer, I can automate a lot of things, but that takes time, too. So at the beginning of the year, I think this sort of theme and then I rough out what some experiments might be to explore that territory and see if I can, with the ultimate goal being to spread the mission to more people. My ultimate goal is to spread the hourly billing as notes mission to more people.
What am I going to do in 2025 to make that a reality? And that'll be my focus for the year. And then I just keep it really simple. I have a to-do list with recurring to-dos on it and I put daily to-dos. So like every day, like 15 or 20 to-dos that come back every single day. Got to do all these things. And it's a mix of personal and business.
100 pushups, practice my forms, send my daily email, check the Teardowns channel in the community, stuff like that. These little tiny tasks, like very much atomic level tasks that I do every day and almost like a, it's like a gardening metaphor. Plant this garden and you just tend to it and produce it. After a while, it produces a whole bit more tomatoes than you can eat.
So that's my overall, I guess my overall philosophy is to have a gardening metaphor instead of a hunting metaphor where you go out in the morning with a spear and try and come back with a buffalo. So I keep the gardening model of marketing, sales, delivery.
It requires a lot of little touches every day or every weekday to keep the ball rolling, keep the momentum going, to keep that flywheel spinning and increasingly spin faster. I don't really do time blocking. If you looked at my calendar, you'd see I maybe have one or two appointments a week and the rest of it's just open time for me to do my to-dos. So that's pretty unusual.
The ruthless part, it's very simple. I keep it very simple. It's get off a phone call. Let's say I'm going to get off this phone call with you. I'm going to look at my phone and see if there are any emergencies with my kids or anything. There's not going to be. And then I'm going to go to my calendar. I'm going to say, do I have another appointment? The answer is no.
How many hours do I have before we have to go to karate tonight? Before, okay, we'll go to my to-do list. What kind of my to-do list, what can I fit into that four hour block? And I just start cranking them off. The ruthless piece is that I don't do stuff that's nice to have. I do the, I'm a big believer in the 80-20 rule. So I don't get fancy with my website. I don't get fancy with my emails.
I don't get fancy on social media. I host a podcast called Ditching Hourly. I don't get fancy on that. There's no intro music. There are no ads. There's no edits. If there's something egregious, a fire truck goes by or something, I'll cut that out. But it's pretty much live to tape and then that's it.
Everything that I need to do, let's say I've got an SOP to record a podcast episode, every single thing on that list needs to make a case for itself. Do I really need to put ID3 tags in every MP3? No. Do I really need to put chapters and everything? No. Do I really need music? Do I need episode artwork? No, no, no, no, no. What do I need to do?
I need to give the listener a massive insight, at least one, every time they listen to me so they keep listening. I'm ruthless about that stuff. It's the kind of thing that I would hire a VA for, but I'd rather just not do it, to be honest.
Okay, Jonathan, last question. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world and can't wait to show it off to you right there on the plane. Or maybe it's the next big like mindset or the next big approach to something.
Kind of like what you did with value-based pricing and ditching hourly. What advice do you give that person having gone down this road a bit now?
I'm pretty old, so when I encounter this kind of enthusiasm, I need to take a step back and celebrate that someone is so excited about something. That's great. I love that enthusiasm. You need it. At the same time, I would be super skeptical because I've seen so many things launched to crickets. I've seen so many people just in their own head about what a great idea this is, including myself.
I've launched to crickets a bunch of times. I wouldn't give them any advice. I would ask basically in a polite way, be like, who cares? Who cares about this? Who's going to buy this? If I don't immediately see what the value proposition is of this thing, you know, it's Uber, but for dogs, it's like, it's okay. What's the market size? Where are you going to find these people?
Why aren't they going to do something cheaper? Why are they going to use your thing? I would be, it's tough for me to not switch into coach mode in a situation like this, but I would be very polite and I probably wouldn't, I probably wouldn't say anything about it to be honest.
My default position would be to ask them probing questions and chances are that's not what they, chances are they just want a cheerleader to be like, that sounds great. I'm sure it's going to be a big success.
Well, I can appreciate all of that. Well, Jonathan, thank you for being on the show today. And thank you for telling the creation story of Ditching Hourly and JonathanStark.com.
My pleasure. Thanks for having me.
And this concludes another chapter of Code Story. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.