Building Publicly in Harsh Winters: Tools That Keep Me Productive
Last January, the temperature at my cabin in Caswell Lakes hit negative 42 degrees Fahrenheit. The diesel generator ran nonstop. My Starlink dish had so...
Last January, the temperature at my cabin in Caswell Lakes hit negative 42 degrees Fahrenheit. The diesel generator ran nonstop. My Starlink dish had so much ice on it that the built-in heater couldn't keep up, and I lost internet for six hours. During those six hours, I shipped a feature for AutoDetective.ai, wrote half an article, and debugged a payment integration — all offline.
That's not a flex. That's survival. When you build software from a cabin in interior Alaska, you either develop a toolchain that works in hostile conditions, or you stop building. I chose the toolchain.
The Mt. Gox Collapse: Bitcoin's First Crisis
How Mt. Gox went from a Magic: The Gathering site to the world's largest Bitcoin exchange—then lost 850,000 BTC and triggered crypto's first existential crisis.
Learn MoreI've been building publicly — sharing progress, writing about what I'm working on, and shipping in the open — for the better part of two years now. I've done it through power outages, frozen pipes, 18-hour winter nights, and internet connectivity that would make a 1990s dial-up modem look reliable. Here's what I've learned about staying productive when the environment is actively working against you.
Why Build Publicly at All?
Before I get into tools, I should explain why someone living in a remote Alaskan cabin bothers with building publicly in the first place.
The short answer: accountability. When I worked at large companies in the lower 48, I had managers and standups and sprint reviews to keep me honest. Up here, I have two dogs and a wood stove. Neither cares about my deployment schedule.
Building publicly — writing about what I'm working on, sharing progress on Grizzly Peak Software, posting about features I'm shipping — creates external pressure that replaces the accountability structures I left behind. It's not about followers or engagement metrics. It's about having made a public statement that I'm building X, which makes it psychologically harder to abandon X when it gets hard or boring.
The longer answer: it drives real business. Every article I write for grizzlypeaksoftware.com is a long-term SEO asset. People find my technical articles through Google, some of them click through to my book or my other projects, and a small percentage become customers. That flywheel doesn't spin if I'm building in silence.
But building publicly requires consistency, and consistency requires tools that don't break when your environment tries to break everything.
The Connectivity Problem (And How I Solved It)
My internet is Starlink. On a good day, I get 150 Mbps down and 15 up. On a bad day — which in winter means any day with heavy snowfall, ice buildup on the dish, or extreme cold affecting the electronics — I get intermittent connectivity or nothing at all.
The first winter up here, I tried to work the way I'd always worked: everything in the browser. VS Code in the browser through GitHub Codespaces. Notion for notes. Google Docs for writing. Contentful's web dashboard for CMS management. Every single one of these tools became useless the moment my connection dropped.
So I moved everything local.
Editor: VS Code desktop with all extensions installed locally. No Codespaces, no remote development. My projects live on an NVMe drive in my machine. I use Git for version control and push when I have connectivity — but I can go days without pushing and lose nothing.
Writing: I write everything in Markdown in plain text files. No Notion, no Google Docs, no web-based editors. My articles start as .md files in a local directory. I use a simple Node.js script to preview them:
var http = require("http");
var fs = require("fs");
var showdown = require("showdown");
var converter = new showdown.Converter();
var port = 3333;
http.createServer(function(req, res) {
var filePath = req.url === "/" ? "./current-draft.md" : "." + req.url;
if (filePath.endsWith(".md")) {
var markdown = fs.readFileSync(filePath, "utf8");
var html = converter.makeHtml(markdown);
var page = "<html><head><style>"
+ "body { max-width: 720px; margin: 40px auto; padding: 0 20px; "
+ "font-family: Georgia, serif; line-height: 1.7; }"
+ "code { background: #f4f4f4; padding: 2px 6px; }"
+ "pre code { display: block; padding: 16px; overflow-x: auto; }"
+ "</style></head><body>" + html + "</body></html>";
res.writeHead(200, { "Content-Type": "text/html" });
res.end(page);
} else {
res.writeHead(404);
res.end("Not found");
}
}).listen(port, function() {
console.log("Preview server running on http://localhost:" + port);
});
Fifteen lines of code and I have a live preview server that works whether or not Elon Musk's satellites can see through the cloud cover.
Notes and task tracking: A plain text file called TODO.md in each project root. I tried Trello, Jira, Linear, Todoist — they all require internet to be useful. A text file doesn't. When I finish a task, I move it from the "doing" section to the "done" section. Revolutionary stuff.
The Power Problem
Interior Alaska gets about five hours of daylight in December. That's not a metaphor — the sun comes up around 10 AM and sets around 3 PM. My cabin runs on a combination of solar panels (useless in winter) and a diesel generator.
The generator is reliable but not infallible. I've had it go down twice in the last two winters. Once because the fuel line froze. Once because I made the amateur mistake of not keeping the battery tender connected during a week-long trip to Anchorage. When the generator dies, I have a battery bank that gives me about four hours of laptop power if I'm conservative.
Four hours isn't a lot. But it's enough if your tools are efficient.
Lightweight processes: I don't run Docker locally in winter unless I absolutely have to. Docker on my MacBook Pro chews through battery like nothing else. Instead, I run Node directly, use SQLite for local development databases, and only spin up the full stack when I'm on generator power.
Offline Git: I commit constantly. Small, frequent commits. If my machine dies, I lose at most 20 minutes of work. When connectivity comes back, I push everything to GitHub in one batch.
// deploy-batch.js — pushes all local repos that have unpushed commits
var execSync = require("child_process").execSync;
var fs = require("fs");
var path = require("path");
var projectsDir = "/Users/shane/projects";
var dirs = fs.readdirSync(projectsDir);
dirs.forEach(function(dir) {
var fullPath = path.join(projectsDir, dir);
var gitPath = path.join(fullPath, ".git");
if (!fs.existsSync(gitPath)) return;
try {
var status = execSync("git -C " + fullPath + " status --porcelain").toString();
if (status.trim().length > 0) {
console.log("Uncommitted changes in " + dir + ", skipping");
return;
}
var unpushed = execSync(
"git -C " + fullPath + " log origin/master..HEAD --oneline 2>/dev/null"
).toString();
if (unpushed.trim().length > 0) {
console.log("Pushing " + dir + " (" + unpushed.trim().split("\n").length + " commits)");
execSync("git -C " + fullPath + " push origin master", { stdio: "inherit" });
}
} catch (err) {
console.error("Error processing " + dir + ": " + err.message);
}
});
I run this script whenever my internet comes back. It finds every local repo with unpushed commits and pushes them all. Takes about 30 seconds and means I never have to remember which projects I was working on during an outage.
The Isolation Problem
This one doesn't have a clean technical solution. When you work remotely from a cabin that's 30 miles from the nearest town, and the nearest town has 400 people, you don't have a lot of casual professional interaction.
Building publicly helps here too. Writing articles is a form of conversation, even if it's asynchronous and one-directional. When someone emails me about an article they found useful, or when I see traffic spikes on a tutorial I wrote, it creates a connection to the broader engineering community that I'd otherwise lack.
But the real tool for isolation is scheduling. I keep rigid working hours — 7 AM to 3 PM, six days a week. That sounds old-fashioned, and it is. But when your workspace and your living space are the same 800-square-foot cabin, boundaries matter. Without them, work bleeds into evening, evening bleeds into weekend, and suddenly you haven't gone outside in four days and you're arguing with yourself about database schema design at midnight.
The schedule also helps with the darkness. In December, I start work in the dark and I finish work in the dark. But by keeping consistent hours, my body clock stays anchored to something, even if that something isn't sunlight.
The Tools That Actually Matter
After two winters of iterating on my setup, here's the stack that works:
For code:
- VS Code (local, no remote/cloud features)
- Node.js runtime
- Git (local commits, batch push)
- SQLite for local dev databases
- A simple HTTP server for testing (no ngrok, no tunnels)
For writing:
- Markdown files in a directory
- Custom preview server (shown above)
- Showdown for Markdown-to-HTML conversion
- A
content-creationfolder with a manifest that tracks article status
For communication:
- Email (POP3 downloaded locally, can read and draft offline)
- A weekly "progress update" I post publicly
- GitHub Issues for project-specific conversations
For system reliability:
- UPS battery backup (4 hours)
- Diesel generator with auto-start
- Starlink with heated dish mount
- USB-C laptop charger that runs from 12V battery bank
- External NVMe drive with nightly rsync backup
For mental health:
- Fixed working hours
- A dog that demands walks regardless of temperature
- A woodworking shop in the garage for non-screen breaks
That last category isn't a joke. Productivity tools don't matter if you burn out. And burnout hits different when the nearest coffee shop is a 45-minute drive on roads that might be covered in ice.
What I'd Tell Someone Considering This
People email me asking how I work from Alaska. Usually they're fantasizing about leaving tech hubs for somewhere remote and dramatic. My honest answer: it's wonderful and it's hard, and the hard parts are the ones nobody talks about.
The wonderful parts: I can see the northern lights from my desk. I haven't been in traffic in two years. My commute is walking from the bedroom to the office corner. The silence — real silence, not the fake silence of noise-canceling headphones in an open office — is extraordinary for deep work.
The hard parts: frozen pipes, generator maintenance, the weight of darkness in deep winter, the loneliness, the six-hour round trip for hardware store runs, and the constant low-grade anxiety about what happens if my internet dies during a client call or a critical deploy.
Building publicly doesn't solve the hard parts. But it creates structure and accountability that make them manageable. When I wake up at 7 AM in December and it's pitch black and negative 30 outside, the thing that gets me to my desk isn't discipline — it's the fact that I said I'd ship something this week, publicly, and people are watching.
The tools I use are boring. Markdown files, Node.js scripts, Git, a battery backup. Nothing on that list is exciting or innovative. But boring tools are reliable tools, and reliable tools are the only tools that matter when the temperature drops to negative 42 and the satellite dish is covered in ice and you've got four hours of battery power to ship a feature.
Build with what works. Build publicly so you can't quit. And if you're doing it from a frozen cabin in Alaska, make sure your generator has fuel.
Shane Larson is the founder of Grizzly Peak Software, writing code and articles from a cabin in Caswell Lakes, Alaska. After 30+ years building software in environments ranging from Fortune 500 offices to a one-room cabin at negative 40, he's learned that the best productivity system is the one that still works when everything else fails. His latest book covers training and fine-tuning large language models.
