Most cloud problems aren't cloud problems
After fifteen years of getting called in to fix cloud projects, we’ve learned the hard part is rarely the technology. More often it’s a decision nobody wanted to make, or a difficult conversation nobody wanted to have, and no tool fixes that.
We’ve watched plenty of smart teams try anyway. They reach for whatever’s trending on Hacker News because adopting a new tool feels like progress when the harder problem doesn’t. Or they hope a migration will quietly fix a deeper problem, and the new platform just inherits the old habits. It’s an easy trap to walk into when you’re heads-down trying to ship code.
What we actually do is help good teams get unstuck and over the finish line. We care more about what your business needs than about whether the architecture would impress other engineers, and we’ve talked clients out of the fancier option more than once when the plainer one served them better (looking at you, Kubernetes).
Who we’re good for
We’re a good fit for product and engineering teams with a real production problem to solve: a migration that has stalled, a platform that has grown too fragile, a security or reliability bar that has moved higher, or a system that needs to scale without becoming harder to operate. We take the work seriously and own our part of it; but don’t think that being skilled requires being difficult to work with. One of our core values is “Empower Others” and if we’re not the right fit, we’ll tell you early rather than sell you something that won’t help.
We’re not the people you should call if you need a deep bench of staffers to lift-and-shift hundreds of applications out of a datacenter. We focus on very specific, high-value outcomes where we can use our extensive experience and automation toolbox to do amazing work quickly.
We’re based near Ann Arbor, Michigan and work with clients all over the world. Most engagements are with distributed teams these days, though we’ll happily fly wherever Delta will take us.
Why teams trust us
We were one of the first couple dozen companies AWS recruited into its Consulting Partner program, in 2012, back when the cloud was still something you had to talk people into. We advised on its first certification exams and helped shape AWS’s early DevOps tooling under NDA. And once, after a client’s system nearly took down an entire AWS product, their product manager phoned us directly. You don’t get that call from reading the documentation.
Microsoft recruited us into its Azure program in 2015, where we were the first partner to complete a project on the then-new Azure Cloud Solution Provider (CSP) channel program. We joined Google’s network in 2022, after we started to encounter more GCP workloads in the wild.
Also back in 2012, we founded AWS Michigan, the longest continuously operating AWS user group in the country, and out of it launched DevOpsDays Detroit, a two-day annual conference that is now its own independent non-profit.
We’ve stayed small and specialized on purpose, betting our reputation matters more than our headcount. We’re engineers at heart, and the big, hairy problems are the ones we actually enjoy. While cloud skills are everywhere now; the depth and tenacity to solve real engineering challenges still aren’t–which is mostly why people still call.
The best version of this job, for us, is the one the MIHIN team put better than we could: a partner confident enough to share everything it knows, take on the problem you’re not ready for, and hand the knowledge back so your team is stronger when we leave. We’d rather make ourselves unnecessary than indispensable.
One question worth asking
Put this to any consultant you’re weighing, us included: how will you measure whether this worked? If the answer is a vague gesture at total cost of ownership, keep looking. We’ll tell you what we’d measure, in numbers that matter to your business, before we start.