Something shifted recently. Not gradually — more like a threshold crossed. A new model drops, a capability unlocks, and something that felt out of reach last month becomes something anyone can build on a Tuesday. The people feeling this most aren’t engineers. They’re founders, operators, product people who’ve spent careers describing what they want to someone else who could build it.

Vibe coding is the shorthand for this: describe what you want in plain language, watch it get built in real time. I’d been skeptical. Then I had coffee (virtually) with Philip Johnson, a fellow founder, and his energy around Claude Code was the kind you can’t fake. I decided to stop watching and try it myself.

I needed a real problem. I didn’t have to think long.

The platform problem

I do the Philadelphia to New York run on Amtrak more than I’d like to admit. Over time I’ve built up what I can only call a horror reel.

The worst version: it’s a Tuesday morning, you’re at 30th Street Station — and if you know it, you know it’s not a place you linger by choice. The waiting area feels designed for throughput, not comfort. You’re not there to be there, you’re there to leave.

And your train is running 40 minutes late. You don’t know this yet. You find out when you’re already inside, through an SMS that says something like “your train has been delayed.” No context. No updated time. No explanation of whether it’s weather, a mechanical issue, or something that cascades further down the line.

The 40 minutes isn’t the problem. The not knowing is the problem. If I’d known at home, I would have grabbed a coffee, left later, planned around it. Instead I’m stuck in a station I didn’t want to be in any longer than necessary, compulsively refreshing an app that was clearly never designed for a stressed passenger who just wants one clear answer.

There’s a site called RailRat.net that rail nerds use. The data is there. But it’s not built for the person in that moment. It’s built for people who enjoy the data itself.

That gap — between having the information and actually serving the person who needs it — is the exact problem I worked on every day at Meep. Mobility data that exists but doesn’t reach the person making a decision in real time. Seeing it here, I couldn’t leave it alone.

What I built (and how it happened)

I started with a PRD. Not a vague prompt — an actual product requirements document written from the passenger’s perspective. What does someone need at the moment they’re stressed and stuck? I had a clear picture in my head and I wrote it down first.

From there it was back and forth. Claude didn’t just execute — it pushed the thinking. We’d land on something, I’d react, it would adjust. It felt less like dictating to a tool and more like a fast-moving working session with someone who never gets tired of iterating.

What came out the other side wasn’t one clean build — it was layers.

It started simple: search a station, get live data. But we kept pulling the thread. Search expanded to handle cities and train numbers, not just station codes. Then the alerts logic, which turned out to be more nuanced than I expected — not just “train is late” but how late, visualized in a way that actually helps you decide what to do next.

Alongside the core build, I was running a separate UX/UI audit in parallel with other tools, feeding recommendations back into the iteration loop. The interface you see now is a few rounds of that, not the first draft.

When I thought I was about 90% done, I shared it with my former tech co-founder from Meep. One conversation was enough to realize the alerts system wasn’t working the way it should. Not broken technically — wrong conceptually. We scrapped the approach and rebuilt that piece from scratch. That kind of feedback only comes from someone who’s seen you ship before and isn’t going to spare your feelings about it.

The last thing I added was the music and podcast section. Practically it’s simple — curated Spotify and Apple Music playlists matched to your journey length. But the reason I kept it is less practical: it’s a small gesture toward community. A way to make the experience feel like someone thought about you, not just your train.

The result is RailPulse — React front-end, Node.js back-end, live Amtrak data, completely free, no affiliation with Amtrak.

What vibe coding actually felt like

Humbling is the honest word.

The speed was real — I shipped something usable in an afternoon that would have taken me weeks to coordinate through a traditional process. But the experience wasn’t frictionless magic. You need a baseline comfort with how things work under the hood — knowing your way around a terminal, reading an error message without panicking, understanding enough to know when something is structurally wrong versus just misconfigured. It’s not coding, but it’s not nothing either.

Some features didn’t work the first time. A few required going back to the requirements, rethinking the logic, and re-entering the conversation with more precision. The quality of my next prompt determined everything when something broke. Vague description produced vague output. The more precisely I described the user’s actual emotional state — not the feature, the feeling — the better the result.

What surprised me most: I wasn’t just a passenger in the build. I was making product decisions constantly, just faster than I ever had before. The AI handled the how. The what was still entirely on me.

But overall? It’s a genuinely remarkable experience. The gap between having an idea and having a working thing has never been smaller. That’s a bigger shift than I expected to sit with.

What I actually want to know

If you’re a regular Amtrak rider — Northeast Corridor, or any route — I have one genuine question for you:

What’s the one piece of information you always wish you had at the station, and never do?

Here’s where my head is on what comes next. The goal was never to compete with existing train status tools. Amtrak has one. RailRat exists. The bet with RailPulse is narrower and more specific: is there a moment of friction — that window between “should I leave the house yet?” and “where is my train right now?” — that nobody is solving well enough to change behavior?

That’s what I’m trying to find out. Not through a survey, but through actual signals. Do people activate alerts? Do they come back? If someone sets a 15-minute delay notification and shows up at the right time because of it, that’s the answer I’m looking for. That’s the behavior that tells you whether the problem is real enough to build further on.

Early GTM here isn’t about scale. It’s about clarity — finding the people who feel this friction most acutely, putting something simple in front of them, and watching what they actually do with it. If the signal is there, the strategy follows. If it isn’t, I’ve learned something useful without overbuilding.

So this is less a launch and more a structured question. I’m not looking for validation. I’m looking for the gap I haven’t seen yet — and for the riders who feel it every time they’re standing on that platform, waiting.