Real-time train intelligence layer designed to reduce uncertainty for passengers
Status: Paused (post-MVP, testing phase)
Built in: ~1 day (AI-assisted)
Focus: Mobility / real-time information / AI-native prototyping
Why this problem
In transportation, the problem is rarely lack of data, it’s lack of clarity at the moment of decision.
Train systems already have real-time data, but they don’t serve the user when it matters most: the window between “should I leave?” and “where is my train right now?”.
The friction is not the delay itself.
It’s the uncertainty.
User problem
- Delays communicated too late or without context
- No clear answer to “should I leave now or wait?”
- Information exists, but is not actionable
- Existing tools optimize for data visibility, not decision-making
Example:
A 40-minute delay is manageable. Not knowing about it until you’re already at the station is not.
Thesis
There is a narrow but high-value moment in mobility where timely, clear information can change user behavior.
The opportunity is not to rebuild transport apps, but to create a decision layer that:
- surfaces the right information at the right moment
- translates raw data into actionable signals
- reduces stress in time-sensitive situations
This is the same pattern seen in broader mobility:
data exists → usability lags → behavior doesn’t change.
What I built
A lightweight application that provides real-time train visibility and delay intelligence for Amtrak users.
Core features:
- Station, city, and train-based search
- Live train status and delay visualization
- Alert system based on delay thresholds
- Simple UI focused on fast decision-making
- Optional content layer (music/podcasts) tied to journey time
Stack:
- React frontend
- Node.js backend
- Live Amtrak data integration
- Built end-to-end using AI-assisted development
Evidence
- Working MVP shipped in a single afternoon
- Full product loop: PRD → build → UX iteration → feedback → rebuild
- External validation from experienced technical operator (alerts system redesigned)
- Early user testing focused on behavior (alerts, return usage)
How I used AI / technology
RailPulse was built using AI as a real-time product development partner, not just a coding tool.
- Wrote a full PRD before building, anchoring the product in user context
- Used AI (Claude Code) to translate requirements into working product iteratively
- Ran continuous back-and-forth cycles to refine logic and UX
- Used separate AI tools for UX/UI audits and fed improvements back into the build
- Iterated rapidly by improving prompt precision based on user intent and emotional context
Key insight:
AI compressed the gap between idea and execution, but product judgment remained the bottleneck.
What I learned
- The biggest shift is speed: ideas can be tested in hours, not weeks
- AI is not a replacement for product thinking, it amplifies it
- The quality of output is directly tied to clarity of intent
- Emotional context (user stress, uncertainty) improves product decisions more than feature lists
- Feedback from experienced operators still matters, some systems need conceptual redesign, not iteration
Why I paused it
The core question was not whether the product could be built, it was whether the problem was strong enough to support a business.
- Unclear monetization path without large-scale adoption
- Narrow use case (high intensity, low frequency)
- Existing solutions already cover parts of the problem, even if imperfectly
This made it more valuable as an experiment in AI-native product development than as a standalone company.
What would need to be true to revisit it
- Clear evidence that users change behavior based on alerts
- Strong retention around specific routes or commuter segments
- A distribution channel tied to frequent travelers
- A monetization layer (B2B, partnerships, or premium utility)
Guillermo Campoamor 