Building in Public Alaska-Style: Coding While Chopping Wood

I wrote 200 lines of code this morning before the sun came up. Then I went outside and split a cord of birch in minus fifteen degrees. Then I came back inside, debugged a race condition in a job queue, made lunch, and hauled water from the well because the pipes froze again.

This is what "building in public" looks like when you do it from a cabin in Alaska.

The build-in-public movement has become this polished, curated thing on X/Twitter. Daily revenue screenshots. Clean dashboards. MRR updates. "Day 47 of building my SaaS!" with a perfectly framed laptop photo and a latte.

I'm not knocking it. Transparency is good. Sharing your work is good. But my version of building in public involves chainsaw maintenance, frozen water lines, and debugging Node.js applications while wearing three layers of fleece because the wood stove needs another hour to bring the cabin above 60 degrees.

Here's what I've learned about transparency, engagement, and building software products from one of the most impractical locations on earth.

---

The Daily Routine Nobody Prepared Me For

People ask me about my daily routine like they expect some optimized productivity system. Color-coded calendars, Pomodoro timers, structured deep work blocks.

Here's the actual routine during an Alaskan winter:

5:30 AM — Wake up. The cabin is 48 degrees because the fire died at 3 AM. First task is always the same: stoke the wood stove. This isn't optional. This is survival.

5:45 AM — Coffee. I grind beans by hand because electric grinders are loud and I like the quiet. Also because when the power goes out (which happens), a hand grinder still works. This is the kind of redundancy thinking that makes me a better systems architect, honestly.

6:00 - 8:30 AM — First coding block. This is the gold. Nobody is emailing me. Nobody is on Slack. The nearest neighbor is half a mile away. I can hear my own thoughts, and it turns out that's incredibly productive.

This is when I do the hard stuff. Architectural decisions. Complex debugging. Writing code that requires holding a lot of context in my head. Two and a half hours of completely uninterrupted focus, every single day.

8:30 - 10:30 AM — Outside work. This varies by season, but in winter it's some combination of: splitting wood, clearing snow, checking the generator, hauling water if the pipes are frozen, feeding the birds (yes, I feed the birds, fight me).

This isn't wasted time. This is the most underrated productivity hack I've ever discovered, and I stumbled into it by accident.

10:30 AM - 12:00 PM — Second coding block. After two hours of physical work in cold air, my brain is completely reset. Problems that seemed impossible at 8:15 AM suddenly have obvious solutions at 10:45 AM. I'm not making this up — there's actual neuroscience behind physical exercise and cognitive function. I just happen to get my exercise from a splitting maul instead of a Peloton.

12:00 - 1:00 PM — Lunch and admin. Email, social media, responding to comments, checking analytics. The boring stuff.

1:00 - 3:30 PM — Third coding block. This is when I do the "easier" work. Writing content, reviewing pull requests, handling deployment, doing research. My deep focus is spent by afternoon.

3:30 - 5:00 PM — More outside work if needed. In summer, this is the garden. In winter, it's usually more firewood.

5:00 PM — Done. I cook dinner. I read. I do not code after 5 PM unless something is on fire (figuratively — if something is literally on fire, that's a different priority).

---

Why Physical Work Makes You a Better Developer

I know this sounds like something from a wellness influencer, and I hate that. But after three years of this routine, I'm completely convinced that mixing physical labor with knowledge work makes the knowledge work better.

Here's the practical mechanism: when I'm splitting wood, my conscious mind is focused on the swing — reading the grain, positioning the maul, not hitting my foot. But my subconscious is still chewing on whatever technical problem I left on my desk.

I can't count the number of times I've walked back inside after an hour of chopping and immediately known the answer to something I'd been stuck on. It happened last week with a particularly nasty PostgreSQL query optimization. I'd been staring at the EXPLAIN output for 40 minutes, trying different index strategies. Nothing was clicking. I went outside, split wood for an hour, came back, and immediately saw that I was joining tables in the wrong order. Fixed it in five minutes.

Cal Newport calls this "productive meditation." I call it "the wood pile method." Whatever you call it, it works.

The other benefit is that physical work gives you a hard stop. When you work from home in a normal city, work bleeds into everything. The computer is right there. You could fix just one more bug. You could ship just one more feature. The boundaries dissolve.

When you need to split wood before dark or you won't have heat, the boundaries are non-negotiable. Software problems can wait until morning. Freezing to death cannot.

---

Building in Public: My Version

The build-in-public movement is fundamentally about transparency. Show your work. Share your numbers. Let people see the process, not just the polished result.

I do this, but my version looks different from the typical indie hacker on X.

I share three things regularly:

1. Honest Revenue and Traffic Numbers

Every month, I post the real numbers for Grizzly Peak Software and AutoDetective.ai. Not just the good months — every month, including the ones where traffic dropped 30% because Google decided to reshuffle rankings for no apparent reason.

This is the part that most "build in public" practitioners get right. Numbers build credibility. When someone sees that you went from 0 to 31,000 organic visits in 8 weeks, they pay attention. When they also see that traffic dipped to 22,000 in week 10 because of an algorithm update, they trust you.

Selective transparency is just marketing. Full transparency is what actually builds an audience.

2. The Failures and Dead Ends

I talked openly about my failed Product Hunt launch. Three signups from six hours of work. I shared the exact post, the exact results, and why I think it flopped.

This is where most people chicken out. It's easy to share wins. It's uncomfortable to say, "I spent a week building a feature that nobody used and then I deleted it." But those posts consistently get more engagement than the success stories.

My most-engaged X thread ever was about a payment integration I spent four days building before realizing the API I was using was about to be deprecated. Four days of work, thrown away. The thread about it got three times more engagement than any revenue milestone post.

People don't connect with your successes. They connect with your humanity. And nothing is more human than wasting four days on something dumb.

3. The Alaskan Context

This is my unfair advantage in the build-in-public space, and I'll be honest about that. "Software developer in San Francisco builds a SaaS" is a story that's been told ten thousand times. "Software developer in a cabin in Alaska chops wood between debugging sessions" is a story people remember.

I lean into this. I post photos of my desk with the wood stove in the background. I mention when I have to pause a deployment because a moose is standing in front of the satellite dish. I talk about the generator failing during a critical database migration.

Is this "personal branding"? I guess. But it's also just my actual life. I'm not manufacturing a narrative — I'm sharing the genuine absurdity of trying to build a tech company from a location where the infrastructure actively fights you.

---

The Engagement Numbers That Surprised Me

When I started sharing the Alaskan angle, my engagement on X roughly tripled. Not because people suddenly cared about software — because they cared about the story.

Before the Alaska content: average post got 2,000-4,000 impressions. After incorporating the Alaska angle: average post gets 8,000-15,000 impressions.

The same technical insights, wrapped in a more interesting context, reach more people. That's just how human attention works.

But here's the more important thing: the quality of engagement changed. I started getting DMs from other developers who were thinking about leaving cities. People in their 40s and 50s who were burned out and wondering if there was another way to do this. Founders in rural areas who felt isolated and were glad to see someone else making it work.

That kind of connection doesn't come from posting revenue charts. It comes from being a real person with a real life that people can relate to or aspire toward.

---

The Trust Factor

Building in public generates trust, and trust converts.

When I launched my book, "Training Your Own AI Models," I didn't need to run ads. I'd been sharing the writing process for months. People watched me struggle with chapters, rewrite sections, debate whether to include certain topics. By the time the book was available, my audience felt invested in it. They'd watched it get built.

The same thing happened with the Grizzly Peak Software job board. I posted about building it — the architecture decisions, the AI classification pipeline, the moment I realized the salary data from most job APIs is basically nonexistent. When it launched, people who'd followed the build process told their networks about it.

This is the compounding effect of transparency that most people underestimate. Every honest post is a deposit in a trust account. When you eventually ask for something — buy this book, sign up for this list, check out this tool — the trust account is full enough to support the ask.

Compare this to cold advertising. You're asking strangers for trust and money simultaneously. No wonder conversion rates are terrible.

---

Practical Advice for Building in Public (From Someone Who Does It Weirdly)

If you're thinking about building in public, here's what I'd tell you:

You don't need an audience to start. I had 1,200 followers when I began. You can start with 50. The content builds the audience. Don't wait for the audience to build the content.

Share the process, not just the results. "We hit 10K users!" is a celebration. "Here's the three things we tried to get from 5K to 10K, two of which failed" is content people actually learn from and share.

Find your angle. Mine is Alaska. Yours might be that you're building while raising twins, or that you're 60 years old and learning to code, or that you're building a SaaS in an incredibly boring industry. The angle is what makes your story stick.

Be consistent but not obsessive. I post 3-4 times a week. Not every day. Consistency matters more than frequency. People who post every single day for a month and then disappear for six weeks are worse off than people who post twice a week for a year.

Don't fake the struggle. People can smell manufactured vulnerability from a mile away. If everything is genuinely going well, say that. If you're having a terrible week and questioning everything, say that too. The key word is genuine.

---

The Uncomfortable Parts Nobody Mentions

Building in public from Alaska has real downsides that I should be honest about.

Internet reliability. I have satellite internet. It's good enough for coding and deployment. It is not good enough for live streaming, video calls are often choppy, and there have been days where a heavy snowstorm knocked out connectivity entirely. I once pushed a broken commit because my connection dropped mid-push and I didn't realize only half the files made it.

Loneliness. The nearest tech meetup is in Anchorage, which is over an hour away. Most days, the only person I talk to about code is whoever responds to my posts online. I love solitude, but there's a difference between solitude and isolation, and some days the line blurs.

The physical cost. Splitting wood, hauling water, maintaining a generator, clearing snow — these take real time and real energy. On days where I need to do heavy maintenance work, I might only get four hours of coding done. In San Francisco, I'd get eight. The math is simple: I'm trading raw output for quality of life.

Seasonal depression is real. Alaska winters mean four or five hours of daylight. I've learned to manage it with vitamin D, a light therapy lamp, and the wood stove's ability to make any room feel cozy. But December and January are hard months to be productive, and I've learned to plan my project schedules around that.

---

Why I Wouldn't Trade It

Despite everything — the frozen pipes, the moose incidents, the satellite outages, the dark winters — I build better software here than I ever did in an office.

Part of it is the focus. There are no distractions here except the ones nature throws at you, and those are at least interesting.

Part of it is the perspective. When you spend half your day doing physical work that has nothing to do with technology, you come back to the keyboard with fresh eyes. Every single time.

And part of it is the story. Building in public works because people connect with real humans doing real things. And there's nothing more real than debugging a production issue while your wood stove crackles behind you and the northern lights are doing something impossible outside your window.

You don't need to move to Alaska to build in public. But you do need to find whatever it is that makes your story yours. The cabin and the wood pile are mine. Find your version of that, and the authenticity follows naturally.

The code doesn't care where you write it. But you might write it better in a place where you actually want to be.

Shane Larson is a software engineer, writer, and the founder of Grizzly Peak Software. He writes code and splits firewood from a cabin in Caswell Lakes, Alaska, where the build-in-public movement meets the build-a-fire-or-freeze movement.