Before DarDev Services quotes a DevOps engagement, we run a structured discovery call—not a sales pitch. The goal is to learn how your team ships software today, what breaks when it breaks, and what constraints (budget, compliance, Tunisia hosting) shape realistic delivery. Good scoping prevents the classic failure mode: a six-month Kubernetes migration proposal for a team that still deploys via SSH and has never tested a database restore.
This guide lists the discovery questions we ask on every DevOps scoping conversation—stack, deploys, backups, on-call, budget, and Tunisia-specific constraints—so you can prepare before talking to DarDev Services or run the same checklist internally.
Current stack: what actually runs in production
We start with an inventory, not pitch-deck diagrams. Where do workloads live—OVH VPS, AWS, Azure? How many environments exist and do they differ meaningfully? We ask for runtimes, databases, queues, and whether anything still runs without containers.
- Source control: GitLab, GitHub, Bitbucket—and who has admin access
- CI/CD: GitLab CI, GitHub Actions, Jenkins, or manual scripts
- Runtime: Docker Compose, systemd services, Kubernetes, serverless
- Edge: nginx, Traefik, cloud load balancer, Cloudflare proxy
- Data stores: Postgres, MySQL, Redis, object storage—and who owns schema migrations
We also ask what is out of scope for the first phase. If you are on Compose today, our compose-to-kubernetes-migration guide describes when a move makes sense versus when hardening the VPS stack is the honest answer.
Deploy process: from commit to production
Walk us through the last production deploy step by step. We want branch strategy, staging usage, deploy duration, and rollback time. Manual steps are data—we count them and estimate automation ROI.
Critical follow-ups: Can you roll back in under thirty minutes? Do migrations run automatically? Are secrets injected at deploy time? We document the happy path and the last failed deploy—failures reveal more than success stories.
Backups and recovery: prove it, do not assume it
Every team says they have backups. We ask when someone last restored one. For databases: schedule, retention, off-site copy, encryption, and who holds restore credentials.
We ask about RPO and RTO in plain language. Many teams target four-hour RPO without a successful restore on record. Discovery is where we schedule a drill before quoting automation on top of untested dumps.
On-call and incident response
Who gets paged at 2 a.m.? We ask for the last three incidents: detection, time to mitigate, and whether a runbook existed. Telegram and WhatsApp forwards count as alerting—we note gaps to size observability work.
For teams without formal on-call, we discuss a lightweight rotation before instrumenting dashboards nobody watches. Our oncall-runbook-template article shows the minimum structure we expect after a kickstart.
Budget, timeline, and internal capacity
DevOps consulting scoping fails when budget and ambition mismatch. We ask for a monthly consulting budget range and whether it is OPEX or tied to a funding milestone. Fixed-price vs time-and-materials preference matters: we often propose phased fixed scopes after a one-week paid assessment when the stack is unknown.
- Internal champion: who owns outcomes after we hand off?
- Developer availability: hours per week for pairing and review
- Hard deadlines: fundraising due diligence, enterprise customer go-live, regulatory date
- Build vs buy: managed Kubernetes, observability SaaS, or self-hosted open source
We are explicit about what a given budget buys. The observability-kickstart-engagement outline describes a bounded first phase many teams use to de-risk a larger commitment.
Tunisia context: hosting, connectivity, and compliance
Tunisia-based teams face constraints generic playbooks skip. We ask where primary data must reside—EU OVH is common—and whether customers require a subprocessor list. Bandwidth to EU regions affects backup windows and replication.
Local hiring matters: can your team maintain Kubernetes after we leave? If the product touches TTN e-invoicing, we treat fiscal uptime as a separate track—as in our case-study-platform-hardening-tn write-up.
What you receive after discovery
Within a week we deliver a written scope: current-state summary, prioritized gaps, phased recommendations, effort range, and out-of-scope items. Quick wins (TLS, backup test) sit apart from strategic bets (cluster migration).
To start a discovery conversation, contact DarDev via dardev.net/services with your stack summary and biggest operational pain. Attach architecture sketches even if they are outdated—wrong diagrams spark useful corrections.
How long does discovery take?
One to two working sessions (90–120 minutes each) plus async review of configs and pipelines. We schedule a restore drill separately if needed.
Is discovery free?
Initial fit calls are free. Deep dives with written deliverables are a paid assessment—credited toward the engagement when you proceed with DarDev.
What if we are still on manual SSH deploys?
Common for Tunisian SMEs. We scope CI and staging first; Kubernetes only when traffic and team skills justify it.
Do you require Kubernetes?
No. We operate Kubernetes for our own products but right-size client stacks. VPS plus Docker plus GitLab CI is often enough.
How does Tunisia data residency affect scoping?
We document where data lives, backup locations, and subprocessors. EU hosting on OVH is typical; we align recommendations with your customer contracts.
What should we prepare before the call?
Architecture sketch, last deploy steps, backup schedule, on-call contact list, and monthly budget range.
