About
Bradley Hanson
- Role
- Software Engineer II, Microsoft
- Team
- Dynamics 365 Contact Center
- Based
- Greater Seattle Area
- Education
- Bachelor of Science, Software Engineering, University of Wisconsin–Eau Claire. Minor in Economics.
I'm a full-stack software engineer in the Seattle area. I've worked on Microsoft products since 2016. I started as a vendor engineer through Mindtree, took ownership of an internal app's frontend, and that work got me hired at Microsoft full time in October 2018. Today I'm on Dynamics 365 Contact Center, working on the Live Chat Widget that businesses put on their websites and its integration into Copilot Studio.
Frontend taught me to like change. Before AI, frontend developers complained all the time about how fast the ground moved: a new framework, a new major version, a new build tool every year. I enjoyed it. Learning the new thing was part of the job. AI has brought that pace to the whole industry, and backend engineers can't wait it out either. I already worked across the stack, so the same habit now lets me take on work anywhere in the product.
I build with AI coding agents every day. I've worked with Claude Code, Cursor, Grok Build, and GitHub Copilot's CLI and coding agent, and I pick the tool and the model for each job, then change them when something better ships. That's how I joined Dynamics 365 Contact Center in January 2026 and was soon shipping in code I'd never seen: Copilot Studio's monorepo, the admin center's older React stack, and C# services I hadn't worked in before.
Speed only counts if the code holds up. At work I've put real time into the guardrails that make agents useful on a team: architecture rule files, agent skills, tests that gate releases, and a weekly check for architectural drift. When I moved on from the agent desktop, the larger team that took it over kept building on that foundation.
I also build a lot outside of work. The Sub Delta is a music-discovery app for SoundCloud that I've been rebuilding since 2015, and the latest version produced three open-source TypeScript packages. Civic Maps is about a question that should be easy to answer: who governs a given place? When I got married in 2026, I built our wedding website and its RSVP system myself. This site was built the same way, with AI coding agents.
How I got here
My first paid software work came from fixing a computer. In college I rented from a small, family-run property company near campus. They called about a problem with their office computer, I fixed it in about ten minutes, and they offered me a job. For the rest of school I built their mobile-first listings website and the spreadsheets that ran their office, along with leasing, showings, and the books.
My first engineering job came from a detour. At a hiring event, the recruiters from the company I'd come to see were busy, so I started talking to the next table over. That conversation turned into an offer from Mindtree, which sent new graduates to its training campus in Bhubaneswar, India, for three months of self-directed study. I focused on full-stack .NET, worked through real culture shock, and came back better at adapting than when I left.
Then I moved to the Pacific Northwest and started on-site at Microsoft in Redmond as a vendor. I've worked on Microsoft products ever since.
What I keep coming back to
- Music and audio technology
- The Sub Delta and the SoundCloud libraries it runs on.
- Civic technology
- Civic Maps, and the public data behind it: Census geography, Congress.gov, Open States.
- Developer tooling
- SDKs, test architecture, release workflows, and rules that help AI agents follow a codebase's conventions.
- Product design
- The details that decide whether something feels finished, like dark-mode authoring for a chat widget or a rating dialog that works with a screen reader.
- Automation
- On-call tooling at work, and scheduled ingest jobs that keep Civic Maps current.
- AI and how coding is changing
- I try new agents and models as they ship and keep what works, at work and on every side project here.
Lessons I've kept
Each of these started as something I got wrong. What matters is what changed afterward.
Unit tests aren't the release gate
My first big customer-facing release, a rewrite of an Azure portal extension, went out with a few bugs that unit tests had no way to catch. They lived in how the pieces fit together.
I made end-to-end tests a release gate there, and on my next greenfield project I set up a three-tier Playwright suite before launch.
Split security fixes along package lines
A security fix that touched several packages at once had to be reverted, and work stacked on top of it came out with it.
I now split fixes like that by package so each one ships and rolls back on its own. The security fixes I shipped after that went out without a revert.
Don't lazy-load anything that listens
I lazy-loaded a voice module to shrink a bundle. It subscribes to call events the moment a call arrives, so loading it late meant missing events. I reverted it two days later.
I wrote the rule into the team's coding guidelines, where both people and AI agents read it: no dynamic imports on real-time event paths.
A fix gets the same flag as its sibling
I shipped a fix for customer-visible text without a feature flag, while the matching change it belonged with was behind one.
I reverted it on three release branches before any customer reported it, then shipped it again behind the same per-customer flag. Now a fix to shared, visible behavior goes behind whatever flag its sibling uses.
The work behind all of this is on the work page.
Contact
Get in touch
I'm interested in senior product engineering work where the UI, the SDKs, and the services behind them are one problem. Email is the fastest way to reach me.