Building a train time app, all on my own*

Observations from a first foray with Claude Code

Introducing: My Transit Dashboard

I built a thing. Specifically, a web app for creating custom MTA dashboards, so I can see ETAs for my top train stations (and bus stops) all in one place. And I did it all using Claude Code. Test it out here. Sorry in advance for the long blog, but I wanted to document this thoroughly.

Read on for:

• Why I built it – To test out AI-assisted development tools, and to help me catch the train on time.

• Process – High-level overview of my steps, from setup, planning, design, build, and iteration. In case it’s helpful to fellow beginners.

• Observations & learnings – What were Claude Code’s strengths and weaknesses? And what would I do differently for future projects?

Alright, let’s dive in 👇

Why I built it

I developed this app for two main reasons:

1. To test out AI-assisted software development tools – While I have my misgivings about AI overuse¹, I’m excited by tools that unlock new human capabilities. And every UX designer not currently under a rock knows we’re now expected to flex our AI-assisted front-end dev skills yesterday. For this project, I chose to work exclusively with Claude Code, because it’s the most ubiquitous part of every vibe coder’s stack, and I wanted to see its limitations.

So that’s why I decided to build something. But why build this?

2. I’ll actually use it – I tend to leave my apartment in a rush, frantically checking train times for my two closest stations, trying to decide: should I wait for the local, or walk farther for the express? On mta.info, it’s a multi-click mess. And while the new MTA app’s location-based approach is a massive improvement, it still lacks the single-click ease I crave.

And since I’m my own ideal test user, I knew I could count on a steady flow of feedback to drive in-build iteration. So I got to work.

Process

First, some quick notes on my setup:

Setup notes

I found this video from UI Collective instructive, but here are the basics:

• To use Claude Code, I had to buy Anthropic’s “Pro” plan, $20/month. I would still be constrained by Claude’s compute usage limit, which resets every 5 hours (unless you pay for à la carte tokens and/or the “Max” plan, which I did not).

  • I used the ‘Sonnet 4.6’ model on a ‘Medium’ effort setting. (‘Opus 4.8’ on ‘Max’ effort would work better, but consume resources faster.)

  • I installed Claude’s desktop app, rather than working in-browser.

• I needed Figma’s “Professional” plan (also $20/month) to use Figma MCP, which allows Claude to interact with Figma.

• I would eventually create free GitHub, Vercel, and Supabase accounts.

Planning

I resisted the temptation to wireframe, and began with just a prompt. I tried to be comprehensive and provide context: the why, the UX-how, and the UI-how. And I asked Claude to help me make a plan:

My first-ever query to Claude Code

Claude responded approvingly (an anthropomorphism I rolled my eyes at, but nevertheless appreciated), and proposed a plan:

Claude's initial plan, which was a bit too long for one screenshot

Claude asked clarifying questions, called out key decisions, and laid out a workflow: designs first, API set-up second; MVP build; then refine; then mobile.

The plan sounded good, and I was reassured by the explanations. When I asked for help weighing the decisions asked of me — e.g. where to host, persistence approaches, etc. — Claude obliged, delineating the trade-offs in terms (friction, latency, cost) that an unemployed UX designer could understand. After some quick deliberation, we got to work.

In the ensuing weeks, this plan proved to be more of a starting scaffold than a rigorous timeline. Like a “real” project between human collaborators, scope evolved, and we stayed flexible.

Design

Once linked to Figma, Claude set to work on its first task: turning my notes into a mock-up. I had described function and layout, and told it to reference the MTA’s official site for style.

Claude manipulated Figma in one window and explained its steps in the other. At times it seemed slow, but the eventual first pass was impressively comprehensive, and done far faster than I could have done. And it even called out key layout decisions I needed to make, like text wrapping/truncation.

Claude shares screenshots of its WIP. And at the end of this first session, delivered something comprehensive.

There was room for refinement (and I told Claude to stop congratulating itself for how “excellent,” “clean,” and “proper” the mock-up looked), but it had covered all the bases.

But Claude’s not a great designer (yet)

Still, things felt clunky, and I was constantly reminded that I was interacting with an agent that didn’t have eyes, taste, or any understanding of the real-world systems at play.

Strange layout decisions were made. Trains became buses became trains. Colors, untethered to any design system, were applied at random. New designs were layered on top of old ones, rather than replacing them. And the MTA logo png was inexplicably garbled, over and over.

Claude in Figma: Quick at first, but the last mile is a struggle

Claude’s slow manipulation of Figma became cumbersome in this last mile. And when I tried to tweak the designs myself, Claude’s unconventional auto-layout slowed me down.

But with a little patience, it got there — or, close enough that I decided it would be best to make the final refinements in build.

Development

As this was my first software engineering project, this phase kicked off with some library installations I won’t belabor. Once underway —

UI

Claude built out a rough UI, but with far more discrepancies from mock-up than I had expected — and these took a frustrating amount of back-and-forth to resolve.

Claude struggled with translating its designs to a UI, and it struggled again with understanding my feedback

Along the way, I learned that Claude doesn’t pick up everything a human would from a screenshot — so it’s best to use very specific (code-adjacent) language, if you know it.

And eventually, with patience, the core UI was built.

Data

This meant integrating the MTA’s data feeds for train times, bus times, service alerts, and elevator outages — all of which the MTA makes publicly available here, and here for buses.

There was a lot to debug in this phase: search didn’t work; alerts weren’t station-specific; B trains and Brooklyn buses were incorrectly grouped; train lines were seemingly invented from thin air.

Debugging the data layer was a bit of a chore — but switching to Plan mode helped.

By default, Claude diagnoses bugs confidently and treats them immediately, leaving the user to verify. But by switching to Plan mode, I can force Claude to assess all of the relevant code and analyze the issue holistically.

But we got there: a testable MVP was built, and I hadn’t defenestrated my laptop.

Polish, mobile, & launch

Next, all the unglamorous UI styling refinements and minor interaction patterns that are easier to catch in build, and which a design system preempts: things like component styling, search bar functionality, and empty/error states. Kudos to Claude for being an AI agent and thus incapable of growing annoyed with a fastidious, nitpicking designer.

Adjusting for mobile was quick: I’d outlined expected breakpoint behavior at the very start, so quick use of a browser-resizer confirmed its proper implementation.

With the MVP established, it was time to push it live via GitHub and Vercel, which Claude coached me through smoothly enough. It’s worth noting that Claude was unaware of changes Vercel had recently made to how its license keys work — just like a human dev can be caught unawares by 3rd party updates, to be fair.

Online and mobile, the app was ready to be put through its paces.

Testing & refinement

So far, this had all taken under a week — and very part-time, at that. In the three weeks since, I’ve used My Transit Dashboard every day I’ve taken the train or bus. This regular testing uncovered a few bugs, but mostly it provided inspiration for a raft of quality of life UX enhancements that have gradually transformed it into something quite handy.

To me, this is where the entire paradigm of the AI-assisted designer-as-developer showed the most promise: the feedback-refinement flow can now be a tight, one-person loop: no long list of feedback notes, no feedback triage prioritization meetings, no check-in chats, no off-hours. Just articulating an improvement and guiding Claude to implement it, one at a time, as they arise.

What types of improvements did I make in-build? In order:

• Collapsible service alerts – There can be a lot of active service alerts. Initially, they all stacked atop one another, but I added a summary bar with expand/collapse functionality.

  

• Click-and-drag info cards – Rearranging info cards should be easy.

• Line search – In v1, users had to search by stop name — but those aren’t always easy to remember. So now users can type “/” before a line name to list all stops.

  

• Map search – I found myself regularly cross-referencing stop selection with google maps. So it was clear that search needed an integrated map mode.

  

• Nearby stops – So far, the UX was built around optimizing travel to from familiar destinations. But what if I’m departing from somewhere new?

  

• Dashboard library – The more I used it, the more I wanted to create and save distinct dashboards — one for home, one for work, etc.

User accounts – Persistence had been browser-linked, but now I wanted to enable cross-device sync of my dashboard library — so I used Supabase for account creation. Claude was massively helpful with this more complicated setup, as well as with doing most of the lift to create the sign-up UX, a ubiquitous flow with a hidden complexities. (It even created generic privacy policy and terms of service statements without being directly prompted!)

Adding user account support sounds like a headache, but Claude made it easy

Each of these improvements required back-and-forth with Claude to get right. But each one intuitively paved the way for the next, a sort of unplanned feature roadmap accelerated by the solo workflow.

Release

I’ve only just started to share this project with friends more broadly. But early feedback was largely positive:

Thanks for the encouragement and iOS QA help, friends

The goal of this project was always to test out Claude Code, not to compete genuinely in the transit app space. But the iteration speed Claude makes possible really accelerated the path from demo to usable tool.

Observations & learnings

Here’s what I observed about Claude Code’s capabilities, plus my conclusions on how to adjust my approach next time:

1. Yes, it’s an over-eager junior dev. Claude Code’s first implementations are often buggy. Where an experienced human dev might see potential issues in advance, with Claude, it’s a “push early, fix in QA” approach. So it’s a fast first 90%, slow last 10%.
   ↳ Using ‘plan mode’ keep Claude on a tighter leash, and you can discuss technical trade-offs of key choices before acting. But as a non-engineer, this only goes so far — there will always be some QA aftermath.

2. Claude can design UI from scratch, but it probably shouldn’t. It generated credible Figma designs just from a prompt, but its components didn’t use auto-layout properly. And as that list grew, styling inconsistencies did too. If I’d given Claude a design system to work from, this wouldn’t have been an issue.
   ↳ As always: start from a component library if you can, or build one along the way. But until AI is using auto-layout properly, this is a manual task.

3. Claude crushes boilerplate work. User sign-up and login are UX flows that every app has, but no one wants to (re)design. Thankfully, LLMs have been trained on countless examples and can quickly spin up viable versions.
   ↳ If you need design assets but not design thinking, ask the AI to do it.

4. Debugging can be a slog. When something goes wrong, Claude diagnoses confidently and acts swiftly — but these fixes often fail, which frustrates and erodes user confidence.
   ↳ For big bugs, switch to ‘plan’ mode — it gets Claude to take a step back and assess the problem holistically.
   

   

   Debugging was never-ending until I switched to 'Plan' mode

5. Claude uses auto-summarization to get around context limits, but it’s lossy. A “context limit” is how many “tokens” (words, basically² ) a model can keep in memory as it performs a task. For Sonnet 4.6, that limit is 200k. When I hit it, Claude “compacted” the conversation, summarizing the preceding chat into a machine-readable preamble that it subtly appended before my next prompt. This worked well enough, but it’s inherently lossy, and implies that the longer a project, the more is forgotten.³
   ↳ For longer projects, create and maintain your own .md context file, so you decide what is essential information for all tasks. You’re the senior project manager overseeing a forgetful, over-eager dev.

   

   One of Claude’s “compaction” summaries, hidden by default.

6. LLMs reference old info. When setting up Supabase, Claude’s integration steps were for an older version. Claude adapted quickly when I pointed it out, and on its own it’s not a big deal (human devs also fail to keep up with every 3rd party tool update) except the knowledge gap recurred later, during debug. A human dev would remember that things had changed and not make the same mistake twice.
   ↳ When you encounter info that is new to your AI model, keep track of it, and consider adding it to the context file.

7. Text-only explanations aren’t always intuitive. I’m a visual learner, but LLMs are not: they’re fundamentally text-in, text-out tools. That’s why analyzing screenshots is so token-intensive: under the hood, they’re parsing those images into words. And when Claude tells me how to find an API key within Supabase’s menus, I’m doing the opposite: turning its text into mental images.
   ↳ No actionable learning for code dev, but an inherent tension to keep in mind when communicating with an AI tool: written text is our common interface, but they map to very different systems.

8. Mixed results on learning how to code. This wasn’t my main objective, and Claude was obliging with layman-friendly explanations when asked. But by obscuring the code as secondary to the chat experience, rather than centering it like in assistive IDEs like Cursor, the Claude Code UX de-centers it in my mental model of the project. And when I’m trying to finish a feature before hitting the 5-hour token limit, asking for explanations along the way began to feel wasteful.
   ↳ For my next project, I’ll plug Claude into a visual IDE like Cursor so I can observe the changing code as the primary artifact, not the chatbot conversation.

Okay. So what?

There’s clearly still room for humans in software design and development — someone to think through the use case and usability, and someone to be accountable for stability and security. But the shortening of the cycle between feedback and front-end refinement is a game-changer that can’t be waved away.

The speed from first idea to testable prototype is the paradigm-shifter. Not just for pure efficiency’s sake, but because it means that a designer can be far more independently productive in the iteration phase than ever before. And as much as I love to consider all possibilities upfront, there’s nothing like hands-on testing to help prioritize the next feature.

Yes, there are still kinks. But this new workflow means that the process will continue to gravitate toward a “ship early, fix it later” notion of efficacy.

There are cultural risks for an industry that leans into this approach heedlessly. Conventional heuristics have trained us to believe that if something looks finished, it is finished. But now a polished-looking UI is no longer a reliable signal that any thought has gone into the UX itself.

It’s up to leaders to know that the goal isn’t looking good enough, it’s being good enough. It’s up to managers to clearly delineate between prototype testing and beta launches. And it’s up to designers to know, defend, and advocate for their core value: empathetically intuiting how the thing should work. Otherwise, we’ll all just become “designer engineers” who babysit chatbots that do the UI work for us 😅

✸

1. Some studies indicate that AI use in students can inhibit cognitive development

2. Tokens are the fundamental building blocks of written language that LLMs weave their patterns of weighted interrelations around. They might be words, sub-words, punctuation marks, or something else bite-sized.

3. Interestingly, all the compaction summaries end with this bit of prompt engineering:
“If you need specific details from before compaction (like exact code snippets, error messages, or content you generated), read the full transcript at [directory]. Continue the conversation from where it left off without asking the user any further questions. Resume directly — do not acknowledge the summary, do not recap what was happening, do not preface with “I’ll continue” or similar. Pick up the last task as if the break never happened.” But if the LLM could actually read the whole transcript, what’s the point of compaction?