Let me be upfront: the app I’m about to describe is useful for maybe three weeks out of the year. It helps you figure out when to tap a maple tree for sap. That’s it. The rest of the year it just sits there, waiting for February to roll around again. I can’t think of much else targeting such a specific, and time-limited, niche…
A year ago, I wouldn’t have built this. Not because it’s hard, but because the return on investment is laughable. A few weeks of utility for evenings of development time, if I finish it at all, is not worth it. I’d just check the weather forecast myself, squint at the overnight lows, and make a guess like I did last year. The motivation simply wouldn’t survive contact with the reality of actually sitting down to build it.
At the end of the day or on the weekend, at this point in my life, I just don’t have the time or remaining brain cycles, to work through software side projects when life’s already busy or I spent all day in meetings. But the cost of producing code has changed. And that changes which ideas I can tackle in the limited time I have available.
With many experiments, learnings, and changes to my flows over the past 6-8 months, I’ve produced more code than in the past 6 years since getting into management. Finally a lot of the ideas I’ve had can see the light of day as I can instead focus on the product/feature, secure deployments, smooth DevEx, and architecture of the thing I’d like to see. And each time through this process, whether at my computer, or now at my phone, I find points of friction I can smooth out so that next time it’s just a bit easier.
The Spark
I’d been having ongoing conversations with a family member about the impact of AI on software engineering: what’s possible now, what’s overhyped, where it’s actually headed. The kind of back-and-forth where you’re theorizing about the future but don’t have a great concrete example to point at. I’d been thinking about what simple, real app I could build to just show what’s possible instead of talking about it abstractly.
Then, sitting at dinner, talking about tapping maple trees (because it’s that time of year), the idea clicked. Last year I’d manually checked the forecast every day, trying to figure out when the freeze-thaw cycle was right for sap to flow. Lots of guessing, lots of doubt. Why not build something that does that automatically?
I pulled out my phone, opened the Claude iOS app, and started describing what I wanted using Wispr Flow for voice dictation. I gave it the problem I was trying to solve, a high-level overview of my understanding of how maple sap tapping works, and told it to do research so it could cite its sources. Then I let it work.
By the time I got home, maybe 20 minutes later, I ran npm run dev and had
a working application. It detected my location, pulled a 7-day temperature
forecast, and graded each day as poor, fair, good, or excellent based on the
freeze-thaw cycle. It had information explaining how the cycle works, how the
ratings are calculated, and a full section of sources and further reading based
on the research it had done. Not a skeleton. A real app with real content.
That was pretty eye opening. Was it perfect? Definitely not. Did I trust it yet? Nope. Did it “work” and could I build from this? Oh yeah… Let’s iterate.
Note: This wasn’t my first attempt at building from my phone. I’d hit some friction on a prior project that taught me a fair amount about the workflow, like making sure your repo has a
mainbranch before Claude tries to open PRs. I wrote up those learnings separately in Tips for Starting New Projects With Claude Code on iOS.
Getting to Production
Once I was home with the app running locally, the next step was getting it
deployed. I connected a Cloudflare Worker to my GitHub repo so that every
merge to main triggers a production deploy, with preview URLs enabled for
pull requests. There were a couple of build issues to work through, and I had
Claude move the project from vanilla JavaScript to TypeScript, which is what
I would have preferred from the start. I just hadn’t caught it during that
initial phone session because everything was happening so quickly.
Sidenote: That’s one of the trade-offs of the autonomous mode that Claude Code on iOS runs in. It’s not asking for permission as frequently as it does on desktop because it’s working in a sandboxed environment. The upside is speed: it moves fast and gets a lot done. The downside is that it might make a bunch of decisions and execute on them before you have a chance to review and steer it in a different direction. Though once you do steer it, it shifts pretty easily, so I’m not sure it’s actually a drawback so much as something to be aware of. 🤔
I was watching the output, bouncing between the Claude app and GitHub on my phone to see what commits were getting pushed. That back-and-forth between apps is the closest thing to a “review loop” you get on the phone.
One thing I made sure to do was have Claude create unit tests for the rating logic. The app was functionally showing me different ratings for different days, but I wasn’t confident it was correct until I could read through test cases. Once I could see “given this overnight low and that daytime high, the rating should be X,” I had a lot more confidence that it would work in reality.
Like a tale as old as time, good, clear unit tests, help enable an Agent to prove its work and help us humans build confidence in the underlying code.
The Iteration Loop, a Few Days Later
A few days passed. I had more ideas. Season timing estimates based on latitude, so if you haven’t had a good tapping window, you’d know when to just tap anyway before you miss the season. A map showing your location. Better error handling if location services weren’t working. Analytics and a feedback widget through PostHog so I could get basic analytics and collect feedback.
By this point, the development flow was established. Here’s what the loop looked like:
- Open Claude on my phone
- Describe the change I want
- Claude writes the code, pushes a PR to GitHub
- Cloudflare builds a preview URL within seconds
- I review the changes in the preview on my phone
- If something’s off, I go back to Claude, request changes, and it pushes to the same PR, and Cloudflare picks up the update automatically
- Merge the PR, Cloudflare deploys to production
Rinse and repeat. The whole thing, from idea to production, could happen in minutes. And because each change was isolated in its own PR with a preview deployment, I could spin up multiple Claude sessions for independent changes and review them in parallel: one adding Gitleaks scanning, another adding help docs for location service issues, a third integrating PostHog.
In this round of iteration, the only thing I needed my laptop for was setting a new secret variable in Cloudflare for the PostHog API key. Everything else was done entirely through the feedback loop between Claude on iOS, GitHub, and Cloudflare.
What Went Well
Voice-to-code is surprisingly effective for greenfield work. Describing a new application out loud, conversationally, maps well to how you’d explain a feature to a colleague. I didn’t think about file structure or naming conventions. I described the problem and the desired outcome and let Claude sort out the implementation.
The research was genuinely good. I told Claude to research maple sap tapping and cite its sources. The result was an app backed by real references: academic papers, extension programs, established guides. For something I’m still learning about myself, having that research done and integrated into the app was valuable.
The phone-to-production cycle time was genuinely fast. Once Cloudflare was wired up, making a change and seeing it live took minutes. That’s competitive with, or better than, a lot of traditional workflows where you’d context switch to a terminal, run a build, push, wait for CI, and deploy. This was somewhat aided by Claude’s sandboxed, more autonomous mode.
PR-based workflow with preview URLs gave me confidence. Every change went through a PR. Every PR got a preview deployment behind Cloudflare Access. I could see exactly what the change looked like in a real environment before merging, and share preview URLs for feedback without exposing half-finished work.
Unit tests removed the doubt. Asking Claude to write tests for the rating logic helped the project go from “this looks right” to “I’m pretty sure this is right.” Being able to read through concrete test cases grounded the whole thing.
Where There Was Friction
Greenfield setup from a phone has gotchas. Repo creation, default branches, missing config files. I covered these in detail in the companion tips post.
The autonomous mode is a double-edged sword. Claude on iOS moves fast and doesn’t ask for permission as often. That’s great for momentum but means it can make a batch of decisions before you’ve reviewed the first one. Bouncing between the Claude app and GitHub to watch commits is the workaround, but it’s not the same as the more interactive desktop experience. This is definitely a pro and a con at the same time.
Secrets management breaks the flow. Every time I needed to add a new API key or environment variable in Cloudflare, I had to go to my laptop. This happened for Pirate Weather (a Dark Sky compatible weather API) and again for PostHog. It’s a small interruption, but it breaks the autonomy of the phone-based loop.
Infrastructure setup is still a laptop task. Configuring the Cloudflare Worker, setting up the custom domain, wiring up DNS, configuring Cloudflare Access for preview environments. All of that was done on the laptop the first night. It’s not a Claude Code limitation; it’s a “managing cloud infrastructure from a phone browser” limitation.
An App That Doesn’t Really Need to Exist (But Can)
The result is Sapcast. It takes your location, pulls real forecast data, and tells you when conditions are right to tap your maple trees. It rates each day, highlights the best tapping window, estimates season timing based on your latitude, and includes educational content with cited sources. All in a beginner-friendly way.
Last year I was guessing. This year I have an app backed by research that I can check in seconds. I’m also sharing it with other people who are into tapping to get feedback. I’m not 100% confident in my own understanding of all this, so getting real-world feedback matters.
Does this app need to exist? Honestly, no. People have been tapping maple trees forever without issue. But a year ago, the effort-to-payoff ratio would have killed this idea before I finished dinner. Now, the idea survived because the cost of going from “that would be neat” to “it’s live at a URL” has dropped to the point where three weeks of utility is enough. I didn’t have to carve out a weekend. I didn’t have to weigh it against other projects competing for my limited free time. I described it out loud at dinner and had something real by the time I got home.
That shift, from “not worth building” to “why not,” is the thing I keep coming back to. It’s not about this app specifically. It’s about all the small, niche, only-useful-to-a-few-people ideas that now clear the bar.
The Phone is Just a Litmus Test
I don’t want to do all my development from my phone. That’s not the point.
Building from a phone is an extreme scenario, and extreme scenarios are useful because they amplify every point of friction. On a desktop, you can work around a snag quickly enough that you don’t even register it as friction. On a phone, there’s nowhere to hide. Every rough edge stops you cold. Each of the friction points I listed above is a small inconvenience on a desktop but a real blocker on a phone.
That’s what makes it a useful experiment. If I can smooth out friction in an environment where any friction is hostile to the development flow, removing that same friction in a more amenable environment becomes trivial.
- Template repos with sensible defaults
- Automated preview deployments
- PR-based workflows with visual review
All of that makes the desktop experience better too. The learnings transfer directly.
For me, this is a learning process I can apply back to my career. I’ve been thinking a lot about developer experience and reducing the distance between having an idea and seeing it running. The phone is just a litmus test. If the workflow holds up there, it’ll hold up anywhere.
The side benefit is that I can finally build some of the side projects I’ve been sitting on. The cost of going from idea to working software has dropped enough that even something useful for three weeks a year is worth doing. And the next time someone asks me what’s actually possible with AI and software engineering, I won’t have to theorize. I’ll just show them.