LOG // PROJECTS
Projects
Real problems. Real solutions. Click any card to see the full story.
Multi-Tenant SaaS · Practice Management
Harbour
Type: Multi-Tenant SaaS
Status: Live · Private Beta
Market: Mexico · SMB Services
Source: Proprietary
Running the Whole Business
Harbour is practice management for Mexican service businesses — barbershops, dental offices, clinics, salons. The dashboard opens on the numbers that decide the day: revenue collected, tickets still unpaid, stock about to run out, who is coming in at 2:30. Booking feeds that picture, but the product is everything that happens after the appointment is made — the cash register, the inventory, the client history, the staff kiosk. Every business is its own tenant behind its own slug, with its own branding, timezone, catalog, team, and payment account.
Isolation the Build Refuses to Break
In a multi-tenant system, one leaky endpoint exposes every customer at once. Every authenticated query is scoped to the requesting user before it touches the database, so a tenant who guesses a competitor's slug gets a 403 — never their data. What makes that hold over time is a sweep in the test suite that walks every route mounted under a tenant slug and fails the build if a new one appears without being declared either scoped or deliberately public. Adding an endpoint and forgetting to secure it is not a code-review catch here; it is a red pipeline, and a red pipeline means no deploy.
The Business Keeps the Whole Deposit
Deposits are collected at booking through Stripe Connect, into an account that belongs to the business — not to a platform wallet. Harbour charges a monthly subscription and takes zero commission per transaction, so growth costs the client nothing extra and the incentives never drift apart. Card fees are absorbed by the business rather than passed to the customer, which is not just a courtesy: surcharging card payments has been illegal in Mexico since the 2024 consumer-protection reforms. Money moves as Decimal with half-up rounding, and deposits land on whole pesos so nothing at the counter ends in cents.
A Pricing Model That Survived Its Own Math
Messaging is the only cost that grows with every single appointment, which makes it the one line item that can invert a flat subscription. Priced against the real AWS tariffs, an SMS segment to Mexico runs $0.10 USD against $0.0115 for the same message over WhatsApp — 8.7x, and Mexico is 8.4x more expensive for SMS than the US, so every playbook written for that market misleads here. At the top plans, SMS would cost more than the plan charges: the better the client does, the more money the platform loses. So WhatsApp is the primary channel and SMS is the fallback, and skipping re-verification for a phone the business has already confirmed cuts the per-appointment message count nearly in half. That is architecture answering to a spreadsheet, not to taste.
The Stack Behind It
Django 6 and DRF run under Gunicorn and Nginx on EC2, with managed RDS MySQL on its own host and S3 for tenant media; the Next.js 16 App Router frontend ships to Vercel's edge. The API and the app live on separate subdomains, which makes strict CORS the first wall rather than an afterthought. Auth is JWT with short access tokens and a module-level refresh queue — when five calls hit a 401 at once, one refresh fires and the rest park and retry, instead of five racing requests invalidating each other and logging the user out mid-task. Rate limits are enforced twice, at the DRF scope and again at the Nginx zone, and a 429 comes back as a countdown the user can read. Every push to main runs pytest, tsc, lint and vitest before anything reaches production.
Tech Stack
Django 6 DRF Next.js 16 React 19 TypeScript AWS EC2 · RDS Stripe Connect WhatsApp API
