Dioveo started as an irritation. Someone needed every invoice attachment from three years of email, and the options were to click through Gmail for an afternoon or write a script that would break the next time Google changed something.
It is now a product with users, billing, an OAuth relationship with Google, and a support inbox. That last part is what makes it useful to us as a company: it is the difference between having opinions about production systems and having scars from one.
What it does
You search years of email in plain language, pull every matching attachment at once, and set rules so that new files land in Google Drive, Dropbox, or OneDrive without anyone touching them. There is a web app, a Chrome side panel that sits next to Gmail, and a mobile app.
Underneath: Vue on the front, a service layer on Kubernetes, Temporal for the long-running work, MongoDB for state, and an OCR service for reading the documents that arrive as scans.
The parts that were harder than expected
Long-running work is a different kind of problem. A user asking for eight years of attachments is not a request, it is a job. It can run for many minutes, it will hit rate limits, tokens will expire mid-flight, and the user will close the tab. We started with a queue and retries and moved to Temporal, because what we actually needed was durable execution — a workflow that survives the worker dying halfway through and picks up where it left off. Retry logic scattered across a codebase is a sign you needed workflows two months ago.
Third-party rate limits shape your architecture. Gmail's quotas are not a detail to handle at the edges; they determine your concurrency model. We rewrote the fetching layer twice before accepting that the API's limits, not our compute, were the thing to design around. This is the single most common mistake we now look for when reviewing other teams' integration code.
OAuth scope review is a product constraint. Asking Google for access to someone's mail means a security review, and the scopes you request shape what you are allowed to build. That is a conversation to have before the roadmap, not after. We have since saved two clients a quarter each by raising it early.
Most of the work is the unhappy path. The demo took a fortnight. The year since has largely been HEIC images, corrupt PDFs, mailboxes with attachments that are technically valid and practically nonsense, expired refresh tokens, and users who revoke access and then wonder why sync stopped. The interesting engineering lives entirely in the cases nobody thinks to specify.
What it changed about our client work
We stopped recommending things we had not operated. It is easy to sketch an architecture on a whiteboard. It is different to be paged by it. Our advice narrowed considerably once we had to live with our own decisions for a year, and it got more useful in the process.
We got specific about observability. Every alert Dioveo has, we have been woken by. That taught us which alerts are worth having and which just train you to ignore your phone. We now set up client monitoring the way we wish we had set up ours: few alerts, each one meaning a human must act.
We learned what handover actually requires. Onboarding a new engineer onto Dioveo exposed every place our documentation said "obviously" about something that was not. The runbooks we write for clients now come directly from what that process taught us.
We treat migrations with more respect. We have moved Dioveo's data between stores under live traffic. The plan did not survive contact with production; the rehearsal did. We do not promise clients zero-downtime cutovers we have not tested against a copy of their data, and that caution is entirely learned rather than principled.
Why we show it
We are not putting Dioveo forward as a portfolio piece. It is a modest product solving a specific, unglamorous problem.
We show it because it is checkable. You can sign up, use it, hit its limits, and email its support address — which reaches the same people who would work on your system. Most engineering credentials cannot be inspected. This one can, and given that transparency is the thing we claim to be built on, it would be strange to ask you to take our capability on faith.
If you have a system with the same shape — long-running jobs, third-party APIs that fight back, a data pipeline that has outgrown its cron job — we would like to hear about it.