5 min read ​Read online​

#40 | What Happens When Therapists Build Their Own Tech?

Hello dear reader,

I’m at my desk tippy-typing to the pitter-patter of rain outside my window.

Bangalore experiences the Indian Monsoon in the most gentlest fashion. Where coastal Kerala, Goa, and Maharashtra see a downpour, Karnataka drenches in its trademark 4pm rains.

It’s these very tea-time rains that were the canvas against which TiNT readers and friends gathered a fortnight ago for the Therapists Who Build (TWB) Hackathon.

The following week our Linkedin timelines were flooded with writings of everyone’s experience. Now that downpour of enthusiasm has passed and we sit instead with cool contentment, I’m here to share our findings and takeaways from TWB.

TiNT Studio: Project Announcement

But before that, here’s announcing a new User Research sprint.

Uppinder Chugh is the founder and builder of ProTherapy, a bootstrapped (which is a fancy word for self-funded), self-run and hosted practice management tool in its early stages. He’s seeking 30 minutes with practitioners.

If you’d like to grow your understanding of the products mushrooming on the fertile forest floor of the Indian mental health innovation market, read more and express your interest on the project bulletin.

TiNT Events: Bangalore Chapter

We’re meeting later today at the Cubbon Park for the first time!

Hosted by our chapter leads Aditi Bhatt, Shruti Jain, and Dishita Swaika, this will be our first therapists only event. If you can’t make it today, subscribe to our calendar to learn of future meet-ups.

TiNT Academy: Cohort #3 Concludes

Today we close on the last of week of Cohort #3 of Applied Product Thinking for Therapists. Ends of cohorts feel cathartic and nostalgic for me at the same time.

We had our biggest product partner yet, India’s largest EAP provider 1to1help, to do a demo of their limited release AI chat app Mio to this cohort. What's more, this cohort has turned in a record number of assignments, all of them fusing humanities and tech in a way that will make your heart sing. It reinforces my belief that product thinking and tech lingo is a very learnable skill for therapists, and that they’re naturals at it. More about this cohort soon. To my C#3 members reading this: I’m so proud of you! :)

Cohort #4 opens in September and is the last of this year. I hate to blow my own trumpet but seats go like hot cakes so if you’re interested, join the waitlist for APTT Cohort #4 here.

Reflections from Therapists Who Build Hackathon

TWB In Numbers

We had a total of 45 problem statements collected from 60 therapists. We divided those 45 into seven categories:

• Client-facing self-understanding: tools pointed at the client or the public rather than the practice, from an inner critic narrative game to a couples intimacy map (13).
  ​
• Administration and practice operations: notes, scheduling, payments, availability, fee logic, the business of running a practice (9).
  ​
• Matching, referral and professional discovery: helping clients find therapists, and therapists find each other, referrals, and work (7).
  ​
• Clinical reasoning and formulation: tools that help the therapist think, rather than tools that do the thinking (6).
  ​
• Assessment and screening: profiling and early identification, mostly game-based (5).
  ​
• Between-sessions continuity: the week between appointments, and what happens to a client inside it (4).
  ​
• Others: one project testing whether a clinically grounded mental-state representation makes AI support safer (1)

By the end of the day, 20 of those 45 were working prototypes. Another 15 continue being being built. 13 statements nobody picked up at all, which is its own kind of finding.

Between-sessions continuity was the smallest category and had the highest completion rate: 4 statements, 3 finished tools. Assessment and screening had 5 statements and finished none. This tells me that when a therapist owns the data a prototype can appears in hours. When the problem statement touches instruments, norms, and regulatory surface, it slows down creativity and building.

On Building For The First Time

All TWB therapists were new to vibe-coding, all opening an account on Claude Console and understanding how AI credits and tokens work for the very first time.

Building can be daunting and hard as a first time experience. The screens and commands feel alien. The words sound technical. It's far from care work in that it produces an object at the end of the process.

Considering all of these newnesses, you’d expect TWB therapists to talk about the experience of learning the tool the most, right?

Yet, the most common thing TWB therapists described was a shift in what they believed was now available because they could make things.

One participant wrote that she did not expect to leave grateful for how much she had learned and how much more there was, in a way that felt expansive rather than overwhelming. Another said the day left her with a growing confidence that she can actually build things.

On What The Problem Statements Reveal

All TWB therapists went through a 2 week process of refining their problem statement which they would then bring on the d-day to build. We collected these in our in-house tool, WishICould.

Now, if you read the WishICould wall as a single document two patterns begin to emerge.

The first is the need to address the administrative burden in a therapy business. For example: blocking slots manually whilst juggling between three platforms, reconciling UPI transfers against a calendar, retyping handwritten notes, charging one fee for a consultation that ran twice as long.

There’s plenty of innovation in this area but I was ever skeptical of it because it came from non-therapists. That TWB therapists themselves developed problem statements around it was validating because it proved that to some extent, administrative burden is indeed a problem to be solve.

The second is the need to protect the clinical judgment and discernment. An integral part of our problem statement design process was to name what the tool must not do. This was because drawing boundaries of the tool is as important as drawing its scope. Containment is one antidote of risk in clinical tools. Repeatedly, problem statements on WishICould end by naming what the tool must not do, and all the boundaries point to clinical judgment.

Traditionally, you see software products claiming to always do more. More is good, more is fast, more is powerful. By drawing this boundary for the functionality of the tool, TWB therapists created scope for creativity in a way you don’t see in the tools iin the market.

On Therapists Jamming With Engineers

There’s a preconceived notion that to work with engineers and to engineer anything requires a certain level of competency in speaking the “coding language”. This notion was joyfully disproved by TWB participants as they agreed that this sort of interdisciplinary collaboration had to do more with aligning visions than speaking an alien language.

Since we’d already prepared crisp problem statements (naming who it is for, what it does, what it must not do), therapists and builder pairs hit the ground running.

One TWB therapist described this balance as being walked through each step while still having room to figure things out with her builder alongside her. Which in turn had a compounding effect on creativity. Several participants said when they mingled with other teams, their own ideas sharpened. The most valuable thing simply became the room and the people in it.

On Presentation & Open Critique

At the end of the day, every project at TWB had to be presented to the entire participating forum. This presentation had to be done by the therapist who led the project.

Now, presenting the build to your team and having them use it and critique it is day-to-day for builders and tech-workers. A huge part of building anything is developing thick skin to take feedback on it. So the brief for TWB therapists was: present.

Present even if your prototype is incomplete. Even if you feel under-confident. Present because presenting makes it clear how much the tool speaks for itseelf vs how much you have to speak for it.

What We Got Wrong

The very thing that made TWB a smashing success (I daresay so myself) also became its achilles’ heel.

A few participating therapists did not have the same experience as the rest due to last minute changes in the availability of their builder team-mates. Combine that with joining from different cities, the async nature of communication, and the newness of building with AI and we had a recipe for an unpleasant first experience of vibe-coding.

As organisers my team and I acknowledge the things that were within our control that we can and will improve on. A lesson that we learned through this process is that builder-therapist team curation and commitment is everything to trust building and therefore tool building.

In Closing

A handful TWB participants want to keep improving their prototype, and we’ve set up something called P2C (Practice-to-Client) Studio to facilitate that. I'm keen to find out what happens when a tool born inside a practice keeps growing there. More on that soon.

In the next edition, I’ll be talking about all the TWB prototypes and the participants who built them.

Take care and see you soon,

Harshali
Founder & Educator, TiNT

Look us up on LinkedIn, Insta, Luma. We're present but not so active yet on X and Youtube. Look me (Harshali) up on LinkedIn and Insta.