About
A small studio with an unreasonable amount of infrastructure experience
Drozan exists because two things turned out to be the same skill: building software people rely on, and building the systems that keep it running.
Who you would be working with
Drozan is led by a Lead DevOps Engineer with 8+ yearsspent in the part of engineering nobody sees until it fails: the pipelines, the clusters, the networks and the bills.
That has meant building cloud platforms from an empty account, taking clusters through upgrades without downtime, cutting build times from half an hour to a few minutes, and reducing cloud spend by re-architecting rather than by switching off things people needed.
When you hire Drozan you get that engineer, not a bench. There is no account manager, no junior doing the real work, and no deck that arrives three weeks after the kickoff. Work lands as pull requests in your repositories from the first week.
Why the apps?
Building and shipping our own mobile products keeps the practice honest. It is easy to recommend a release process you never have to live with. Running our own Play Store releases, our own on-call and our own cloud bill means the advice we give clients has already been paid for once, by us.
At a glance
- Practice lead
- Lead DevOps Engineer, 8+ years in production
- Based
- India · remote worldwide
- Works with
- Startups and scale-ups, seed to Series C
- Contact
- hello@drozan.com
Principles
How we think about the work
These are not posters on a wall. They are the reasons we say no to certain designs.
Infrastructure as code, always
If it is not in a repository with a review history, it does not exist. Click-ops is a migration, not a destination.
Boring technology wins
Reach for the proven tool your team can operate at 3am, not the one that looks best in a conference talk.
Automate the second occurrence
Do it once by hand, document it the second time, automate it the third. Premature automation costs as much as none.
Cost is a design constraint
An architecture nobody can afford to run is not an architecture. Bills belong in the design review.
Leave the team stronger
The measure of a good engagement is that the client does not need a second one for the same problem.
Blast radius before velocity
Ship fast, but know exactly what breaks when it breaks, and how quickly you can put it back.
Toolbox
What we actually run in production
Listed because it is useful to know, not because tooling is the point. The right answer is usually the one your team can already operate.
Cloud
Orchestration
Infrastructure as code
Delivery
Observability
Data & runtime
Tell us what is breaking.
A slow pipeline, a cloud bill nobody can explain, a cluster that only one person understands. Send the details and you will get a straight answer on whether we can help.