The Stack Is the Most Replaceable Thing on My Resume

The most replaceable thing on my resume is the list of technologies on it.

I've been building software for about twenty years. Started in mobile before the App Store existed, and 25+ shipped apps later, the work has almost nothing to do with what I used to open Xcode to do. Enterprise platform architecture. Establishing engineering practice on teams that have none. Sitting between the people writing the code and the people funding it, making sure both sides are solving the same problem.

Nobody handed me that expansion, and I can not point to the week it happened. What I can tell you is which parts of those twenty years actually transferred. It was not the languages.

Full-stack before it was a job title

The ladder, stated plainly. iOS in the early days of the App Store. Full-stack before "full-stack" was a common thing to put on a business card. DevOps before most small teams thought they needed any. Then architecture. Then leading the people doing all of it.

Junior engineer, lead, hiring manager, systems architect, and eventually fractional CTO work with early-stage startups. Each of those rungs looks like a different job from the outside. From the inside they were the same job with the blast radius turned up.

And that last rung is the one that changed how I see the rest. When you're responsible for how a team hires, how it's structured, how it grows, and how it ships, you stop evaluating decisions one at a time. You start seeing the pattern underneath them. The specific technology in front of you becomes the least interesting variable in the room, because you've watched the same category of decision go right and wrong across roughly a dozen global corporations, in languages that had nothing to do with each other.

Same debt, opposite answer

Here is the clearest example I have.

At Nelnet I inherited a massive Objective-C codebase for community outreach. Real debt, the friction kind, the kind that taxes every change you make. The obvious move is a migration project. I didn't run one. The rule was that you migrate the file you're already touching, inside the same pull request, and you do not open a refactoring sprint. Build times came down ninety percent on the way through. Ninety percent. Nobody ever scheduled a quarter to make that happen.

At SAMi Alert I looked at a legacy Objective-C architecture and came to the opposite conclusion. That one could not support the features on the roadmap. Not "would be annoying to extend." Could not. So it got a full rewrite into SwiftUI, scoped as its own initiative, with an actual business case attached to it.

Same language. Same debt on paper. Opposite correct answers.

Nothing about Objective-C told me which was which. What told me was the shape of the roadmap, what the business needed in the next two quarters, and how much of the existing system was load-bearing versus merely old. That judgment is portable. It works the same way on a TypeScript service or a Python backend, and I have used it on both. The language was never the thing being evaluated.

Defaults age out quietly

I'm not going to pretend the judgment is always on. Not long ago a hiring manager asked me what I'd build a new API in and I said "Ruby on Rails" out loud, in 2026, because some part of my brain still lives in 2016. I wrote about that whole moment already.

The useful part is what expired. Not a skill. An answer I had stopped re-examining. Rails was a genuinely good default for a long time and it aged out while I wasn't looking, the way PHP did, the way Perl did before it.

That's the failure mode of building an identity around a stack. The stack keeps moving whether or not you re-evaluate it, and if your value is the stack, your value moves with it.

The parts of the job with no code in them

The work I get called for now is mostly not writing software.

I've walked into an organization with two vibe-coded apps and no engineering process at all and turned it into something that could scale and survive an audit. Environment separation. CI/CD. Testing standards. Code review that means something. Practices that hold up when a company is on an IPO track and somebody external starts asking how the software gets built.

None of that is a language. You can not express any of it in a stack list, and it is the highest-leverage thing I do.

Same with the design conversations. I've written before about what skipping architecture reviews actually costs, and the number that sticks with me is a data-integrity bug that a review caught in twenty minutes. Twenty minutes in the design phase, against weeks of unwinding it in production. The technology was irrelevant to both the mistake and the catch.

And the same again with incidents. Knowing who has authority when something is on fire, and having the standing to say the documentation can wait until it's out, is worth more in the moment than any framework expertise anybody on the call has.

What actually carried

The clearest proof I have is a thing I built for myself.

Brickanize is a LEGO collection app, and it is the one place where every call is mine. Product decisions, architecture, two native clients, an API, the cloud infrastructure, the release pipelines, the store listings, the privacy filings, the trademark. Over four thousand automated tests across three codebases. Four thousand.

I could tell you it's Swift and Kotlin and Python, and that would be true and almost entirely beside the point. I did not know FastAPI particularly well before I needed a service that could hold API keys the clients had no business holding. I learned it because the architecture demanded it. The architecture came first and the technology showed up to serve it, which is the same order those two things have arrived in for twenty years.

That's the whole transition, honestly. I did not stop being an iOS engineer and become something else. I kept solving problems that got progressively less bounded, and the tools kept changing underneath to match. Mobile taught me constraints. You ship to devices you can not patch on demand, through a review process you do not control, to users who will never update. That teaches you to think about failure modes and blast radius and what happens when your assumption is wrong, and none of that knowledge stayed on the phone.

So when somebody asks what I work in, the honest answer is that the question is aimed slightly off target. Every technology on my resume is something I picked up because a problem needed it. The problems are the career. The list is just the receipt.