There’s a category of development work that nobody notices when it’s done well. No feature announcement, no changelog entry, no release note. Just a feeling — a quietness — that the app is responding the way you expected before you even finished expecting it.
That’s what this past stretch of Cozy Reader has been about.
What we actually shipped
On paper, none of it sounds like much. But in practice, this is the stuff that separates a prototype from something you actually want to use every day.
Drag-to-reorder on the library grid. Long press a blog, feel a haptic bump, drag it where you want it. Release, and it stays. The order is written to SQLite immediately, survives a restart, and the new position is optimistic — the grid moves before the database confirms, so there’s no visual snap-back. Getting here took three separate detours through React Native’s gesture system, a dependency conflict between react-native-reanimated v4 and Expo Go’s bundled native modules, and eventually a migration to a full development build. None of that is visible to the user. What they see is: I pressed it, it moved.
Press feedback on every interactive card. The Continue Reading card and every blog icon now dim to 75% opacity on touch. It sounds trivial. But without it, the app felt unresponsive — you tap and nothing happens for a half-second until the next screen slides in. With it, the interface feels like it’s alive and listening. We considered a coloured border flash, briefly landed on coral, then caught ourselves: coral is close enough to red that it would read as a warning state. Opacity is colour-neutral. It just says “I felt that.”
Blog colour on Continue Reading. When you’re mid-way through a post from Quiet Builds — which has a teal brand colour — the “CONTINUE READING” label and progress bar now render in that teal. Switch to a deep blue WordPress blog and they shift to match. The colour is already extracted and stored from the blog’s favicon when you first add it, so there’s no extra network request. It’s just using data that was already there. Off by default? No. On by default. You can toggle it off in Settings if you prefer consistency, but the personalised version is the better experience, and most people will never open that setting.
Icon refresh without sync overhead. Blog icons are cached when you add a blog and never touched again. If a blog redesigns, you’d be stuck with the old logo forever. The obvious fix — re-fetch the site HTML on every pull-to-refresh — was implemented and then immediately reverted. That’s one extra HTTP request per blog per sync, fetching the full homepage just to check a favicon. With ten blogs that’s ten extra requests every time you pull down. Instead there’s now a “Refresh icon” option in the blog’s action sheet. Manual, deliberate, costs nothing until you need it.
Haptic feedback on Add Blog. One line. Light impact. Done.
Small decisions, every one of them. But the cumulative effect is an app that feels considered.
What would this have cost in real human hours?
I asked Claude to estimate the full project scope in developer hours. Not just this stretch — the whole thing, from the initial database schema through the API integrations (WordPress REST, WordPress.com, RSS/Atom), the reader, the sync service, the theming system, the settings, all of it.
The answer was: approximately 280–350 hours for a junior developer, and 100–140 hours for a senior.
That’s seven to nine weeks of full-time work at junior pace. Two and a half to three and a half weeks for a senior.
The gap is instructive. It isn’t mostly about typing speed or syntax knowledge. A junior developer and a senior developer both know how to write a SQLite migration or a Pressable component. The difference is pattern recognition — specifically, knowing which rabbit holes to avoid before you fall into them.
The reanimated dependency saga is a perfect example. Expo Go bundles a specific version of React Native Reanimated into its app binary. When you install a library that requires Reanimated as a peer dependency, npm resolves the latest version — which in our case was v4, which had split its worklets functionality into a separate react-native-worklets package that Expo Go had never heard of. The build failed. We installed worklets. It still failed. We switched to a development build. It still failed. We downgraded to Reanimated v3. It finally worked.
A senior developer who has navigated the Expo ecosystem before would have reached for Reanimated v3 immediately, knowing that v4 is too new for Expo Go. Total time: twenty minutes. A junior developer might spend two days on the same problem, working through each failure without the background knowledge to predict the next one.
That is not a criticism of junior developers. It is just how expertise works. You earn the shortcuts by walking the long way round first.
What AI actually changed
The honest version of this is not “AI did the work.” I still made every decision — what to build, what to cut, what the right trade-off was between sync overhead and icon freshness, whether the default should be on or off. Those judgements did not come from Claude. They came from thinking about the product.
What changed was the cost of implementation. When the friction of writing the code drops away, you spend more time deciding what to build and less time fighting how to build it. The drag-to-reorder feature probably would have taken me a weekend of research before I even wrote a line. Here it was a conversation. The gesture system conflicts, the dependency issues, the fallback approaches — all of it happened in dialogue rather than in isolation.
There’s a useful analogy in woodworking. A hand tool craftsperson and a power tool craftsperson both need to understand wood — grain direction, joinery, finish. The power tools don’t replace that knowledge. They just mean you spend your time on the knowledge rather than on the physical effort. The person who picks up a router without understanding what it’s doing will produce worse work faster.
The same is true here. AI pair programming rewards people who already know what good software feels like. It amplifies taste. It doesn’t install it.
The moral, briefly
The hours matter less than what you do with them. A 300-hour project compressed into a few weeks of evenings and conversations is still a 300-hour project’s worth of thinking. You don’t get to skip the decisions. You just get to make them faster, with better information, and without the implementation work drowning out the design work.
Build the thing. Sweat the details. Know why you’re making each choice. The tool doesn’t think for you — it just clears the desk so you can.
Three hundred hours shrunk to weeks, the gap between the want and build. Not shortcuts taken, just less friction — the same good taste, more quickly filled. Junior walks the long way round, senior skips the holes they know. AI clears the desk for both of them, but only you decide which way to go.
Leave a Reply