Writing
July 28, 2025 · 13 min read

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:

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:

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.

Update on Jan 27, 2025: Jane finally responded to my email. In short, looks like I am breaching their terms. So, I cannot use it for my personal purpose as well. It is a long goodbye to this App. I took down the GitHub repo as well. Here is their email:

============================================================================

`Hi Sundararajan,

AAAAAA from the Jane Product Partnerships team here!

First off, I’m really sorry for the very delayed reply here. Thanks for your patience. I appreciate the thoughtful note and the kind words about Jane. I also want to say thank you for reaching out proactively to check on compliance. We really value that. Based on what you described, specifically proxying and aggregating real-time availability across multiple Jane-powered booking pages, this would be considered automated collection of data from Jane booking pages. Even if it’s for personal or family use, infrequent, and you’re not storing the data, this approach isn’t permitted under our Terms, so we’re not able to approve or support it. To answer your questions directly: Does personal or family use align with your terms? No. The automated aggregation or proxy requests you described don’t align with our Terms.`

  1. Are there any modifications we’d recommend to ensure compliance? The compliant path would be to stop automated requests or aggregation of Jane booking data. Checking availability would need to happen through normal use of each clinic’s online booking flow, meaning manual browsing rather than programmatic collection.
  2. Would we be interested in potential collaboration? At this time, we’re not able to pursue collaboration on this concept. To give a quick summary about where we are heading: we’re in the early days of building our first API partner programs, meaning allowing partners and builders to build on Jane’s APIs and publish integrations to our audience. Right now, the parts of Jane we’re making available to potential builders include 1) the ability to write entries into Jane’s charting, and 2) the ability to read a Jane clinic’s patients and appointments. At the moment, we have a closed API. As we grow into our next phase and build our partner ecosystem, we’re taking a selective approach, working with a small number of strategic partners through a closed API. This helps us ensure the highest level of security and a truly delightful experience for our customers. Because of this approach, we don’t have API access to share right now.

`Thanks as well for sharing your post. Given the compliance concerns above, we’d ask that you remove any references that imply Jane has approved this approach, and that the tool be discontinued as currently implemented.

I appreciate your understanding, and again, thank you for checking with us first.

Warmly, AAAAAA`

============================================================================

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:

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.

← All writing Home