Skip to content
Kalpit Jain

Software Architect & Developer

HealthTech

Drawing-based platform for remote trauma recovery sessions

A web app that takes an in-person trauma recovery method online. Users draw their story board by board and record a voice-over, and facilitators use those storylines to guide the sessions. I came in after an earlier version missed the mark and, as the only engineer, redesigned the architecture and built the drawing board, storylines, charts, and subscriptions.

Overview

The platform runs trauma recovery sessions remotely. It’s built around an established method in which a user works through their experience by drawing, one board at a time, and narrating what they drew. A facilitator uses those storylines to understand how the user is thinking and guide the sessions. These sessions had always been held in person. The client wanted to take them online, and then the pandemic made it urgent.

I joined after the first version had been built by another team. It didn’t match what the client had in mind, the launch had been pushed back, and they brought me in to make it right. I was the only engineer from then until launch, and the job was to get the product to what they had envisioned without adding to the delay.

What I built

  • Storylines. A user tells their story as a series of drawing boards: they draw on one slide, add the next, and build up a sequence. Later they can record a voice-over for each slide, and the storyline plays back like a narrated presentation. For the facilitator, this is the main window into how the user is thinking. I built the slide sequence, the recording flow, and the playback engine that keeps audio and slides in sync.
  • The drawing board. This is where users spend most of their time: a canvas with a set of drawing tools chosen for the sessions, and an interface simple enough to pick up without training. I built it as a custom React component on the HTML canvas, with the tools, the interface, and the drawing logic written around how the sessions run.
  • A new architecture. When I joined, the existing version didn’t match what the client had in mind, and they wanted a codebase they could keep adding features to. I redesigned the backend, frontend, and database architecture, trimmed the dependencies down to a small set of well-maintained packages, and kept the parts of the existing code that worked. I brought the rest in line with standard practices, so new features were easy to add.
  • Progress charts. D3 charts that show how a user is doing over time, for both users and facilitators. One example: users answer a few questions each day, and the resulting score is plotted, so progress is easy to see.
  • Subscriptions. I built the subscription flow for users through Stripe. The whole tool sits behind a paywall, with nothing available for free.

Key decisions

Keep personally identifying information out of the system. The client wanted as little HIPAA overhead as possible, ideally none. I proposed how to handle that on the technical side: the platform stores no PII at all. Drawings and audio recordings live in S3 behind strict access controls, and nothing in the application data ties them to a real identity. The platform still does everything it was meant to, and the compliance overhead is much simpler.

Redesign the architecture. The launch was already delayed, so a rewrite from zero was not an option. Patching the existing version in place would have shipped sooner but left the client with code that made every new feature harder than it needed to be. So I kept the parts that worked, redesigned the surrounding structure, and moved the rest over as I built the features the client was waiting on. They got a codebase they could keep building on without adding to the delay.

Build the drawing board rather than integrate an existing one. The drawing board is the core of the platform. Everything a user does starts there, and the sessions depend on it working in a very specific way, down to which tools are on offer and how the board behaves. Dropping in an existing tool would have been less work, but every gap between it and the sessions would have been a compromise in the most important part of the product. Building it meant the board could be shaped entirely around the sessions.

How it went

The platform launched and is still in use. I was the only engineer on the project, owning the architecture and every feature, and was in the technical calls with the client throughout. My work wrapped up at the production launch. The client started using it in their sessions straight away, with little training needed.

What I’m most pleased with is the drawing board. It matches what the client asked for exactly, and users find it intuitive from the first session. It’s the part of the platform people spend the most time on, and it just works.

Built with
Django, Django REST Framework, PostgreSQL, Next.js, React, Redux, D3.js, Docker, AWS S3, Heroku, Stripe