Building What Doesn't Exist: I have an app for that
Scratch your own itch
The Problem That Wouldn't Go Away
In the last post, I talked about an engineer-turned-PM's return to building with AI, and one I was building was RMT Finder. In this post, I want to talk about why I endured myself in building RMT Finder—and how it happened faster than I ever imagined.
It all started because of Michelle Wojcik (yes, a real person; CMTO profile here). She was our RMT. The wife highly recommended that I go to her for my shoulder and lower back. She was the best. I doze off every time she weaves her magic. And then, the clinic administration split. She left. To downtown Toronto, a good hour and a half drive. Whereas my usual commute was a 20-minute walk or 5 minutes by cycle/car.
That's when I became like a mindless wanderer. Checking for other RMTs within our area based on good reviews in Google and, more importantly, in our local Facebook community groups. Each recommendation led me to different RMTs across different clinics, each with their own Jane App booking system. I'd have to create accounts, learn each interface, and manually check availability across multiple platforms.
While Jane App has revolutionised clinic management—and I genuinely appreciate what they've built—there was a gap in what I needed as a patient. I had no unified way to:
View schedules across multiple clinics
Verify RMT experience and certifications through CMTO
Compare availability without juggling multiple apps
There were gaps in what I needed; outside the lookup of schedules on various clinics, I didn't have a way to verify RMT's experience and certification. I needed to use CMTO. The CMTO's verification system ensures I'm seeing qualified professionals.
This verification matters more than I initially realised. Ontario's RMT industry generates $2.0-2.1 billion annually and represents 70% of Canada's entire massage therapy market. With over 13,000 registered RMTs in the province—86% of whom are self-employed—distinguishing qualified practitioners from unregulated alternatives is crucial. Most extended health plans only cover CMTO-registered RMTs, giving verified professionals a significant competitive advantage. Analysis here.
It's like having amazing individual restaurant menus but no OpenTable to see what's available tonight.
The "Build vs. Buy" Moment
For an issue/problem at hand, just like everyone else, I look for ready-made options or workarounds. Unlike many, if all else fails, I do not give in to fate. I handcraft a solution. Not because I am a Product Manager, but because I see it as a way to learn something or beat boredom. That said, as a PM, I know the drill: validate the problem, research existing solutions, consider building vs. buying. I spent weeks looking for existing aggregators, APIs (Jane App in their FAQ was clear that there were no APIs), or services. Nothing comprehensive existed for the Canadian RMT market.
Before settling on Kiro, I tried the usual suspects: Cursor for its codebase awareness, Claude Web for general development help, Bolt and v0 for rapid prototyping, and Lovable for full-stack development. Each had strengths, but they all felt like sophisticated coding assistants rather than development partners. They'd help me write code, but I still had to figure out the architecture, break down the requirements, and manage the project structure myself.
The traditional path would be: write specs, hire developers, manage a 6-month project, iterate based on user feedback. But I had a different tool available: Kiro AI. I was in their beta to try out. I have been playing with it for the last two weeks.
Since I had an existing semi-solution, I started with a simple conversation: "I want to build a platform that shows RMT availability across multiple clinics in Stouffville." with several HAR files and example HTTPS calls each clinic makes to Jane (I wouldn't call them APIs yet).
What Happened Next Surprised Me
Within hours, Kiro had:
✅ Analysed the Jane App HTTPS calls and structure
✅ Built a React/TypeScript frontend with real-time availability
✅ Created a Node.js backend that aggregates data from 10+ clinics
✅ Implemented city-based filtering for future expansion
✅ Added CMTO verification integration
The entire MVP was functional in a single day (OK … several hours that make up a single day ;-) ).
Compare this to my previous attempts with other tools: Cursor would have helped me navigate the codebase efficiently, Bolt might have given me a quick prototype, v0 could have generated some UI components, but I'd still be stuck figuring out the overall architecture and breaking down the requirements myself. With those tools, this would have been a weeks-long project of trial and error.
The Technical Magic (Without the Technical Debt)
What impressed me wasn't just the speed—it was the quality. Kiro didn't just hack together a prototype. It built:
Proper Architecture: Clean separation between frontend/backend, modular components
Real-time Data: Live availability from Jane App HTTPS calls, not static listings
Scalable Design: City-based organisation ready for expansion beyond Stouffville
User Experience: Intuitive search, filtering, and booking flow
Error Handling: Graceful fallbacks when clinic APIs are unavailable
The code quality rivals what I'd expect from a senior development team.
Respecting the Ecosystem
Here's what I love about this approach: it enhances rather than disrupts the existing ecosystem.
Jane App continues to be the backbone—clinics keep their existing workflows, patients still book through Jane's interface. Without Jane App, this aggregation wouldn’t even be possible. The other way would be to manually look up every clinic’s site.
The CMTO verification system remains the source of truth for practitioner credentials.
My platform simply aggregates and presents information that's already public, making it easier for patients to find available appointments. It's like Google Flights for massage therapy. That said, I have emailed the team at Jane App to ensure what I am doing doesn’t breach their Terms and does not cause any harm to their system.
All said, I built this for myself and the wife. Not available for anyone else. Why? I don't know if my itch is your itch. :-) Next, this may amount to abuse of Jane App—since I don't know how their platform scales. I don't want to disrupt their product and services offered. Well, this may be something that they can borrow with some royalties—wink-wink.
The Broader Implications
This experience made me rethink what's possible for solo builders and small teams, especially in markets experiencing rapid digital transformation:
Speed to Market: Ideas can become functional products in days, not months
Quality at Scale: AI can maintain code quality standards that typically require large teams
Niche Solutions: Problems too small for VC-backed startups become viable for individual builders
Ecosystem Integration: Instead of replacing existing tools, we can build bridges between them
The RMT market exemplifies this opportunity. Consumer adoption of massage therapy has nearly doubled—from 23% in 1997 to 44% of Canadians today—while the profession rapidly adopts digital tools for practice management and client engagement. Yet no unified discovery platform existed for this $2+ billion market. The gap between market size and available solutions creates perfect conditions for AI-assisted development to shine. Analysis here.
What This Means for Product Managers
As PMs, we're used to being the bridge between business needs and technical implementation. Tools like Kiro change that dynamic:
Faster validation: Build and test ideas before writing lengthy specs
Technical literacy: Understand implementation details without years of coding experience
Resource efficiency: Solve problems without large development budgets
User focus: Spend more time on user research and less on technical project management
The Result & What's Next
I now have a platform that solves my original problem. I can see real-time availability across all RMTs in Stouffville, filter by speciality and availability, and book appointments efficiently.
But more importantly, I have a new appreciation for what's possible when AI tools meet real-world problems. The barrier between "I wish this existed" and "I built this" has never been lower.
Looking ahead, I'm collaborating with my good friend Thiru to add a reputation analysis feature that will aggregate and analyse reviews across multiple providers. The platform could also expand to other cities, integrate additional data sources, and add features like treatment history tracking.
The technical foundation is solid, and the expansion roadmap is clear. What started as personal frustration became a viable product in less time than it typically takes to write a PRD.
Two videos that demonstrate (click to view):
The not-so-tangent? Spec-Driven Development.
Here's what makes Kiro fundamentally different from other AI coding tools I've used—Cursor, Claude Web, Bolt, v0, and Lovable: spec-driven development.
It is clear from the videos above that while most AI assistants, no matter how sophisticated, essentially help you write code faster. Cursor excels at understanding your codebase, Claude Web provides excellent general development guidance, Bolt and v0 can rapidly prototype interfaces, and Lovable handles full-stack development well. But they all start with the assumption that you know what to build and how to structure it.
Kiro flipped this completely. Instead of asking "How do I code this?" it asked "What exactly are we building?" It turns your prompt into clear requirements, system design, and discrete tasks using EARS (Easy Approach to Requirements Syntax) notation.
Think about it—I gave Kiro a conversational prompt about wanting an RMT platform, and it didn't just start coding like the other tools would. It created:
Structured requirements break down exactly what needs to be built
System architecture defines how components would interact
Task lists with clear deliverables and dependencies
Implementation roadmap that could guide any development team
This isn't just faster coding—it's intelligent project orchestration. While other AI tools make you a faster developer, Kiro essentially did what would typically require a BA, system architect, and senior PM working together for weeks.
It is mind-boggling to see how Kiro could disrupt how PMs work. How much involvement they can have—Engineering team permitting. Writing requirements all by themselves (Agentic-handoff) with simple prompting? Am I (as a PM/middleman) still relevant? சொந்த காசுல சூனியும் வைச்சுக்கார்த்து (loosely translated: keeping sorcery/black magic on oneself with one's own money). The closest English (a funny language) can get is this: digging your own grave.
The implications are staggering. If AI can bridge the gap between problem identification and structured requirements—the core of what we do as PMs—what does that mean for our role? Are we moving toward a world where domain expertise and user empathy matter more than our ability to write PRDs and manage backlogs?
The Meta-Lesson
This experience forced me to confront an uncomfortable truth: the most transformational aspect wasn't that I built something in 24 hours (over a couple of weekends) — it's that Kiro fundamentally changed how products come to life (maybe a bit exaggerated).
While Cursor, Bolt, v0, Lovable, and Claude Web make us faster developers, Kiro makes us better product thinkers. It bridges the gap between problem identification and structured implementation in ways that challenge our traditional PM workflows.
The question I posed earlier—"Am I (as a PM/middleman) still relevant?"—has a nuanced answer. We're not becoming obsolete; we're probably being liberated. Instead of spending weeks writing PRDs that developers will inevitably question and revise, we can focus on the higher-order challenges: understanding users deeply, identifying real problems, and ensuring solutions create genuine value.
But here's the catch: this only works if we embrace these tools rather than resist them. The PMs who thrive in this new landscape will be those who combine domain expertise with AI orchestration skills, not those who cling to traditional gatekeeping roles.
My advice? Pick a problem that genuinely bothers you and experiment with spec-driven AI development. Don't just use it to write code faster—use it to think through problems more systematically. See if you can compress your entire discovery-to-delivery pipeline into days instead of quarters.
The barrier between "this should exist" and "this exists" is dissolving rapidly. The question isn't whether AI will change how we build products—it's whether we'll be leading that change or reacting to it.
Sometimes, the best way to understand the future is to build it yourself. Or, scratching your own itch.