Software engineering · disaster recovery
Daydev Labs is a software engineering studio working in Go and Rust on the parts that have to stay up: platforms, APIs, data pipelines and infrastructure. We also ship our own products — because running what we build is the fastest way to find out whether it is any good.
Most of what we are asked to build is not a greenfield demo — it is the system underneath something that already has users, an on-call rota and a bad week in its history. So we work the way that survives that: every service ships with metrics, tracing and structured logs on day one, every interface is documented before it is depended on, and nothing goes out that the team who inherits it cannot operate without us.
Full-lifecycle engineering — from the architecture conversation to the thing running in production with someone watching the dashboards.
Backend platforms, internal tooling and consumer-facing applications, built in Go and Rust with React or Flutter on the front. Enterprise ERPs, automation systems, high-throughput services — at whatever scale the problem actually has.
The layer everything else hangs off. gRPC, REST and SOAP where you have to, GraphQL where it earns its place, and streaming through Kafka or NATS when the data will not sit still.
Design, migration and replatforming across AWS, Azure, GCP and Oracle Cloud — and on-premises with VMware, Nutanix, OpenStack or Hyper-V when the workload is not going anywhere.
CI/CD, infrastructure as code, secrets management and threat detection built into the delivery pipeline rather than bolted on after the first audit finding.
PostgreSQL, ScyllaDB, MongoDB and Redis in the shapes that survive growth — with schema migrations that are versioned, reversible and refuse to serve a half-applied state.
Prometheus, Jaeger, Grafana and Alertmanager wired in from the first commit, with the documentation to match. A system nobody can see inside is a system nobody can fix at 3am.
Model-backed features built like any other production dependency — with evaluation, cost control, fallback behaviour and a clear answer to what happens when the provider has an outage.
Short, honest spikes on the questions that decide an architecture. We would rather spend two weeks proving an approach cannot work than eighteen months discovering it.
Four habits that decide whether a project is still healthy a year after we leave.
Not the feature list — the thing that actually limits you. Latency, compliance, a database that cannot be migrated during business hours. The constraint shapes the architecture; everything else is preference.
One path through the whole system, in production, early. It is the only way to find out what the integration really costs before the estimate has hardened into a commitment.
Metrics, traces and logs are part of the feature, not a follow-up ticket. If it ships without them, nobody will know it is degrading until a customer says so.
Runbooks, architecture notes and a team that has operated the system before we step back. The goal is a codebase you own, not a dependency on us.
Our own products
Two products out of our own practice — both licensed, both running, one still in early access.
Policy-driven protection for databases, machines, network gear and cloud accounts — with recovery plans you can rehearse and an inspection layer that lets you open a recovery point and read what is actually inside it.
A desktop workspace for network engineers — the working environment that vendor web consoles never quite became. Licensed builds for macOS, Windows and Linux; nothing in it is simulated.
Inside the DR platform
Every backup tool reports that a job succeeded. Ours lets you check what the job captured — reading into the archive itself, so coverage stops being a number you trust and becomes one you can verify. Compare a file across two recovery points, browse an archive a directory at a time, or search the contents of several points at once.
An edit that preserves both size and modification time would otherwise read as unchanged. When a hash is unavailable, the console says it fell back rather than presenting the weaker check as the same answer.
A search reports a binary file as binary rather than passing over it, says when only the head of a file was read, and names the recovery points that failed to answer at all. Only one of those two answers is safe to act on.
Demo fixtures render in the demo account and nowhere else. A live session that cannot reach the backend shows an error, never something that looks plausibly like your estate.
Inspecting a failed run is refused outright, because an empty file listing reads as "nothing was backed up" — the one sentence a DR console must never say by accident.
Inside the DR platform
Getting the data back is the easy half. The rest is a sequence somebody has to perform correctly on the worst day of their quarter — so the platform holds that sequence, runs it on your agents, and lets you rehearse it while nothing is on fire.
Steps are dispatched one at a time, and step n+1 is queued only once step n has actually succeeded. A failed restore stops the plan rather than being compounded by everything after it. Recovery steps are never retried blind — one partial restore is better than two.
Ansible, Terraform and Python, with official blueprints for restoring a PostgreSQL service, quiescing an application, standing up recovery networks and compute, failing DNS over, and verifying what came back. Write your own alongside them.
A rehearsal rewrites every verb to its read-only counterpart before anything is dispatched: Ansible gets --check, Terraform gets plan, and a destroy becomes a plan too — so the rehearsal shows what would be torn down without tearing it down.
A failed backup can start an escalation plan; a recovery point appearing can start the verification one. A deploy pipeline can ask for a backup with one authenticated POST — a backup taken minutes before a release is worth more than one taken six hours earlier on a schedule.
Slack, Teams and signed generic webhooks, queued in a table rather than in memory — because the incident that kills the process is exactly the one somebody needs to hear about. Five attempts with backoff, every delivery stored verbatim, so "did we tell anyone?" has an answer.
Variables reach a step in a private file, never on an argv where the host process table would show a database password to every user on the machine. Secret-typed values are never read back by the API, and an editor that cannot display one cannot clear it either.
Same platform, same console, same agent. The only question is who operates the control plane.
We run the control plane and keep it patched, upgraded and migrated. You install agents and register what you want protected.
One Go binary with a systemd unit, or containers if that suits you better. Your PKI issues both the server and the agent certificates.
What is nearly ready, and what we have deliberately not built yet.
A platform to design, a system to rescue, an estate whose backups nobody has opened — or an early-access licence for NetIDE. All of it starts with the same conversation.
Email us — contact@daydev.orgDaydev Labs · Rua Cravos, 3080-098, Portugal