Colodaily: the overbuilt version is still the live one

The version of Colodaily on the App Store today is the wrong one. I know exactly what is wrong with it, I have a better version finished on my machine, and I have not uploaded it. That is an odd thing to admit in public, so this post is the explanation.

It was my first app. Everything I got wrong on it, I got wrong for the first time.

It started with a drawing book

Kamo’s How to Draw Almost Every Day is a book of small drawing prompts — one for each day of the year, each one simple enough that somebody convinced they cannot draw will still finish it.

What struck me was not the drawings. It was the structure. A prompt a day removes the hardest part of drawing, which is deciding what to draw. You do not need talent to start. You need a prompt and a reason to come back tomorrow.

A book can give you the prompt. It cannot tell you that you have shown up eleven days in a row. That gap is the app.

I did not know how to build an app

At that point I had never shipped anything to the App Store. I chose React Native and Expo because it was the shortest path I could find from nothing to something running on a phone, and then learned both from zero — navigation, gestures, the drawing canvas, local storage, builds, over-the-air updates, all of it.

I wrote the whole thing in Cursor. I want to be precise about what that did and did not do. It made the unfamiliar parts survivable: I could ask why a build was failing instead of losing an evening to it. What it did not do was tell me I was building the wrong thing, which is the mistake this post is actually about.

I overbuilt it twice

There are two different ways to overbuild something. I managed both.

Over-engineered is the technical one, and it is the one everybody warns you about. Abstractions for cases that never arrived. State management for a screen with four pieces of state. A structure sized for an app ten times bigger than the one I had.

Over-producted is the other one, and I do not think it gets discussed enough. It is shipping features because you can, not because anyone needs them. Settings nobody will open. A second way to do something that already had a way. Depth, in a product whose entire promise is draw one small thing today.

Over-engineering costs you time. Over-producting costs you the product. A drawing app for people who are sure they cannot draw should feel like a nudge. Mine felt like a tool, and tools are intimidating — which is the exact objection the app existed to remove.

What shipping taught me that building did not

Finishing the app was maybe sixty per cent of it. The rest was everything around the app, and none of it is in a tutorial:

• App Store Connect. Bundle identifiers, provisioning, privacy manifests, age ratings, review notes, and the particular way a rejection is worded.
• Screenshots. Every device size, laid out and captioned. I ended up using a dedicated screenshot tool, because doing it by hand once teaches you why those tools exist.
• Ads. Wiring up Google ads, and the app-ads.txt file that has to sit on your own domain before any of it verifies.
• Store copy. A title, a subtitle and a description that have to do their work in the two seconds somebody spends on that page.

I have written before that the last ten per cent is forty per cent of the time. I learned that here. Lume Flow only went smoothly because Colodaily went badly first.

The second version is the one I actually want

I rebuilt it around the thing that made the book work. It is cuter. It is gamified in the small ways that matter — the streak, the milestones, the calendar filling in — and it is far less of a tool. Less product, more nudge.

It is finished. It is also not on the App Store.

Why the finished version is sitting there

Because I am building Lume Flow, and I can do one thing properly at a time.

Releasing an update is not the end of the work, it is the start of a different job: reviews, crash reports, store metrics, support mail. Doing that badly for two apps is worse than doing it well for one. Colodaily has also never really been distributed — it went up, and it has been sitting there. Pushing the new version into that silence would change very little, and it would cost me attention that Lume Flow currently needs.

So it waits. Not abandoned, queued. It is the same argument as running four habits properly instead of eleven you feel guilty about: the constraint is not ambition, it is attention.

What I would tell myself at the start

• Ship the smallest honest version. Not a stripped-back version of the big idea — the least thing that still delivers the promise. For Colodaily that was one prompt, one canvas, one streak.
• Over-producting is the expensive mistake. Bad architecture slows you down. Unnecessary features change what the product is, and users feel that before you do.
• Learn the store before you finish the app. The non-code work is not admin, it is half the job. Discovering that at the end is demoralising in a way that has stopped better people than me.
• Your first app is tuition. Colodaily taught me Expo, App Store Connect, screenshots and ads. I paid for it with a version I am not proud of, and that was a fair price.

The overbuilt version is still live, and I have decided to be fine about that. It is an honest record of what I did not know yet. The better one is queued behind Lume Flow, and it will go up when I can give it the attention it deserves rather than the attention I have left over.

If you want the other half of this story — the app currently getting all of it — that is what I got wrong building Lume Flow alone.