journal/004.md
~/sonya-birch/journal – zsh
sonya@berlin:~/journal$ cat 004.md
journal #004 · 2026.06.04

Deciding what to actually build

I've been sitting on a question for a while. Not how to build, but what. The plan said build a ladder of small tools, each harder than the last. Easy to write. Then you open an empty folder and have to pick something real.

I work for an event venue. We make a lot of flyers, and every one starts the same way: someone reads the event details off a page or an email and retypes them into a design. The date, the time, the line-up, the ticket link. Over and over, by hand.

I'd already automated a piece of this at work, the gut-feeling way. A script that pulls event info and drafts the monthly flyer text, built in Google Apps Script because that's what I knew. It worked, mostly. But "mostly" is doing a lot of lifting in that sentence. Every so often it would get something wrong, and we'd only catch it on the proof, right before it went to print. I never really knew how often it slipped, because I never had a way to check. I just fixed whatever we spotted in time.

So this time I wanted to build it properly. A flyer builder: you give it a messy event page, it pulls out the details that matter, and those feed into the flyer. The interesting half, the part I wanted to learn, is the pulling-out: getting a model to read something written for humans and hand back clean, structured fields I can actually use.

Here's how it works, concretely, so this isn't just hand-waving. It's a small Node project that calls the Claude API. I give it an event page, it sends the text to the model with a fixed list of fields I want back, and it returns them as structured data: name, date, time, venue, price, ticket link. Right now I run it from the command line and the fields print out. Plain, but real.

I actually built the same thing twice, once in Apps Script and once in Node, so I could compare them and understand what each was doing rather than just copying a pattern. That turned out to be one of the more useful things I did.

And then I got the first version running. Fed it a page, it returned the fields. The old me would have called that done and moved on.

But I'd been here before, with the old script that worked "mostly" and slipped when I wasn't looking. Returning something is not the same as returning the right thing. So before I trusted it, I wanted a way to actually know whether it worked, not just whether it ran.

Good thing too. The first real page I pointed it at had a surprise waiting that I didn't spot for a while, and it taught me more than getting it working did. But that's the next entry.

// designed & coded by Sonya Birch© 2026