I started Kore last spring hoping I could ship something on my own — no team, no fundraising, just nights between lectures. Almost nothing went the way I sketched on day one, and I would do it again tomorrow.

The seed

Kore began as a Sunday-night frustration. I was juggling three side projects and a course load, and I could not keep a single source of truth for what I owed each context.

So I gave myself one constraint: if it took longer than ninety seconds to capture a thought, the tool had failed.

Months one to three: the wrong stack

I started native-first and had a beautiful capture screen with exactly zero users, including me. The friction was that I lived on three machines and a phone.

I deleted the iOS project on a Sunday in May and restarted with Next.js, Prisma, and Postgres. Within four days I had a worse-looking version that I actually used.

Build the version you will use on a Tuesday morning, not the version you will demo on a Friday.

What worked

Three habits did most of the heavy lifting:

1. Write the smallest version of the idea before any code — a paragraph in plain English, dated.
2. Keep a daily build log: what I touched, what I learned, what surprised me.
3. Protect one night a week for reading other people’s source.

What I broke

Database migrations. Three times. Each time I learned the same lesson — write the rollback first — and ignored it the next month. The fourth time I bought myself a twelve-line script that refuses to run a migration without a tested rollback.

Two threads, not three

I also broke my own attention by running a landing page and a backend rewrite in parallel. Now a single rule is taped above my desk: two threads, not three.

Where Kore is now

It is a small thing — maybe a hundred and fifty people use it. The capture screen still loads in under half a second, and that is the number I am proudest of. Ninety seconds or it is broken. See you in the build log.