There's a moment in every product's life where it stops being a thing you're building and starts being a thing you're using. Makers call it dogfooding. Investors call it product-market fit. We call it the Saturday at the zoo when we shipped a production deployment from the penguin exhibit.
This is the story of how PropelCode built PropelCode. Not as a stunt. Not as a demo. As a daily workflow, running for weeks, across zoos and playgrounds and soccer games and bedtime routines — while the product got better every single day.
It Started With a Saturday Morning Bug
We were in the car, driving to the zoo. Kids in the back seat arguing about which animal we'd see first. Phone buzzing in the cup holder. A user had reported a CSS regression — the sidebar was overflowing on tablet-width screens. Small bug. Annoying bug. The kind you want to fix immediately because it makes the product feel sloppy.
Old instinct: add it to the backlog, fix it Monday. New instinct: open PropelCode.
Opened PropelCode on the phone. Swiped to the AI chat panel. Typed: "The sidebar in PanelNavigator overflows horizontally on screens between 768px and 1024px. Add a max-width constraint and overflow-x: hidden to the sidebar container. Check the responsive breakpoints in lib/responsive-breakpoints.ts for the exact values."
The agent read the file. Found the class. Made the fix. Showed the diff: two lines changed. Reviewed it in the editor panel. Tapped approve. Swiped to Git. Staged, committed with the AI-generated message — fix: constrain sidebar max-width at tablet breakpoint to prevent horizontal overflow — and pushed.
Time: 4 minutes. We hadn't even parked yet.
That was the first time, but it wasn't the aha moment. Fixing a two-line CSS bug from your phone is useful, but it's not transformative. The aha moment came later that same day.
The Penguin Exhibit Deploy
We'd been working on a new feature all week — the container resource management UI. It lets users see their container's CPU, memory, and disk usage and resize if they need more power. The feature was done. The branch had 14 commits. It needed a final review, a merge to main, and a deploy.
At our desks, this is a 20-minute ritual. Pull up the PR. Read through every file change. Run the test suite. Merge. Watch the deploy pipeline. Verify in production. It requires focus, but it doesn't require a large screen. It requires attention, not screen real estate.
Kids were mesmerized by the penguins. We had at least ten minutes. Opened PropelCode. Switched to the feature branch. Scrolled through the diff in the Git panel — 14 commits, 8 files changed. Read the important ones: the new React component, the API endpoint, the database query. The agent had written most of it earlier in the week. We'd reviewed pieces along the way. This was the final pass.
Switched to the terminal. Ran npm test. All green. Ran npm run build. Clean compile. Merged the branch. Pushed to main. Railway auto-deployed.
The container resource management UI went to production from a bench at the penguin exhibit.
That was the aha moment. Not because the deploy was complicated — it wasn't. Because we realized we'd just done something that was supposed to be impossible. We reviewed a 14-commit feature branch, ran the test suite, merged to main, and deployed to production. From a phone. At the zoo. While our kids watched penguins.
And we didn't feel like we were doing anything heroic. It just felt... normal.
The Playground Sprint
After the zoo, we started paying attention to all the moments where we were using PropelCode to build PropelCode. It was happening constantly — in gaps of time we'd previously written off as dead.
Kids climbing, falling, climbing again. We had a 15-minute window and a clear head. Opened the AI chat: "Add a keep-alive cron job that pings active containers every 5 minutes to prevent Railway from suspending them. Use the same setInterval pattern as task-cleanup.ts. Check the billing status first — only keep-alive containers for users with positive credit balance."
The agent read the existing cron patterns, created server/keep-alive.ts, wrote the ping logic with billing checks, and added the startup call to server/index.ts. We reviewed the diff across both files. One small correction — the billing check needed to use cents, not dollars. Told the agent. It fixed it. Approved. Committed. Pushed.
An entire feature, designed and built, in the time it takes a five-year-old to get bored of a climbing structure.
Saturday morning soccer. Forty minutes of watching eight-year-olds chase a ball in a swarm. Between cheering for goals (and near-goals, and "great effort" goals), we built the pricing sync cron. The feature pulls model pricing from OpenRouter's API every four hours and updates the database so we always show accurate costs to users.
This one was more complex — it touched the schema, the API call, the cron scheduler, and the admin dashboard display. We worked in bursts. Five minutes of focused coding. Two minutes of watching the game. Five more minutes. The agent did the heavy lifting: writing the fetch logic, parsing the response, updating the Drizzle queries. We did the architecture: which fields to store, how often to sync, what to do when the API is down.
Halftime to final whistle. Feature complete. Tests passing. Pushed to main.
The Recursion Gets Weird
Here's where it gets meta. We were using PropelCode to build PropelCode's deployment pipeline. The Tauri desktop build config. The EAS Android build profile. The Expo web export script. The Railway deployment configuration. All of it, written and tested from the phone.
We pushed a commit from the phone that updated the Android build configuration. That commit triggered an EAS Build that produced an APK. We downloaded the APK on the same phone. We opened the newly built app. We used it to push the next commit. The snake was eating its own tail and somehow it tasted good.
The web deploy was even simpler. Push to main. Railway picks it up. Two minutes later, the changes are live at propelcode.app. We'd push a fix from the playground, walk to the car, open the browser on the drive home, and see the fix already live in production. Our kids had no idea why we kept grinning at our phone.
What We Learned About Phone-First Development
After weeks of building PropelCode on PropelCode, a few patterns emerged that we didn't expect:
Short sessions beat long sessions. On a laptop, you sit down for two hours and grind. On a phone, you work in 5-15 minute bursts. Surprisingly, the bursts were more productive per-minute. No context switching. No Slack. No email tab. Just the code, the agent, and the terminal. Forced focus.
The AI agent is more useful on mobile than on desktop. On a desktop, you can type fast enough that the agent feels like a convenience. On a phone, the agent is a necessity. It's the difference between a nice-to-have and a you-literally-can't-work-without-it. The phone made us build a better agent because we depended on it completely.
Code review is perfect on a phone. This surprised us most. Reading code, understanding changes, approving or rejecting diffs — none of this requires typing. It requires reading and judgment. A phone is fine for reading. Swipe through the changed files. Read the diff. Think about whether the logic is right. Tap approve or leave a comment. The input is minimal. The value is high.
You become a better architect. When typing is expensive, you think more before you type. You give the agent better instructions. You describe the architecture more clearly. You catch design issues earlier because you're forced to articulate what you want in words before any code gets written. The constraint makes you better.
The Numbers
Over a four-week stretch of primarily phone-based development:
Why This Matters
This article isn't really about us. It's about a question that every developer with a life outside of work has asked: what if I could use all that dead time?
The commute. The waiting room. The sideline. The bench at the park. The twenty minutes before the kids wake up. The fifteen minutes after they fall asleep. Those moments add up to hours every week. Hours that used to be lost because the only tool capable of real development was sitting on a desk at home.
PropelCode didn't start as a company. It started as a frustrated parent with ideas and no way to act on them. The fact that it grew into a product that can build itself — on the device it was designed for, in the moments it was designed to fill — is the most honest proof we can offer that it works.
If you've ever had a coding idea at the wrong time and wished you could act on it — that's exactly why PropelCode exists. Because the right time to code is whenever the idea strikes. And the right place is wherever you happen to be.
Even the penguin exhibit.