This morning I played TopGolf with a group of dads.
It was great. Exactly the kind of thing you say you're going to do more of and then don't, because the logistics of coordinating five adults with jobs and kids and conflicting schedules is somehow harder than it should be. We spent more time in a group text arguing about when and where than we spent actually planning anything.
By the time we were walking out, someone said "we should do this again soon." And immediately the thread lit back up. When are you free. What about this place. I can't do weekends in June. The usual.
I got home and sat down and built a tool to solve it.
Four hours later, SORTED was live.
Here is what "live" actually means, because I want to be precise about it:
The gap between "this is annoying" and "there is now a tool that handles this" used to be measured in weeks. Today it was an afternoon.
I also want to be honest about the friction, because the clean version of this story is misleading.
The first deploy hit a CORS error. The API blocks direct browser calls from non-sandboxed origins — I knew this, had planned for it, and still shipped the first version without the required header. One fix, one push.
The proxy server took three attempts to get into GitHub. The token powering the GitHub connector had been stored under the wrong variable name the whole time. GITHUB_TOKEN instead of GITHUB_PERSONAL_ACCESS_TOKEN. The connector was unauthenticated for weeks and nothing surfaced it, because the repos it needed had been set up through other means. Once the variable name was corrected, everything pushed immediately.
The design got thrown out twice. The first version was dark and technical and looked too much like everything else I build. The third version landed: white base, thick black borders, electric orange. Deliberately nothing like anything in the existing stack.
None of this derailed the build. All of it is normal. The point is that "four hours" includes real friction — not a highlight reel.
SORTED is not a product. There is no revenue path I am pursuing with it. It lives at neverstill.llc/labs, which is where Meridian puts things built for the joy of building them and the signal they send.
The rule for Labs projects is simple: the frontend is always public, MIT licensed, zero secrets. The backend stays private or is documented as self-hostable. Anyone who forks it brings their own API key. Nothing from the Meridian stack ends up in a public repo.
The other rule is equally simple: no maintenance obligation. If something is interesting, build it. If it stops being interesting, let it sit. The value is in the building and the demonstration, not the upkeep.
The thing I keep coming back to is the nature of the constraint shift.
For most of the history of software, the bottleneck was execution. You had more ideas than time or capability to build them. Ideas were cheap; building was expensive. So you filtered ruthlessly on what was worth pursuing, because building cost so much.
That is changing. Not uniformly, not perfectly, but directionally and fast. When a genuinely annoying problem from this morning becomes a working tool by afternoon, the execution constraint has loosened significantly. What tightens in its place is judgment: which problems are real, which things deserve to exist, which ideas are actually worth the attention.
The logistics of getting five dads to a TopGolf on the same Sunday are, it turns out, a solvable problem.
The next idea is already in the queue.