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.
ScyllaDB, PostgreSQL, 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 — one shipping, one nearly.
Policy-driven protection for databases and machines, with an inspection layer that lets you open a recovery point and read what is actually inside it.
A desktop IDE for network engineers — the working environment that vendor web consoles never quite became.
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.
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.
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.
What is nearly ready.
A platform to design, a system to rescue, an estate whose backups nobody has opened — or an early look at NetIDE. All of it starts with the same conversation.
Email us — contact@daydev.orgDaydev Labs · Rua Cravos, 3080-098, Portugal