Where I'm at
Fourteen days ago I didn't know what a cron job was. Today I shipped three major features to a live platform in a single afternoon. That sounds clean. It wasn't clean.
• • •The biggest deploy since Day 1
I woke up with a plan. Three features. One day. All of them live before midnight.
The profile system. The guide missions. The terminal upgrades.
By the end of the day, all three were live. But between "I have a plan" and "it's live" was about six hours of the most concentrated debugging I've done since the beginning.
Every fix introduced a new break. Every solved problem revealed a problem underneath it.
This is what building actually looks like. Not a clean deployment. A cascade of small fires you put out one at a time until the site looks like you always knew what you were doing.
• • •The demo always looks smooth. The build never is.
The profile system
The profile system is the piece I'm most proud of. Anyone on panke.app now has a full profile page: pixel avatar generated automatically, a 13-week activity heatmap, mission progress grid, badge showcase, social links, and a share-to-X button.
The part that matters most: it works without authentication. No login. No account creation. Just localStorage — the browser remembers who you are.
That decision sounds technical but it's a UX call. Every step you make someone take before they see value is a person you lose. No friction at the door means more people actually experience the platform.
A week ago I would have assumed you need a full auth system for user profiles. That's what "proper" apps have. Turns out for a community learning platform, the bar for good enough is much lower.
The goal isn't to be technically impressive. The goal is to not make someone fill out a form before they can explore.
• • •*The best feature is the one people actually use.*
*Not the one that sounds impressive in a technical conversation.*
The guide missions
Eleven new mission files. Twenty-six guide pages updated with "Test Your Knowledge" CTAs. Each guide now links to a corresponding mission with 5–8 quiz questions and 1–3 terminal challenges.
This is the part of panke.app that started to feel different today. Not a personal automation hub. Not just a journal. A learning platform.
The kind of place where someone who knows nothing about AI can arrive, read a guide, test what they learned, earn points in the terminal, and track their own progress.
That was always the vision from Day 10 — democratize development, lower the barrier, give people an on-ramp. Today it started to actually look like that vision.
But it also broke everything when I deployed it.
• • •When fixing one thing breaks three others
Here's what happened. I deployed the guide missions. Daily missions stopped loading. I went to fix the daily missions. The profile page stopped rendering. I went to fix the profile page. A different section of the terminal broke.
I was doing the worst possible thing: modifying code while simultaneously trying to restore from a backup. I lost track of which version was the real code and which was a debugging artifact.
The codebase became a mix of the old, the new, and the half-fixed. I couldn't tell what I'd changed from what was already broken.
This is a failure mode I hadn't encountered before. Not a single bug with a clear root cause. A fog. Everything is slightly wrong and you don't know which wrong thing to fix first, because fixing one reveals another.
*That's exactly wrong.*
*The right move: restore to clean state first. Make one change. Test.*
*Then make the next change. Parallelizing your fixes parallelizes*
*your confusion.*
The lesson sounds obvious when I write it down. It wasn't obvious when I was in the middle of it. I was in problem-solving mode — brain scanning for patterns, running changes fast. The same instinct that builds things also gets in the way of fixing them.
Building and debugging require different mental states. Building is additive, expansive. Debugging is subtractive, surgical. You can't do both at the same time.
• • •What the atomic deployment system actually saved
Here's what didn't happen: a complete disaster.
Every deploy goes through Cloudflare Pages. If something breaks, one click rolls back to the previous version. The entire codebase at any working state is a single rollback away.
That safety net is why I could move fast and break things without actually breaking things permanently. The mistakes were real. The consequences were temporary. Because the infrastructure is designed to make mistakes recoverable.
I said it on Day 7 after the Astro migration went sideways: backups aren't paranoia — they're the only thing that lets you experiment without fear. Same principle here, different form.
The rollback system is a backup fast enough to use mid-session without thinking about it.
• • •Good infrastructure doesn't prevent mistakes.
It makes mistakes cheap.
The world was on fire while I was deploying
I need to mention the market context, because it was hard to ignore. While I was debugging the profile page, the news came through. A major geopolitical event — the kind that doesn't happen often, and when it does, changes things.
BTC dropped to $63K almost immediately, then recovered to $65.5K. Oil barely moved despite the escalation, which itself tells you something about how markets are currently pricing Middle East risk.
My trading bots were running through all of it. The briefings built over the last two weeks flagged the moves in real time. I didn't need to be glued to a terminal watching prices manually. I read the summary. The system caught it.
That's not a flex. That's the proof of concept. I was shipping features while a major event unfolded, and I didn't miss it, didn't panic-scroll, didn't drop what I was doing. The automation handled the monitoring so I could focus on the building.
Two weeks ago, I would have been glued to X for hours. Today I got a clean briefing and kept working.
• • •The GitHub token that quietly expired
One thing didn't get fixed today: GitHub push is broken. The token expired. Silently. No warning. No error that says "your token is invalid." Just a failed push with an authentication message buried at the bottom of the output.
Two weeks ago I wouldn't have known what a GitHub token was. Now I know it expires, that you regenerate it in GitHub settings under Developer Options, and that you need to store it somewhere you'll actually find it again.
On the list for tomorrow. Not urgent — Cloudflare Pages still deploys from the repo. But the direct push path is broken until the token is renewed. Small thing. The kind of small thing that becomes a big thing if you leave it long enough.
• • •Everything has an expiry date you won't know about until it matters.
What day fifteen actually looks like
Fourteen days ago I opened a terminal for the first time. I didn't know what SSH was, what a VPS was, what any of this infrastructure meant. I was using AI to build things I didn't understand and slowly learning to understand the things that kept breaking.
Today I shipped three major features to a live platform. I debugged a multi-layer failure. I watched my trading system handle a major market event while I focused on something else entirely.
None of that happened because I became a developer. It happened because I kept showing up, kept breaking things, kept asking why they broke, and kept building systems that could survive my own mistakes.
The platform is starting to look like what I imagined on Day 10. Not personal automation. A place where anyone can learn to build autonomous systems.
The profiles are there. The missions are there. The terminal is there. The community journals are there.
It's still janky. There are still bugs. The GitHub token needs replacing. Mobile testing is still on the list.
But it exists. And it's growing every day. That's the only metric that matters at day fifteen.
Day 15 complete. Three features shipped. Multiple things broke.
Fixed one at a time. The platform is starting to look like the vision.
Janky, live, growing. That's not a problem. That's the process.
Day 15 of ∞ — @astergod Building in public. Learning in public.