Architect in the Cloud

Hi, I'm Steve. I write here because I like building things, I like figuring out why systems behave the way they do, and I've learned (sometimes the hard way) what makes software easier—or harder—to live with over time.

I've been working in tech for 20+ years, mostly in roles where I'm responsible not just for getting something shipped, but for making sure it keeps working when requirements change, traffic grows, and "edge cases" stop being edge cases. A lot of my work lives in the overlap between architecture and delivery: helping teams make good choices early, and then making those choices real in code and implementation.

This site is where I collect what I'm learning and what I've learned—especially the practical stuff that doesn't always show up in official docs or neat diagrams.

What I write about

Most posts here land in a few buckets:

• Architecture in real life — how to think through tradeoffs, where complexity sneaks in, and what I look for when reviewing designs.
• Cloud and platforms — the patterns that tend to work, the ones that cause pain later, and how to keep systems understandable.
• Salesforce — especially when it has to play nicely with everything else in an organization.
• Python — automation, quick tools, and the kind of scripting that saves time and removes manual work.
• AI (when it's actually useful) — what's worth paying attention to, and what's just noise.

How I think about this stuff

I'm not trying to build perfect systems. I'm trying to build good systems—things that are reliable, maintainable, and clear enough that someone else can take over without needing a two-hour oral history.

When I write about decisions, I try to explain the reasoning behind them: what you're gaining, what you're giving up, and what questions to ask before you commit. Architecture is mostly about choosing which problems you want to deal with later.

A quick note on the writing: I sometimes use AI as a writing assistant to help me get ideas onto the page more clearly, but the substance comes from the systems I've built and the teams I've led.

Why this exists

Honestly, this blog is partly for me—writing forces me to tighten up my thinking. But if any of it helps you avoid a bad decision, speed up a project, or make something easier to maintain, that's a win.

As always, everything here reflects my personal views and experience, not any employer's.