From Paper to Production: Building Radiimed for Dentists in Botswana

Hey devs
First post here, glad to finally join the dev.to community.

Over the past period, I worked on Radiimed, a software product used by dental practices in Botswana to transition from paper-based record keeping to a fully digital workflow. The goal wasn’t to “disrupt healthcare” — it was much simpler: reduce friction, errors, and wasted time in day-to-day clinical operations.

I wanted to share what that journey looked like from an engineering perspective, and a few lessons that might be useful if you’re building software for real-world, non-tech users.

The starting point: paper everywhere

Most of the clinics we worked with were managing:

patient records on paper

appointment logs in notebooks

billing handled manually

imaging results stored separately or printed

This created predictable problems:

lost or incomplete records

duplicated work

slow patient turnaround

difficulty tracking history over time

The challenge wasn’t introducing software — it was changing habits without slowing clinics down.

Designing for transition, not replacement

One early lesson:

You can’t just replace paper overnight.

We designed Radiimed to mirror familiar workflows first, then gradually improve them:

forms that felt like existing paper templates

minimal required fields at the start

clear “what happens next” steps

fast load times (clinics can’t wait)

Adoption improved once staff felt the system was helping, not policing them.

The tech stack (kept intentionally boring)

We optimized for clarity and reliability, not novelty.

TypeScript across the codebase
→ Fewer runtime surprises, clearer contracts, easier collaboration

AWS for infrastructure

Managed services over custom ops

Predictable scaling

Reduced maintenance overhead

The goal was simple:

Clinics should never care how it works — only that it works.

What actually improved for clinics

Once clinics were fully onboarded, we saw clear operational gains:

faster patient check-ins

centralized patient histories

easier retrieval of imaging and notes

fewer clerical errors

better continuity of care

No flashy dashboards — just less friction.

Lessons learned (the important part)

1. Non-technical users will teach you humility
   If a dentist or assistant struggles, it’s not a “user problem” — it’s a design problem.

2. Reliability beats features
   A small, stable system beats a powerful system that fails once during clinic hours.

3. Type safety pays off long-term
   TypeScript caught edge cases early — especially around patient data and workflows that must not break.

4. Infrastructure should disappear
   Using AWS managed services meant fewer “fire drills” and more time improving the product.

5. Context matters
   Software built for clinics in Botswana has different constraints than software built for startups in San Francisco — and that’s okay.

Why I’m sharing this here

I joined dev.to to:

share real engineering experiences from production systems

learn from others building software for real users

talk about tech beyond hype cycles

If you’ve worked on:

healthcare software

systems replacing manual workflows

products for emerging markets

I’d love to hear what you learned too.

Thanks for reading 🙌