Matabichos Workflow

Table of Contents

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

The Problem

Matabichos is a pest control company operating across multiple regions in Chile. Before this system, their entire operation ran on manual spreadsheets, email chains, and disconnected records.

The operational reality:

• Sales pipeline tracked in Excel, passed around via email
• Customer files scattered across folders and physical documents
• Scheduling done manually, frequent conflicts and missed visits
• Service certificates generated by hand, prone to errors
• Invoicing disconnected from operations, delayed billing
• Collections tracked in separate spreadsheet, many overdue accounts
• Compliance documents (controlled substances, vehicle permits) managed on paper
• No single source of truth for anything

The cost:

• Slow follow-ups on sales opportunities
• Missed service visits and scheduling conflicts
• Delayed invoicing and lost revenue
• Compliance risks (expired permits, missing documentation)
• No visibility into operations for management
• Duplicated work and data entry across systems
• Unable to scale beyond current size

They needed a complete operating system—not just software, but a fundamental transformation of how the business runs.

Constraints

Technical:

• Had to work reliably for field operations (technicians, supervisors)
• Required role-based access (sales, ops, admin, finance, management)
• Needed to handle complex multi-step workflows across departments
• Must generate legally compliant documents (quotes, contracts, certificates)
• Had to integrate with existing processes (couldn't shut down business for migration)
• Single developer (me) building and maintaining everything

Business:

• Bootstrapped development (no separate budget for software)
• Company couldn't afford downtime or failed deployments
• Had to deliver value incrementally (couldn't wait for "complete" system)
• Required buy-in from teams used to spreadsheets
• Needed to work across multiple regions with spotty internet

Operational:

• Complex dependencies between modules (sales → ops → billing → collections)
• Multiple document types with legal/compliance requirements
• Inventory tracking for controlled substances
• Vehicle and equipment management
• HR files and employee records
• Quality control and service verification

Approach

Architecture: Monolithic Meteor.js application with MongoDB

Why this stack:

• Real-time reactivity: Operations see updates instantly across modules
• Single codebase: Faster development, easier maintenance for solo developer
• JavaScript everywhere: Same language front-to-back reduces context switching
• Built-in accounts: User authentication and role management out of the box
• Proven reliability: If it works for Impaciente (8 years), it'll work here

Product strategy: Full business lifecycle coverage

Built 11 interconnected modules:

1. Sales Pipeline: Lead capture, opportunity tracking, quote generation (PDF)
2. Customer Management: Complete customer files, service history, contacts
3. Scheduling System: Calendar-based service planning, technician assignment
4. Field Operations: Job execution, service verification, photo uploads
5. Certificate Generation: Automated PDF certificates for completed services
6. Invoicing: Automated invoice generation from completed services
7. Collections: Overdue tracking, payment recording, aging reports
8. Warehouse: Inventory management for products and controlled substances
9. Compliance: Controlled document tracking (permits, licenses, certifications)
10. HR Management: Employee files, contracts, training records
11. Fleet Management: Vehicle tracking, maintenance, inspection records

Key technical decisions:

• Role-based workflows: Each team sees only relevant modules

  • Sales: Pipeline + Customers
  • Operations: Scheduling + Field execution + Warehouse
  • Finance: Invoicing + Collections + Reports
  • Management: Everything (read-only analytics)

• Document automation: PDF/DOCX generation for quotes, contracts, certificates

  • Eliminated manual document creation
  • Ensured compliance and consistency
  • Automatic numbering and versioning

• Scheduled automations (7 cron jobs):

  • Alert notifications for unresolved issues
  • Collection reminders for overdue invoices
  • Compliance warnings for expiring documents
  • Scheduling consistency checks
  • Daily operational summaries

• Data exports: Custom reporting across all modules

  • Operations reports (services by region/period/type)
  • Financial reports (billing, collections, aging)
  • Quality control (service completion, customer feedback)
  • Inventory movements (product usage, stock levels)

Development approach:

• Incremental rollout: Deployed module by module, not big bang
• Iterative refinement: Built v1, got feedback, improved in production
• Documentation as code: Inline comments and workflow diagrams
• Manual testing: No automated tests (solo developer trade-off)
• Direct user feedback: Worked with actual users to refine workflows

Tradeoffs

What I chose:

Decision	Why	Cost
Monolithic architecture	Single codebase, faster development	Harder to scale individual modules
Meteor.js framework	Real-time updates, fast prototyping	Framework lock-in, limited ecosystem
MongoDB (NoSQL)	Flexible schema for evolving workflows	No complex joins, manual data integrity
Manual testing	Solo developer, limited time	Higher risk of bugs in production
Role-based monolith	Simpler than microservices	Less flexibility for custom workflows
Document generation (server-side)	Full control over output	Slower than client-side rendering
33 collections	Domain separation	More complex data model

What I didn't choose:

• Microservices: Massive overhead for solo developer
• Automated testing: Time investment vs. value for internal tool
• GraphQL: REST methods were faster to build
• Separate frontend: Meteor templates were sufficient
• Third-party integrations: Built everything in-house for control

The 91,000 lines of code reality:

Yes, it's a lot of code. But for context:

• 11 interconnected modules
• 33 database collections
• 84 indexes (performance optimization)
• 37 publish endpoints (Meteor's data layer)
• 22 routed workflows
• 7 cron automations
• Hundreds of business rules and validations

This isn't bloat—it's the actual complexity of running a multi-region service business.

Outcome

Quantitative:

• 10 years of continuous operation (2014-2024)
• 91,000 lines of application code
• 33 MongoDB collections
• 84 database indexes for performance
• 37 publish endpoints
• 22 workflow routes
• 7 automated cron jobs
• Multi-region coverage across Chile
• Still running on original architecture

Qualitative:

• Operational transformation: From spreadsheet chaos to centralized system
• Single source of truth: Everyone works from same data
• Faster execution: Sales → scheduling → ops → billing → collections in one flow
• Better visibility: Management can see entire operation in real-time
• Reduced errors: Automated document generation eliminates manual mistakes
• Compliance confidence: Automated alerts for expiring permits/documents
• Scalable operations: Company can grow without operational breakdown

Business impact:

• No more lost opportunities: Sales pipeline tracks everything
• Reliable scheduling: Conflicts detected, visits confirmed
• Faster invoicing: Automated from completed services
• Improved collections: Systematic follow-up on overdue accounts
• Compliance assurance: Never miss expiring permits or documents
• Operational efficiency: One system instead of dozens of spreadsheets

What this proves:

• Boring tech works: Meteor.js + MongoDB still running 10 years later
• Solo developer can ship: 91k LOC proves scope doesn't require teams
• Internal tools matter: Good operations software is competitive advantage
• Incremental delivery wins: Rolled out module by module, not big bang
• Domain knowledge wins: Understanding pest control operations was key

What I'd Improve Now

If I were rebuilding today:

1. Add automated testing: At least integration tests for critical workflows

   • Service creation → scheduling → execution → invoicing → collections
   • Document generation accuracy
   • Role permission enforcement
   • Data integrity across modules

2. API layer: Separate business logic from UI

   • Enable mobile app development
   • Allow third-party integrations
   • Easier to test in isolation
   • Future-proof for frontend rewrites

3. Better logging and monitoring: Structured logs, error tracking

   • Winston/Pino for structured logging
   • Sentry for error tracking
   • Performance monitoring for slow queries
   • Audit trail for compliance

4. Database migrations: Proper migration system

   • Version control for schema changes
   • Rollback capability
   • Safer deployments

5. Modular architecture (within monolith): Better code organization

   • Separate concerns by domain
   • Shared utilities and types
   • Clearer dependency graph
   • Easier to reason about

6. TypeScript: Type safety for complex domain model

   • Catch errors at compile time
   • Better IDE support
   • Self-documenting code
   • Safer refactoring

But honestly?

For a 10-year-old internal operating system serving a multi-region company, the current setup works. It's been profitable, reliable, and has scaled with the business.

The key lesson: Sometimes "shipped and working" beats "architecturally perfect."

Technical Deep Dive

Database Design

33 collections organized by domain:

Commercial:

• Leads, Opportunities, Quotes, Customers, Contracts

Operations:

• Services, Schedules, Technicians, ServiceExecutions, Certificates

Finance:

• Invoices, Payments, Collections, AgingReports

Inventory:

• Products, Stock, Movements, ControlledSubstances

Compliance:

• Documents, Vehicles, Permits, Inspections

HR:

• Employees, Contracts, Training, Evaluations

Performance Optimization

84 indexes strategically placed:

• Compound indexes for frequent queries
• Text indexes for search functionality
• Sparse indexes for optional fields
• TTL indexes for temporary data

Automation System

7 cron jobs running daily/hourly:

1. Unresolved alerts: Notify managers of pending issues
2. Overdue collections: Daily reminders for past-due invoices
3. Document expiration: Weekly warnings for expiring permits
4. Schedule consistency: Hourly check for conflicts
5. Stock alerts: Low inventory warnings
6. Service reminders: Next-day service confirmations
7. Daily summary: Operational snapshot for management

Document Generation

Automated PDF/DOCX generation:

• Quotes: Professional proposals with pricing, terms, signatures
• Contracts: Legal service agreements with auto-filled terms
• Certificates: Compliance documents with service details
• Invoices: Official billing documents with legal requirements
• Reports: Custom exports in multiple formats

Why This Matters

Internal operations software rarely gets recognition, but it's the backbone of how businesses run.

Matabichos Workflow isn't just code—it's:

• The difference between chaos and clarity
• The foundation for scaling operations
• The reason compliance doesn't keep anyone up at night
• The system that lets management focus on growth instead of firefighting

10 years later, still running, still delivering value. That's success.

Tech Stack

• Frontend: Blaze templates (Meteor)
• Backend: Meteor.js (Node.js)
• Database: MongoDB (33 collections, 84 indexes)
• Documents: PDFKit (PDF), Docxtemplater (DOCX)
• Hosting: DigitalOcean
• Deployment: Meteor Up (mup)
• Automation: Meteor Cron Jobs

Key Stats

• 91,000 lines of code
• 33 collections
• 84 indexes
• 37 publish endpoints
• 22 workflow routes
• 7 cron automations
• 11 integrated modules
• 10 years running
• 1 developer

This is what solo-developer scale looks like when you solve real problems for real businesses.