Impaciente

Table of Contents

• The Problem
• Constraints
• Approach
• Tradeoffs
• Outcome
• What I'd Improve Now

The Problem

Chilean healthcare providers are legally required to track and respond to patient complaints within strict timelines under Chile's "Ley de Derechos y Deberes de los Pacientes" (Patient Rights and Duties Law).

The existing solutions failed:

• Paper-based systems: Cannot track deadlines, prone to loss, impossible to audit
• Generic ticketing tools: Don't understand healthcare compliance requirements, lack domain-specific workflows
• Excel spreadsheets: Break down under multi-user collaboration, no alerting system

Clinics needed software built specifically for this regulatory requirement—something that understood the domain, enforced compliance, and actually worked.

Constraints

Technical:

• Had to work reliably in healthcare environment (no downtime tolerance)
• Required real-time updates for multiple users across clinics
• Needed to work on existing clinic infrastructure (no fancy IT setups)
• Had to be maintainable by a single developer (me)

Business:

• Bootstrapped with zero external funding
• Small market (Chilean healthcare only)
• Competing against "free" (Excel) and established players
• Customers had low willingness to pay for software

Regulatory:

• Strict compliance requirements with Chilean healthcare law
• Required audit trails for all complaint handling
• Had to generate compliance reports for government inspections

Approach

Tech stack: Full-stack Meteor.js with MongoDB. Yes, it was trendy in 2016. But more importantly:

• Real-time reactive data flow out of the box
• Built-in user authentication and sessions
• Same language (JavaScript) front-to-back
• Fast prototyping for domain validation
• Actually works reliably (still running 8 years later)

Product decisions:

1. Domain-specific, not generic: Built workflows specifically for Chilean healthcare compliance, not a general ticketing system
2. Opinionated design: Limited customization, enforced best practices, reduced configuration hell
3. Multi-tenant SaaS: Each clinic gets isolated data, shared infrastructure, lower operational costs
4. Deadline-first: Automatic tracking, escalation alerts, compliance warnings front and center

Business model:

• Monthly subscription per clinic
• Flat pricing (no per-user charges to avoid adoption friction)
• No contracts (month-to-month to prove value)
• White-glove onboarding included

Tradeoffs

What I chose:

Decision	Why	Cost
Meteor.js (monolith)	Speed of development, real-time updates	Harder scaling, framework lock-in
MongoDB (NoSQL)	Flexible schema for rapid iteration	No complex queries, less data integrity
Opinionated UX	Faster adoption, enforced compliance	Less flexibility, some feature requests denied
Bootstrap SaaS	Predictable costs, fast deployment	Single point of failure, vendor dependency
Solo development	Keep costs low, maintain control	Burnout risk, slower feature velocity

What I didn't choose:

• Microservices (overkill for 8 customers)
• Complex role systems (kept it simple: admin/user)
• Custom reporting (provided exports instead)
• Mobile apps (responsive web was enough)

Outcome

Quantitative:

• 8 clinics using the platform continuously
• 8 years in production (2016-2024)
• No prolonged outages
• Zero refactors or rewrites
• ~150 active users across all clinics
• Thousands of patient complaints processed and resolved

Qualitative:

• Clinics pass government compliance audits without issues
• Users report it "just works" (highest praise for enterprise software)
• Reduced complaint resolution time from weeks to days
• Eliminated lost paperwork and missed deadlines
• Still running on original codebase with minimal maintenance

Business impact:

• Sustainable recurring revenue for 8 years
• Low churn (clinics don't leave)
• Proof that boring, domain-specific software can succeed
• Validated the "do one thing well" approach

What I'd Improve Now

If I were rebuilding today:

1. Better testing: Add comprehensive integration tests (I relied too much on manual QA)
2. Structured logging: Implement proper log aggregation and monitoring from day one
3. API-first: Build a proper REST/GraphQL API layer (currently too coupled to Meteor's methods)
4. Database migrations: Use a proper migration system instead of ad-hoc updates
5. Automated backups: Make backup/restore procedures more robust and tested
6. Performance monitoring: Add real user monitoring and error tracking (Sentry, etc.)

But honestly?

For a bootstrapped SaaS serving 8 customers, the current setup works. The platform has been profitable since year one, requires minimal maintenance, and delivers real value to users.

Sometimes "good enough and shipping" beats "perfect architecture that never launches."

Tech Stack Details

• Frontend: Blaze templates (Meteor's original templating system)
• Backend: Meteor.js (Node.js)
• Database: MongoDB with Meteor's Minimongo for client-side reactivity
• Hosting: DigitalOcean droplet (single server, very boring)
• Deployment: Meteor Up (mup) for automated deploys
• Monitoring: Basic uptime monitoring via UptimeRobot

Key Learnings

1. Domain knowledge > Tech stack: Understanding healthcare compliance was more valuable than using the "best" framework
2. Boring tech wins: Meteor.js might not be trendy anymore, but it's been rock-solid reliable
3. Constraints breed creativity: Bootstrap funding forced sustainable business decisions
4. Small can be profitable: 8 customers × 8 years > venture-funded startup that pivots 3 times
5. Users want reliability: "It just works" is a feature, not a bug

This is the project I am most proud of—not because of the tech stack, but because it solves a real problem for real users and has stood the test of time.