- ~$30Ksaved by replacing a third-party CRM
- 20%fewer missed or late activity reports
- 80+stakeholder requirements turned into one schema
- 20+modules, with audit logs across 8+ of them
What I built
An internal CRM and management reporting platform for a medical device exporter's international sales organization, replacing fragmented Excel workflows with one centralized data structure.
I gathered 80+ requirements across international sales, regional management, product registration and compliance, then turned them into a unified schema and KPI reporting logic. The result is 20+ modules covering leads, customer interactions, exhibitions, shipments, payments and regulatory activity, with management dashboards on a lightweight SQL reporting layer, audit logging across 8+ modules, and permission-scoped visibility driven by a recursive CTE over the org hierarchy. Deployed with Docker on a cloud VPS, with a separate demo instance for evaluation.
It replaced a third-party CRM, saving roughly USD 30K upfront plus annual maintenance, and cut missed or late activity reports by 20%.
How I used AI
I split the work by what each side is good at. AI coding tools handled implementation; I kept architectural decisions, edge-case judgment, and the deployment gate. Every change was reviewed and approved by me before it reached the server, and I spread the build across sessions rather than trying to one-shot it, because the failures that matter surface on the second pass.
In practice, AI moved fast on modules, schema changes and refactors, while I decided where to draw the demo/production boundary, when to promote a shared utility into a central file, and which "correct" architecture to skip.
What I learned
Production isolation is a verification step, not a preference. A demo clear-and-reseed once reset roles and passwords to code defaults. After that, every deployment was checked against a config endpoint plus database spot-checks before I called it done.
Pragmatic beats architecturally correct at this scale. I chose a per-module strings dictionary over a full i18n framework, and runtime demo/production branching over build-time environment separation. Both are wrong in a textbook sense; both were right for a system one person maintains.
The operational surface is where the time actually goes. Cloud firewall rules that silently fail to sync, intermittent TLS on git pulls, permission logic that has to be enforced at the UI and the backend — none of it is in the feature list, and all of it is what shipping means.
Try it
Demo instance, seeded with sample data — no real customer information. Served over HTTP on a non-standard port, so your browser will flag it as not secure.