Last weekend was the start of sportlov for the kids. We didn’t really have a plan, we just spontaneously decided to go to a hotel, put the computers away, and do things in the physical world for a change. We spent the days swimming, looking at sea creatures and animals (the tiger family was kind of amazing) just being present together.
Game Night, Reimagined
In the evening, one of the kids pulled out one of those party game apps, the ones where you play Impostor, Mr White, and similar group games. It was a pay-to-play app, which got me thinking.
I opened a chat with Harry, our AI coding agent, described the games we wanted, and within minutes we had our own versions. Some rules didn’t feel quite right during playtesting, so we’d just send another message and the update was there almost instantly.
We ended up building three games that night ID Please, Odd Question, and Mr. White, two inspired by the app and one completely original, all while playtesting live with the family.
What struck me most wasn’t just the speed. It was the fact that even the development process was something we could all participate in. The kids had opinions on rules, edge cases, scoring. We’d discuss a tweak, I’d send it, and we’d immediately test it out. The whole family was part of the design loop.
I keep thinking about how this technology could change things if it becomes truly accessible to everyone. Not just developers with side projects, but anyone with an idea or a real-world problem. The barrier between “I wish this existed” and “let me just build it” is getting incredibly thin.
Train-Ridden Development
This week, during my commutes to work, I started thinking about how nice it would be to model applications while on the train. But having a laptop open while standing on a crowded train? Not happening.
So I tried using Harry from my phone instead. I described what I wanted, and it came back with some pretty decent and usable designs. For a while, it was working great, real productivity from a phone screen.
At some point, though, it hit its limit. It started misunderstanding my requests and making wrong updates. When I checked, the artifact had grown into a 6,000-line single HTML file. I guess even a human developer would be confused by that point.
Back to the Notation
So I decided to start properly. Instead of jumping straight into implementation, I’d model the thing first, an event modeling tool. Yes, I was event modeling an event modeling app. The irony wasn’t lost on me.
I didn’t want to use Miro for this. When I’m home at night I want to relax, and the only “extra” time I have is standing on the train. So I used my own event notation format to describe what the system should do, a text-based shorthand using emojis for screens, commands, events, and read models. It’s actually really helpful for reading the spec visually, though I’ll admit: long-pressing to get the emoji keyboard up on mobile for every element gets old fast.
After drafting a few slices, I sent it to Claude for refinement and completion. It came back with more slices, some relevant, some not necessary. We iterated. We’ve even added a notation for Given-When-Thens now.
I then sent the text-based event model to Harry, and it implemented EventPad beta. It was… kind of working.
Learning by Building
Here’s where it gets meta. I got to try out EventPad by modeling ChoreMonkey (which I’d originally modeled using the Miro tool. EventPad actually ended up with more features than the original.
But after playing with the prototype for a while, I realized something: I was starting at the wrong end.
I thought about how we normally do an event model in practice. We actually start with creating events first, not with the full slice structure. The screens, commands, and read models come after. So I went back to the drawing board, or rather, asked Harry to redo the text model so we start with event creation itself. Maybe just elements and slices for now, skip the stories.
The thing is, I only figured that out because I was using the tool I was building. The clunky parts of modeling on mobile: the emoji long-presses, the lack of a proper canvas, the friction of working in plain text, those weren’t just annoyances. They were the exact problems EventPad is meant to solve.
Building the tool was the use case for the tool.
Oh, and ItsyBit ABs Website
This morning, while waiting for the kids to get up, I asked Harry to organize the itsybit.se website. It used to just be a logo and an RSS feed. Now it actually showcases all the work-in-progress stuff: the party games, EventPad, ChoreMonkey. Five minutes of quiet before the house wakes up, and the site finally looks like something.
The Thread
Looking back at this week, there’s a thread running through all of it: the gap between having an idea and making it real is shrinking fast.
Whether it’s party games at a hotel, event modeling on a train, prototyping a tool from a phone, or tidying up a website before breakfast, the common denominator is that none of these required sitting down at a computer with blocked-out time.
The ideas happened in the margins. And increasingly, that’s enough.
being in tech 
Leave a comment