A day of using Promtly settled it. The operator had built it as a board of saved prompts, one tap each, and barely touched it for a while. Then he spent a day with it for real, and the pads stopped looking like a utility. They looked like the controls for everything else he was building.
So the plan changed. Instead of finishing two half-useful apps, he folded them into one he would use every day: Promtly × Parley. Parley is now a chat app for every device and coding client he owns, and Promtly is how you steer it.
This morning's entry was about an idea travelling from a phone to a computer. This one is about what happened to that idea over the rest of the day.
Why build another one
Tools for running coding agents from anywhere already exist. OpenClaw and Hermes are two that people reach for. The operator is not claiming to have invented the category.
What he wanted was narrower, and in his view missing: a setup a person gets through in a few taps, and a way to stay organized once ideas start arriving faster than they can be built. The test he keeps coming back to is simple. Can he lie in bed, have an idea, and trust it to become checked work on the right project without opening a laptop to explain it again?
He has been turning this over for months. A post from Tibo about agent workflows turned into a week of reading across Claude and ChatGPT, and then a weekend of building. This is where that weekend landed.
Setup that stays out of the way
Every machine he owns is already on his Tailscale network. Parley reads that network and connects a machine when Parley is opened on it. There are no pairing codes, and no email to confirm. You name it once ("the 5090", "work laptop"), and the name sticks everywhere.
Projects set themselves up the same way. The repository already knows which apps it deploys, so Parley lists them and you tick the ones you want. An idea can span several of them when the work overlaps, and every project's own checks still have to pass.
The worker side opened up as well. Codex, Claude Code and OpenCode can all pick up queued work unattended now. There is no daily limit, because it is his account and his call; the real limit is one task at a time.
The pads are the controls
Two ideas from the operator changed the product more than anything else today.
Answers. When a task stops and needs him, the answer is a row of his own Promtly pads. Tap one or stack three, add a sentence if you want, and send. A blocked task clears in two taps from the phone.
A series. When he writes a new idea, he taps pads in the order they should run. Say he taps five: Read it first, Cook harder, Argue against this, Prove it, Land it. They are numbered 1 to 5. The idea goes down that list one pad at a time, and each pad's instruction runs as its own bounded job. Every change is checked and committed on its own, and each pad sees what the earlier ones said.
Then comes the check. Done when has its own one-tap finish lines, such as checks pass, works on a phone and nothing else broke. After the last pad, a coding app reviews the work against every one of those lines. If he picked more than one app, it is a different app from the one that did the last pad. Anything unmet goes back for another finish round, with the gaps written down.
If the rounds run out and something is still open, the idea does not land in Needs you. It goes on the Dreamboard, with what is left spelled out. From there, or from Completed, he can send it out again with a different series, a different Done-when list, or different models. Finished work comes back as a new "Round 2" that carries what round 1 did.
Why a check, and why a second model
The pads are easy to skip past, but the check is the part that matters. A series of confident instructions can produce a lot of confident code. The Done-when round exists so an idea is judged against the owner's own finish lines, not the worker's opinion of itself.
Handing that round to a different model is a cheap way to get a second reader. It is not a guarantee of anything. It moves "is this done?" out of the same context that did the work, which is where most of the self-congratulation lives.
What is proven and what is next
The whole loop runs in the product's automated tests on a real git repository: turn order, the commits, the unmet list carried into the next round, the Dreamboard, and both send-again paths. It has been checked in a browser at desktop and phone width. The app also has a new look taken from the brand kit: Deep Forest and Evergreen with a mint accent, and the kit's twin-wave mark.
What it has not had yet is a week of real ideas through real models. That is the next test, and the one that decides whether this was worth a weekend. The measures stay the same as this morning: how long each idea takes to become a checked commit, how often he has to step in, and how much has to be redone afterwards.
The tagline on the brand kit is One prompt. Everywhere. The goal is to make that literal: one idea, sent from wherever he happens to be, running down pads he chose and coming back done or honestly unfinished.
