case-study saas dev career proaba
From 0 to 100 Clinics: How I Built ProABA
The real story of how I helped build a healthcare SaaS platform used daily by ~100 ABA therapy clinics in Brazil. Architecture, decisions, mistakes and what you can learn.
· Marcos Souza
Almost two years ago, I joined a project that changed my career. It wasn’t a delivery app, or a social network, or a productivity SaaS.
It was a platform for therapists who work with children with autism.
Today, ProABA is used daily by ~100 clinics and therapy centers in Brazil. Each clinic serves between 10 and 100 children. The platform can’t go down — because when it does, therapists can’t work.
That’s the kind of responsibility that doesn’t show up in anyone’s portfolio. But it’s what defines whether you can truly deliver.
The problem that needed to be solved
ABA therapists in Brazil managed everything in spreadsheets, paper, and WhatsApp. Child records, clinical assessments, intervention plans, progress reports — everything fragmented.
The problem wasn’t technical. It was human:
- Data got lost between sessions
- There was no continuity when a therapist left
- Parent reports were made manually
- Protocol compliance was hard to track
ProABA needed to solve this with a platform that:
- Worked every working day, without failures
- Served dozens of clinics, each with their own workflow
- Was intuitive for healthcare professionals (not devs)
- Supported Portuguese and English
- Handled sensitive health data securely
The stack — and why we chose each piece
We didn’t choose technology for hype. We chose for the problem.
| Technology | Why |
|---|---|
| Next.js (App Router) | SSR + Server Actions = less API boilerplate, faster delivery |
| TypeScript strict | Health data can’t have silent errors |
| Prisma + MySQL | Typed schema + migrations = confidence in database changes |
| Playwright | E2E tests on critical flows (registration, assessment) — if it breaks, we know before the therapist |
| Tailwind CSS | Visual consistency in a team of 20 devs |
| BetterAuth | Robust authentication without reinventing the wheel |
| next-intl | Real i18n — not just button translation, but forms, error messages, reports |
| Sentry | Production error monitoring — we know when something breaks before complaints |
| Docker | Predictable deployment — works locally = works in production |
What I built
I’m not “the ProABA dev.” I’m one of 20 developers. But I contributed to practically every layer — from the form the therapist fills out to the error that appears in Sentry at 11pm.
Multi-step registration system
A wizard that collects detailed data about each child: personal information, emergency contacts, medical history. Each step validated via Zod, smart optional fields, everything bilingual.
The real challenge: Therapists filling out forms between sessions, in a hurry, on mobile. The form needed to be fast, forgiving of errors, and never lose data mid-way.
Clinical assessment tools
Components for scoring by level and group, individual visualizations that therapists use during the session with the child. Performance matters here — there can’t be lag while the therapist observes and records behaviors in real time.
Intervention plans and clinical notes
Every child has an intervention plan that needs to be tracked session by session. I built the navigation between plan steps, drawer buttons for quick actions, and the full CRUD for notes — where the therapist records observations during the appointment.
What I learned: “Customer service” functionality in healthcare is different from any other sector. Every field needs to be fast, accurate, and work in the therapist’s head on an offline-first basis. No fancy animations — just reliable data.
Design and UX for non-devs
ProABA users are therapists, clinic coordinators, parents. None of them know (or need to know) what React is. Interface here isn’t “pretty” — it’s invisible. Components like LevelGroupSelector, child search filters, and PersonDetails visualizations were designed so that the user finds what they need in 2 clicks or less.
I directly participated in the design of reusable components, consistent color system via Tailwind, and real responsiveness (not “works on mobile just to say it does”).
Monitoring and logging with Sentry
A healthcare clinic site can’t go down silently. I integrated Sentry to capture production errors with context: which user, which flow, which action. This allowed us to know about a bug before the therapist opened a ticket.
In practice: when a Server Action failed, Sentry captured the stack trace + request data. Instead of receiving “it’s not working” on WhatsApp, we already knew what, where, and why.
AI in the development workflow
I didn’t use AI in the product (yet). I used it in the process of building the product:
- GitHub Copilot for autocompleting repetitive patterns (i18n keys, Zod schemas, Playwright tests)
- Claude for debugging complex problems — explaining context, receiving hypotheses, testing
- ChatGPT for drafting technical documentation and coding guidelines
Practical result: I estimated 30-40% more speed on scaffolding and boilerplate tasks. The creative code — the architecture, the decisions, the “this works for therapists” — remains human.
Quality standards for 20 devs
This was the least “glamorous” and most impactful work. I created:
- Standardized PR templates
- Documented coding guidelines
- Naming conventions for the entire project
- Removal of dead code with Knip and continuous refactoring of hooks and stores
With 20 people committing, no standards = chaos. These docs are what keeps the project sustainable after ~2 years.
Tests that matter
We don’t test everything. We test what can’t break:
- Child registration flow (E2E with Playwright)
- Clinical assessments
- Intervention plans
- Critical Server Actions (typed with Zod)
If an update breaks a child’s registration, the test catches it before going to production.
The numbers
After almost 2 years, these are the facts:
| Metric | Value |
|---|---|
| Active clinics | ~100 |
| Children per clinic | 10-100 |
| Personal commits | 646 |
| Implemented features | 108 |
| Bugs fixed | 134 |
| Refactorings | 128 |
| Supported languages | PT + EN |
| Unplanned downtime | Zero during my contribution |
646 commits isn’t a vanity metric. It’s consistency. It’s being present when the deploy goes wrong at 10pm on a Friday.
I’m Marcos Souza, a web dev who builds scalable, reliable software for real problems. If you want to talk about your project, message me on WhatsApp or visit marcossouza.dev.