A fintech startup in Tunis came to DarDev after their first production incident: TLS expired on an internal admin tool, backups had never been tested, and the founder was still SSH-ing config changes on Friday nights. Six months later they run staged deploys, monitored Postgres, and a written runbook—without doubling headcount.
This case study describes patterns from a real engagement (details anonymized). It is not a sales deck; it is what platform hardening actually looked like week by week.
Starting point
- Single OVH VPS: Node API, Postgres, Redis, nginx
- Manual deploys via git pull and pm2 restart
- No staging; secrets in a shared.env on disk
- Monitoring: founder gets Telegram when users complain
Month 1 — Visibility and backups
We instrumented health endpoints, shipped logs to a centralized sink, and scheduled nightly Postgres dumps to off-VPS storage with monthly restore drill. First restore failed—wrong pg version in script. Fixing that in month one avoided a real disaster later.
Month 2 — Staging and CI
Second small VPS became staging with anonymized data subset. GitLab CI built Docker images, ran tests, deployed to staging on merge to main. Production deploy became manual approval button—not ssh.
- Dockerize services
Eliminated works-on-my-machine between two developers.
- TLS automation
cert-manager pattern via nginx + Let's Encrypt; removed calendar reminder dependency.
- Secrets
Moved to GitLab CI variables and restricted file permissions on VPS.
Month 3–4 — Hardening and runbooks
Fail2ban, SSH key-only, non-root containers where feasible, database connection limits tuned after a traffic spike. Runbooks covered: deploy rollback, DB restore, certificate renewal failure, and how to page the on-call rotation (two devs, one founder).
Outcomes
- Deploy frequency: weekly to daily on staging, weekly prod with confidence
- MTTR for known failures dropped from hours to under 30 minutes
- Passed enterprise customer security questionnaire with documented controls
- Team did not adopt Kubernetes—VPS right-sized for their scale
DarDev Services scopes similar engagements fixed-price after a one-week assessment. DarDevLab alumni sometimes join as part-time ops after training—pipeline we encourage.
What we deliberately did not do
The client asked about Kubernetes early because competitors mentioned it in pitch decks. We ran a one-day sizing workshop and concluded traffic and team size did not justify cluster ops. Saying no saved budget for staging and backup drills that actually reduced incident frequency.
We also refused to migrate TTN invoicing logic during the same window—that integration stayed on Hesabi with its own release cadence. Platform hardening and fiscal features compete for the same two developers; sequencing matters.
Incident before vs after
Before: Postgres disk filled during a marketing push; team deleted random files via SSH. After: disk alerts at seventy percent, autovacuum tuned, connection pool limits documented. Same VPS class—different operability.
Before: certificate expiry took down admin panel for six hours on a Sunday. After: automated renewal with monitoring on expiry date minus fourteen days. Founder still gets Telegram, but now with runbook link and rollback command.
Metrics the board cared about
- Successful restore drill date (monthly)
- Mean time to rollback after bad deploy
- Percentage of deploys via CI vs manual SSH
- Open critical security findings count
Uptime vanity numbers matter less than provable recovery. Enterprise prospects in Tunis asked for backup policy in writing—we could answer with dates, not intentions.
Team morale improved when Friday deploy fear disappeared. Junior devs stopped waiting for the founder to SSH fixes; staging reproduced bugs first.
Six months is a realistic minimum for this depth on a four-person eng team with day job feature work. Faster timelines skip restore drills and recreate the original risk.
Handoff to client team
Final month focused on documentation and shadowing: client devs ran deploy and restore with DarDev watching. Runbooks lived in their GitLab wiki with screenshots of CI buttons—not PDFs that rot. Access reviews removed DarDev SSH keys except break-glass break-glass account with logged usage.
Quarterly check-ins optional under retainer—many clients self-sufficient after handoff when staging parity holds.
Platform hardening is not glamour work; it is what lets Tunis fintech and SaaS startups pass enterprise security reviews without hiring a full SRE team on day one.
Lessons transfer to other OVH-hosted stacks: same backup discipline, same staging-first deploy culture, same refusal to bolt fiscal integrations onto infra sprints without capacity planning.
If your team still SSHs production for config edits, start with visibility and backups before buying Kubernetes—hardening fundamentals pay off regardless of orchestrator choice.
Security questionnaire answers improved because we could attach runbook excerpts and CI screenshot timestamps—not because we purchased a compliance SaaS badge.
For similar TN startups, budget one senior DarDev Services day per week for six months or equivalent internal champion time—sporadic consulting without owner on client side rarely sticks.
Contact DarDev via dardev.net/services with your current architecture diagram to scope an assessment.
Cost vs new hires?
Fraction of a senior SRE salary for six months; client kept two junior devs and added process.
Kubernetes needed?
Not for this client. Honest sizing beats trend-chasing.
Tunisia data residency?
Kept primary DB on OVH EU region per client contract; document subprocessor list.
TTN integration impact?
Separate concern—billing uptime improved indirectly via better deploy discipline.
Engage DarDev?
Contact via dardev.net/services with current architecture sketch.
