Case study
CityHenge: what happens when a non-developer takes AI coding tools seriously.
An iOS and Android app that maps sun and moon alignments down the streets of 17 Australian cities — built in two months, entirely solo, with zero prior coding experience. This is how it actually went.
I'd spent nine years watching other people build software. I wanted to know what it was actually like on the other side — and whether the AI coding hype was real. It is, and it isn't.
— Why I built this
The premise
Twice a year, the sun aligns directly down the grid streets of Manhattan — an effect nicknamed Manhattanhenge. Sydney, Melbourne, Perth, Adelaide, Canberra and a dozen other Australian cities have their own versions. Until CityHenge, there was no consumer-friendly way to know when, where, or what time to stand on the pavement to watch it happen. The app turns ephemeris data, street geometry and local time into a simple "here's where to be, when" feed.
The stack
- Mobile: React Native with Expo, delivered to both App Store and Google Play from a single codebase.
- Backend: Node.js + TypeScript services with a Postgres/PostGIS data layer for street geometry.
- Astronomy: Custom ephemeris calculations for sun and moon azimuth and altitude at every minute of every day across 17 cities.
- Content: Astro static site for the marketing page at cityhenge.com, embedded in an iframe on cameroncarmody.com for desktop.
- Infra: Self-hosted production servers — the same ones serving this site.
- Assistant: Claude Code as pair-programmer. Almost every line written in collaboration.
What Claude wrote vs. what I wrote
Almost everything was written by Claude. What I wrote was the specification, the tests, and the taste. The model can produce working code at extraordinary speed; what it can't do is decide what the product should feel like, what's worth shipping, what corners are safe to cut. Nine years of watching enterprise software get bought and sold taught me which corners those were.
The hard skill wasn't writing code. It was writing prompts that described the right behaviour, then reading diffs fast enough to catch subtle drift before it compounded. I got better at both over the two months — and I'm still improving.
The three times I nearly rage-quit
- Ephemeris edge cases. The sun doesn't actually align perfectly with any real-world street; it aligns within a tolerance band. Getting that band wide enough to include Melbourne laneways but narrow enough not to trigger on half the city took more iterations than everything else combined.
- App Store review. Apple's reviewers don't care how fast you built the app — they care about screenshot sizes, metadata consistency, and privacy manifest fields. This was the bit no AI tool could substantially help with.
- Self-hosting under real load. The first day the app made the local news, traffic spiked and my fly.io budget alarm went off at 3 a.m. Learning how production servers actually behave at the moment they're failing is a very specific kind of stressful.
What I'd tell a non-developer thinking about doing this
The barrier is no longer "can you write code." It's "can you specify what you want clearly, hold the whole system in your head, and recognise when the assistant is confidently wrong." Those are skills I'd been building for a decade without realising. If you've worked in enterprise technology, sales engineering, product, or anything adjacent to software for a living — the tools have caught up to what you already know. Use them.