I Built an App That's Only Useful Three Weeks a Year

Wed, 18 Feb 2026 20:00:00 -0500

How building from my phone exposed every point of friction in my workflow, and how I can make it better for all devices

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 main branch 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.

Tips for Starting New Projects With Claude Code on iOS

Wed, 18 Feb 2026 19:00:00 -0500

I’ve been experimenting with using Claude Code on iOS to build projects from my phone. It’s been a great learning experience, and I wrote about the broader experiment in I Built an App That’s Only Useful Three Weeks a Year. But before that project went smoothly, I hit some friction that’s worth sharing on its own.

Most of these tips are specific to starting greenfield projects from your phone. If you’re making changes to an existing repo that already has the right files in place, the experience is significantly smoother from the start.

Create Your Repo With a Default README

When you start a brand new project from your phone, you need a GitHub repo. The GitHub iOS app doesn’t let you create repos, so you’ll have to authenticate into GitHub in the mobile browser to do it.

Here’s the important part: have GitHub create a default README when you set up the repo. Not for the README content, but just to get a main branch.

Claude Code on iOS works in cloud-prefixed branches (starting with claude/). For reasonable security, it can’t create or edit the main branch or any other non-claude/ branch. If there’s no main branch when Claude pushes its working branch, that branch becomes the default branch of your repo. There’s no easy way to create a main branch from your phone after the fact. Not from the GitHub iOS app, not from the mobile web. It’s a mess to sort out, and Claude can’t help you fix it because of those same branch restrictions.

Set Up a CLAUDE.md Early

A brand new repo won’t have a CLAUDE.md or AGENTS.md file. On desktop, Claude Code has access to your global configuration file with your preferences for things like commit message conventions. On iOS, it doesn’t. So a new project has no context for how you like things done: commit style, language preferences, TDD, commit frequency, any of it.

On my first project from a phone, Claude defaulted to vanilla JavaScript when I would have preferred TypeScript. I just didn’t catch it because everything was moving so quickly in the autonomous mode. That’s the kind of thing a CLAUDE.md would have prevented.

Consider a Template Repo

I’m pretty confident now that the right move is to set up a template repo with sensible defaults for phone-first development:

A CLAUDE.md with your preferences (language, commit conventions, testing approach)
Basic Gitleaks workflows for secret scanning
Whatever project scaffolding makes sense for the kind of things you build

I haven’t built this yet, but it’s next on my list. The goal is to remove as much of the initial setup friction as possible so that starting a new project from my phone is as smooth as working on an existing one.

Claude Code on Grant Lucas