Patch Pay: Your Switchboard for Modern Money Movement

Patch Pay: Dead Technology, Modern SolutionsA 1927 switchboard interface for optimizing money transfers. Find the cheapest, fastest route between your accounts - putting you in control of your cash.

Comment

Patch Pay: Your Switchboard for Modern Money Movement

Inspiration

I've always been frustrated by how expensive and slow it is to move money between my own accounts. Banks charge fees, payment apps have limits, and I never know if I'm choosing the cheapest or fastest option. I'd think "there has to be a better way to figure this out."

The vintage switchboard aesthetic came from a conversation with a friend about moving money. We joked about how we felt like telephone operators, who manually connected calls by plugging cables, when we have to move money between accounts. We were trying to find the best way to connect our cash from one account to another. We were manually "routing" transfers. That metaphor became the heart of the project: using dead technology to solve a modern problem. I wanted the user to be in the position of the telephone operator because far too often, some surprise fee or delay in a transfer gets in the way of money movement. I thought, why not just make it super easy for users to see all of their options, fees and transfers included. I went with a 1927 switchboard's functionally which matches with the control room theme (and second way to move money) based on another 1927 theme: I was also inspired by "Metropolis", a 1927 German expressionist science-fiction silent film directed by Fritz Lang and written by Thea von Harbou in collaboration with Lang. This film gets at the heart of the tension between humans, machines, control, and capitalism. The film features a master "control room" that the workers must live by. I wanted this project to put people using banks in control of their cash.

As someone relatively new to coding, I also wanted to challenge myself to build something with real algorithmic complexity. The routing optimization problem felt like the perfect challenge. I did not achieve all of my goals because I had to dedicate a lot of time to things like simply setting up git on my device.

What it does

Patch Pay finds the optimal way to move money between your accounts. You tell it:

  1. How much you need to transfer
  2. Where it needs to go
  3. When it needs to arrive (optional)

The algorithm analyzes all your accounts and finds every possible route, then calculates:

Cost: Total fees for each path Speed: When the money will actually arrive Risk: How reliable and complex each route is

You get three options:

💰 Cheapest: Lowest fees (might be slower) ⚡ Fastest: Quickest arrival (might cost more) ⭐ Recommended: Best balance of cost, speed, and risk

The interface is inspired by a vintage 1920s industrial switchboard—color accents, mechanical sounds, indicator lights—making financial routing feel tactile and visual instead of abstract and confusing.

How I built it

I used a hybrid approach with Kiro, choosing different workflows for different parts:

  1. Core Algorithm (Spec-Driven Development): -Spent 2 days writing formal requirements and design documents -Defined 33 "correctness properties"—formal statements about what should always be true -Kiro generated 203 tests (170 unit + 33 property-based) from the spec -Implemented the algorithm systematically, task by task -Result: Zero bugs, 100% test coverage, provably correct

  2. User Interface (Vibe Coding): -Had natural conversations with Kiro about what I wanted -"Create a vintage 1920s switchboard with brass accents" -"Add authentic mechanical click sounds" -Iterated quickly on design and UX -Result: Unique aesthetic, smooth animations, delightful interactions

  3. Consistency (Steering Documents): Created three small docs that Kiro always reads:

    • product.md - What I'm building (financial routing)
    • tech.md - Tech stack (TypeScript, Vitest, fast-check)
    • structure.md - Where files should go Result: Consistent code across 85+ files without repeating myself

  4. Tech Stack: TypeScript, React, Vite, Vitest, fast-check, Framer Motion, Tailwind CSS

Challenges I ran into

  1. Understanding my own problem Writing the spec forced me to think deeply about edge cases I'd never considered:
  2. What if there's no direct path?
  3. What if I need to combine multiple accounts?

  4. What if the deadline is on a weekend? (I didn't actually understand the problem until I tried to explain it formally to Kiro.)

  5. Property-based testing I'd never heard of property-based testing before. The concept—generate hundreds of random test cases automatically—was mind-blowing but hard to grasp at first. Kiro helped me understand how to write properties like "for any valid route, the sum of amounts must equal the goal."

  6. Balancing spec vs vibe Early on, I tried to spec everything, including the UI. That was too slow. Then I tried vibe coding the algorithm—that was too risky. Finding the right balance (spec for logic, vibe for UI) took a few days.

  7. Account synchronization Getting accounts to sync between the automatic mode and manual switchboard was tricky. I kept adding accounts in one place and they wouldn't show up in another. Kiro helped me implement React Context and localStorage to solve it.

  8. Mobile switchboard The spatial grid layout didn't work on mobile. I tried just shrinking it, but it was unusable. Kiro suggested a completely different vertical layout, which ended up being better than my original idea.

  9. I did feel like I had to repeat myself when it come to certain design updates. One day, this weird glow because the logo would reappear every single time I tried to make an update. I wondered what prompt I could have used to completely resolve the issue.

Accomplishments that I am proud of

  • Beginning with a spec-driven approach helped me set up the sore algorithm without bugs. There were 203 tests passing. However, I did not have time to debug the usability issues that occurred when I kept working on the project before submission.
  • Unique aesthetic: The vintage switchboard interface isn't just decoration—it makes the abstract concept of "routing money" feel tangible and understandable.
  • Real-world applicability: This isn't a toy project. The algorithm solves an actual problem I have, and the architecture is close to production-ready.
  • Learning curve: As someone relatively new to coding, I'm proud that I built something with real algorithmic complexity (BFS, graph traversal, multi-objective optimization) and understood it deeply enough to prove it's correct.
  • Authentic audio: The Web Audio API implementation with low-pass filters for vintage muffled sounds—that was a "wow" moment when it worked perfectly on first try.
  • Accessibility: WCAG AA compliant, keyboard shortcuts, screen reader support. I learned that accessibility isn't an afterthought—it's part of good design.

What I learned

  • Spec-driven development is worth it for complex logic: The upfront time investment paid off massively. I would have spent days debugging without those tests.
  • Vibe coding is perfect for creative work: For the UI, I didn't need formal specs—I needed to iterate quickly and trust my eyes.
  • Steering documents are force multipliers: Small investment, huge consistency gains. I wish I'd created them on day 1.
  • Property-based testing catches things you'd never think of: Generating hundreds of random test cases found edge cases I would have missed with manual examples.
  • Context management matters: Kiro is only as good as the context you give it. Clear steering docs and well-structured specs made all the difference.
  • Dead technology can solve modern problems: The switchboard metaphor isn't just aesthetic—it actually helps people understand routing better than a traditional form interface.
  • As a beginner, structure helps: I thought coding was "write code until it works." Spec-driven development taught me that professional coding is: understand the problem, design the solution, implement systematically, prove it's correct.

What's next for Patch Pay

  • Real bank integrations: Connect to actual bank APIs for live fee data and real transfers (currently uses static demo data)
  • Building a database that has transfer rules form every available account a person could transfer money from or to. -Machine learning for recommendations: Learn from user preferences to improve the "recommended" route selection over time
  • Multi-currency support: Handle international transfers with exchange rates and cross-border fees
  • Scheduled transfers: Set up recurring optimized transfers (e.g., "move $500 to savings every month using the cheapest route")
  • Transfer execution: Actually execute the transfers, not just calculate routes (would require bank API partnerships and regulatory compliance)
  • Social features: Share favorite routes with friends, compare fee savings
  • Browser extension: Analyze transfer options directly on bank websites
  • MCP integration: Use Model Context Protocol to connect to real-time financial data sources and compliance checking tools
  • Production deployment: Scale the infrastructure, add monitoring, implement proper security
  • Mobile app: Native iOS/Android apps with push notifications for transfer completion

The foundation is solid: provably correct algorithm, production-quality code, unique UX. Now it's about scaling and adding real-world integrations.

Changes Made December 5th (Before 2pm Deadline) - Not Pushed to GitHub

Critical Fixes

  • Fixed transferRules.json data - Corrected account IDs to match (was causing "account does not exist" errors)
  • Fixed account type - Changed "zelle" type to "other" (valid AccountType)
  • Added more bank accounts - Expanded from 6 to 10 accounts (PayPal, Wise, Chime, Cash App Business)

UI/UX Improvements

  • RouteCalculator layout redesign - Separated destination (green) from source (amber) visually
  • Made amount optional - Defaults to $100 if left blank
  • Updated styling - Changed panels to match industrial theme (zinc-800, proper borders)
  • Fixed "OTHER AVAILABLE ACCOUNTS" - Shows "No balance" for non-user accounts
  • Added "NEW SEARCH" button - Lets users recalculate after seeing results
  • Improved source account dropdown - Only shows user's accounts, not all network accounts
  • Fixed account balance merging - User balances properly override network defaults

Documentation

-Added demo script - Created DEMO_SCRIPT.md with 60-second video guide -Updated README_FOR_JUDGES.md - Added recommended demo path section

Minor Fixes

-Switchboard operator instructions - Moved above controls for better UX -Landing page example data button - Made clickable to load 3 example accounts -Removed forced account setup - Users can use calculator immediately

Built With

  • arialabels
  • autoprefixer
  • claude
  • css
  • docker
  • eslint
  • framermotion
  • git
  • github
  • html
  • javascript
  • json
  • keyboardnavsupport
  • localstorage
  • localstorageapi
  • node.js
  • postcss
  • progressivewebappmanifest
  • react18
  • reactrouterdom
  • serviceworkerofflinefunctionality
  • serviceworkers
  • tailwindcss
  • typescript
  • typescriptcompiler
  • vite
  • vitest
  • wcag2.1
  • webaudioapi
Share this project:

Updates