Avoiding Burnout While Chasing Revenue Goals

I hit a wall in October 2024. Not a metaphorical wall — a real, physical, I-can't-get-out-of-bed wall. My hands were shaking from too much caffeine. I was waking up at 3 AM thinking about conversion rates. I'd lost fifteen pounds without trying, and not in the good way.

I was chasing a revenue number. A completely arbitrary revenue number I'd pulled out of thin air because some podcast host said that's what you needed to "make it" as an indie developer. And it was destroying me.

If you're a developer building side projects, running a micro-SaaS, or trying to turn your technical skills into independent income, this article might save you from the same mistake. Or at least help you recognize the warning signs before your body forces you to stop.

---

The Revenue Trap Nobody Talks About

Here's the dirty secret of the indie dev world: the people telling you to "just ship faster" and "10x your output" are either lying about their own mental health or they haven't hit the wall yet. Both are equally dangerous as role models.

The revenue trap works like this: you set a goal. You don't hit it. So you work harder. You still don't hit it. So you work even harder. At some point, you're working 14-hour days on your side project after putting in 8 hours at your day job, and you've convinced yourself this is temporary. Just until you hit the number.

It's never temporary.

I've been writing software for over 30 years. I've worked at startups, enterprises, and everything in between. And I can tell you with absolute certainty that sustained overwork doesn't produce better outcomes. It produces worse code, worse decisions, and eventually, a person who can't function at all.

---

What Burnout Actually Looks Like for Developers

Burnout isn't dramatic. It doesn't announce itself. It creeps in so gradually that you don't recognize it until you're already deep in the hole. Here's what it looked like for me, and what I've seen in dozens of other developers:

Stage 1: The Enthusiasm Phase Everything is exciting. You're shipping features. Users are signing up. Revenue is growing. You're checking your analytics dashboard six times a day and feeling a dopamine hit every time the numbers go up. This phase feels amazing, which is exactly what makes it dangerous.

Stage 2: The Grinding Phase The easy wins are gone. Growth has slowed. You're working harder but the results are diminishing. You start skipping things — exercise, time with family, hobbies, sleep. You tell yourself it's a temporary sacrifice. You stop enjoying the work but keep doing it because stopping feels like failure.

Stage 3: The Numbness Phase You can't concentrate. Code that used to flow naturally now takes three times as long. You're making mistakes you wouldn't have made as a junior developer. You're irritable. You've stopped caring about the product but you can't stop working on it because your identity is now wrapped up in the revenue number.

Stage 4: The Collapse Your body quits. Maybe it's insomnia. Maybe it's panic attacks. Maybe it's your hands shaking so badly you can't type. But something breaks, and it forces you to stop whether you want to or not.

I made it to Stage 4. Don't be like me.

---

The Alaska Reset

After I hit the wall, I did something drastic. I was already living in Alaska — I'd moved to a cabin in Caswell Lakes a while back — but I hadn't been actually living here. I'd been sitting in a beautiful wilderness location, staring at a laptop screen 16 hours a day, and might as well have been in a windowless office.

So I stopped. Not forever, not dramatically. I just stopped for two weeks. I hiked. I fished. I chopped wood because the firewood pile was getting low and it was getting cold. I didn't check a single analytics dashboard. I didn't push a single commit.

And here's the thing that surprised me: nothing broke. My sites kept running. The revenue didn't drop to zero. The world didn't end.

That two-week break taught me something I should have learned decades ago: the urgency is manufactured. Almost none of what we treat as emergencies in the indie dev world are actually emergencies. A bug in production? Maybe. A slight dip in weekly MRR? Not even close.

---

Building a Sustainable Revenue Practice

When I came back to work, I rebuilt my entire approach around sustainability. Not because I'm some enlightened guru — because my body literally wouldn't let me do it the old way anymore. Here's what I changed:

1. Revenue Targets Based on Needs, Not Ego

I sat down and calculated what I actually need to live. Not what would impress people on Twitter. Not what would make a good "I made $X/month" screenshot. What I actually need to pay my bills, save a reasonable amount, and live the life I want.

var calculateSustainableTarget = function(expenses) {
    var monthly = {
        housing: expenses.housing || 0,
        food: expenses.food || 0,
        utilities: expenses.utilities || 0,
        insurance: expenses.insurance || 0,
        transportation: expenses.transportation || 0,
        misc: expenses.misc || 0
    };

    var totalMonthly = Object.keys(monthly).reduce(function(sum, key) {
        return sum + monthly[key];
    }, 0);

    var withSavings = totalMonthly * 1.25; // 25% savings buffer
    var withTaxes = withSavings * 1.30; // 30% tax buffer

    return {
        monthlyTarget: Math.ceil(withTaxes),
        weeklyTarget: Math.ceil(withTaxes / 4),
        note: 'This is enough. Stop moving the goalpost.'
    };
};

That last line in the return object isn't a joke. I literally put reminders like that in my own code because I know my tendency to keep raising the bar.

2. Time Boxing, Not Output Chasing

I work on side projects for exactly four hours a day, five days a week. Twenty hours a week. No exceptions in either direction — I don't work less when I'm feeling lazy, and I don't work more when I'm feeling productive.

This felt wrong at first. When you're in the flow and shipping features, stopping after four hours feels like leaving money on the table. But here's what I discovered: those four focused hours produce more useful output than the 12-hour marathon sessions I used to do. Tired brains write bad code. Bad code creates technical debt. Technical debt creates more work. It's a vicious cycle, and the only way to break it is to stop before you're tired.

3. One Project at a Time

I used to juggle three or four projects simultaneously. AutoDetective.ai, Grizzly Peak Software, random side experiments, consulting work — all running in parallel. I told myself I was being productive. I was actually being scattered.

Now I focus on one primary project per quarter. The others run on maintenance mode. I fix critical bugs and handle essential tasks, but all creative energy goes into one thing. The result is that each project gets meaningful progress instead of all of them getting half-hearted attention.

4. Non-Negotiable Offline Time

Every day from 2 PM onward, my laptop is closed. I'm outside. I'm hiking, fishing, working on the cabin, or just sitting on the porch watching the mountains do nothing. This isn't a reward for finishing work. It's a requirement for being able to work tomorrow.

Saturday and Sunday don't exist in my work calendar. They're not "catch up" days. They're not "just a quick fix" days. They're days when I remember that I'm a human being who lives in one of the most beautiful places on earth and maybe should act like it occasionally.

---

The Counterintuitive Truth About Revenue and Rest

Here's what nobody tells you: my revenue actually increased after I cut my work hours in half.

I know that sounds like a self-help book cliche. But it's true, and the reason is straightforward. When I was working 80 hours a week on side projects, I was making bad decisions. I was building features nobody asked for. I was chasing vanity metrics. I was too exhausted to think strategically, so I defaulted to tactically — just write more code, ship more stuff, hustle harder.

When I dropped to 20 hours, I was forced to prioritize ruthlessly. Every hour had to count. So I started asking better questions: What's the one thing I can build this week that will actually move revenue? What can I stop doing entirely? Where am I spending time that produces no results?

The focused work produced better features. Better features produced happier users. Happier users produced more revenue. And I got to keep my sanity.

---

Warning Signs to Watch For

If you're in the early stages of the revenue chase, here are the warning signs I wish someone had pointed out to me:

You check analytics more than once a day. Checking revenue numbers obsessively doesn't make them go up. It just makes you anxious. I check mine once a week now. On Friday. After my work hours are done.

You can't enjoy success. You hit a milestone, and instead of celebrating, you immediately set a higher target. The goalpost moves before you've even processed the win.

Your hobbies have disappeared. You used to do things that weren't work. Now everything is either work or "resting so you can work tomorrow." That's not a life. That's a production schedule.

You're justifying it as temporary. "Just until launch." "Just until I hit $5K MRR." "Just until the end of the quarter." If you've said any of these more than once, the timeline isn't temporary. Your burnout trajectory is.

Your relationships are suffering. The people around you have stopped asking how your project is going because they know the answer is always "I'm busy." That's not drive. That's isolation.

---

A Better Framework: The Enough Number

I've started using what I call the "Enough Number." It's the revenue target at which I stop trying to grow and start trying to maintain. Not forever — just until I genuinely want to grow again from a place of excitement rather than anxiety.

My Enough Number is modest by Silicon Valley standards. It covers my expenses, lets me save, and gives me the freedom to work on things I find interesting rather than things I think will maximize revenue. When I hit it, I stop optimizing and start enjoying.

Most developers I talk to have never calculated their Enough Number. They have a "more" number — always more, never enough. That's the road to burnout, and I've walked it far enough to know where it ends.

---

What I'd Tell My Past Self

If I could go back to October 2024, standing in my cabin with shaking hands and a body running on caffeine and cortisol, I'd say this:

The revenue number doesn't matter as much as you think. Your health matters more. Your relationships matter more. The ability to sit on your porch and watch the sunset without thinking about churn rates matters more.

You're a developer. You can always build more things. But you only get one body, one mind, and one life in this cabin in Alaska. Don't waste it staring at a dashboard.

Ship good work. Set reasonable targets. Close the laptop. Go outside.

It really is that simple. We're the ones who make it complicated.

---

Shane Larson is a software engineer and writer living in Caswell Lakes, Alaska. He runs Grizzly Peak Software and AutoDetective.ai, and has been building software for over 30 years. He's currently recovering from burnout by doing less, better — and it's working.