Writing

Ideas are cheap. Working software isn't.

In short: an idea gets a weekend from me when I can name the person who would use it, the one thing it has to do, and how I'll know by Sunday night whether it works. If I can't write those three…

published
read time
5 min
words
971
lang
en
filed under
Product

In short: an idea gets a weekend from me when I can name the person who would use it, the one thing it has to do, and how I'll know by Sunday night whether it works. If I can't write those three lines, it goes in a note, not a repo.

I take AI ideas and turn them into things people use. That sentence sounds like the hard part is the idea. It isn't. I have more ideas in a month than I could build in a year, and so does everyone I know who writes code. The scarce thing is a weekend, and after that, the second weekend, and the tenth.

Why the idea is the cheap part

An idea costs one shower. Working software costs everything the idea left out: the data that turns out to be messy, the model you have to explain to someone who doesn't trust it, the server that falls over at two in the morning. Most of my work has been in health, where being wrong has a cost and nobody cares how clever the architecture is. That teaches you fast where the effort goes.

A demo works when I'm in the room. Software works when I'm not.

That gap is where most ideas die, and it is fine for most of them to die there. What I try to avoid is finding out on the tenth weekend instead of the first.

Three lines before I open an editor

Before an idea gets a weekend, I write three lines in my notes. If any of them is vague, the idea waits.

  1. Who uses it. A person, not a market. "My friend who reads two books a month and never knows what to pick next" is a user. "Readers" is not.
  2. The one thing it must do. One verb. Recommend, transcribe, warn, find. If I need "and" in this line, I am describing two weekends.
  3. How I'll know on Sunday. Something I can check without a dashboard. "She picks one of the three suggestions and actually starts it" is a test. "People like it" is not.

There is a fourth question I ask but don't write down: where is the risk? If the risky part is the model, I start there. If it is getting the data, I start there. If there is no risk at all, it is probably a tutorial, and I should just read one.

ideas three lines Sunday test
Not real counts, just the shape: most ideas stop at the note, a few get a weekend, and very few earn a second one.

What a weekend looks like

When an idea passes, the weekend has the same shape every time. It is boring on purpose.

  1. Friday nightWrite the three lines and one example input with the output I want. Nothing else.
  2. Saturday morningBuild the thinnest path from input to output, end to end. Ugly is fine. Hard-coded is fine.
  3. Saturday afternoonAttack the risky part. If the model can't do it, I want to know before I have built a nice UI around it.
  4. Sunday morningMake it usable by someone who isn't me: one screen, one button, clear errors.
  5. Sunday eveningPut it in front of the person from line one, watch, and decide: keep going, park it, or kill it.

The Sunday evening step is the one people skip. Without it, a weekend project turns into a hobby that eats every weekend after it, and you never find out whether it was any good.

What this looked like in practice

In 2021 I took part in a BCI game jam. Our team built a multiplayer game for people with motor disabilities, controlled by brain signals through an SSVEP paradigm. A jam forces the three lines on you: the user was someone who can't use a controller, the one thing was moving a character by looking at a flickering target, and the test was whether a player could do it in real time. It won first place, the popular vote and best SSVEP game. The idea was not why. We cut everything that wasn't the core loop and got that loop working.

In 2023 I built a voice companion for patients. The idea fits on a sticky note. The work was speech recognition that kept up with real patients, a voice that felt warm instead of robotic, and encryption and storage rules strict enough for a hospital. None of that was in the idea. All of it was in the software.

The same pattern holds for any medical pipeline that works from clinical audio. "Detect a condition from a recording" is a sentence anyone can say. Clean audio, a model you can defend, and a service that stays up are what make it real.

What kills an idea for me

  • No user I can name. If I can't think of one person, I can't run the Sunday test.
  • Data I can't get. A great model idea with no data is a paper, not a product.
  • The only interesting part is the model. If the product around it is an afterthought, nobody will use it twice.
  • I can't say why it beats what people do now. Often the honest answer is that a spreadsheet already does the job.

Killing an idea on Friday night is not a failure. It is the cheapest outcome there is. You spent an hour, not a month.

Try it on your own list

Open the note where you keep ideas. Pick the one you keep coming back to and write the three lines: who, the one verb, the Sunday test. If you can fill all three in ten minutes, block out next weekend and follow the timeline above. If you can't, you just saved yourself a weekend, and you know which line to go and find out about first.

related

Keep reading