July, 2026.- Andy Prondak does not think of systems as architecture. He thinks of them as experiences that happen to be made of code. A pure engineer asks, “Is this correct and will it scale?” Prondak asks, “Who is on the other end, and what does it feel like to use?”
In this interview, Prondak discusses his journey from design to engineering and how that design-first lens changes the way he builds systems. The designers who shaped him were rule-breakers. They knew the rules and broke them on purpose, never by accident. You learn the conventions until they are muscle memory, then you earn the right to break them when the work demands it.
Prondak also explains his framework for deciding whether a client’s AI request is a legitimate business problem or just a buzzword-chasing feature. His filter has three questions, and the word “AI” is not allowed in any of them. First: if you describe the outcome without saying “AI,” is it still worth doing? Second: is there a number it moves—time, cost, quality, revenue? Third: is the input actually repeatable? Half the time, the real answer to a business problem turns out to be a clean process and a good spreadsheet, not a model.
On tech debt, Prondak notes that the debt that hurts most in agencies is not in the code—it is in the scope. Work gets priced and committed before the people who have to build it are ever in the room. The first stretch of every build gets spent quietly paying down the distance between what got sold and what the work actually takes. Moving technical understanding upstream, into the moment the scope is being shaped, is a big part of what Instrument is building toward.
Q: From Design to Engineering: You began your career in design before moving into engineering. How does that design-first lens change the way you think about and build systems compared to someone who started as a pure engineer?
A: I don’t think of systems as architecture. I think of them as experiences that happen to be made of code. A pure engineer asks “is this correct and will it scale?” I ask, “Who is on the other end, and what does it feel like to use?”
The designers who shaped me, Carson, Walsh and Dawson, were all rule-breakers. They knew the rules and broke them on purpose, never by accident. That is the lens I bring to engineering. You learn the conventions until they are muscle memory, then you earn the right to break them when the work demands it.
And here is the thing nobody says out loud: almost anything is possible with enough time and money. So the job was never “can we build it?” It is “what is worth building with the time and money we actually have.” That is the whole craft. Correct is not the same as valuable.
Q: “Quiet Tech” That Enables Creativity: What’s an example of something Instrument built that embodied that philosophy? And, how did you measure its effectiveness? What metrics or signals told you it was creating real value?
A: Quiet tech is the stuff that removes a tax nobody admits they are paying. My favorite kind is unglamorous on purpose. Picture the gap between where a design lives and where its content lives. Two systems that have no idea the other exists, with a person stuck in the middle, hand-copying hundreds of strings back and forth and introducing a fresh typo every time they touch it. We closed that gap. The copying just stopped happening. Nobody demos that at an all-hands. It is invisible by design. It quietly deleted a whole category of busywork that used to eat hours of someone’s week, along with the errors that came with it.
How I measure it: I do not chase a hero percentage. Impact is a measurement problem, not a messaging problem. I put real numbers against the actual workflow. Time reclaimed on that specific task, error rate before and after, and the one signal I trust most: adoption with no mandate. When people quietly stop doing it the old way and nobody made them, the tool is real.
Q: AI with Intent: What’s your framework for deciding whether a client’s AI request is a legitimate business problem or just a buzzword-chasing feature?
A: My filter has three questions, and the word “AI” isn’t allowed in any of them.
One: If you describe the outcome without saying “AI,” is it still worth doing? If the value only sounds impressive when the acronym is in the sentence, it’s a buzzword wearing a business case.
Two: Is there a number it moves? Time, cost, quality, revenue. Something we can measure before and after. “It feels innovative” is not a number.
Three, the one most people skip: is the input actually repeatable? AI loves a pattern. The real tell is whether the client’s work has structure underneath it. We have clients whose inputs arrive in the same shape every single time, and that’s where AI prints money. We have others where every project is its own animal, and there the smart move is often to not automate at all, and to say so out loud. So we work the patterns first. And honestly, half the time the real answer to a business problem turns out to be a clean process and a good spreadsheet, not a model. Telling that to a client who walked in asking for AI is some of the most useful work we do.
Q: Looking ahead 2-3 years, what emerging trend, technology, or approach are you most excited about, and what trend do you think is getting too much hype right now?
A: Most excited: disposable software. We have hit the point where you can build a throwaway tool in fifteen minutes to solve a problem that only exists for one afternoon, then delete it. One of our ETDs recently spent 90 minutes hunting for a plugin that did one very specific thing, gave up, and just built it himself in fifteen. That quietly flips the buy-versus-build math that has run agencies for twenty years. The thing I’m watching is that throwaway tools have a nasty habit of becoming load-bearing, so governance has to grow up fast to keep pace.
Most overhyped: the fully autonomous agent that supposedly runs your whole business while you sleep. The demos are gorgeous. The reality is all confidence and no judgment, with nobody to answer for it when it’s wrong. The version that actually works right now is a lot less cinematic. It’s an expert moving ten times faster because the machine takes the grunt work and they keep their hands on the wheel. Anyone selling set-it-and-forget-it is selling the exact part that doesn’t work yet.
Q: Platform Foundations That Increase Speed: What category of tech debt most often slows creative delivery in agencies, and what did it take to unwind it at Instrument?
A: In an agency, the debt that hurts most isn’t in the code. It’s in the scope. Work gets priced and committed before the people who have to build it are ever in the room, so technical delivery doesn’t start at the starting line. It starts in a hole. Then everyone wonders why engineering is behind. Engineering isn’t behind. The estimate was. The first stretch of every build gets spent quietly paying down the distance between what got sold and what the work actually takes.
It’s structural, not anyone’s fault. It happens fast, under pressure, and optimistic by design, because that is how you win the work. The technical unknowns just surface later, when they cost the most to absorb.
It’s moving the technical understanding upstream, into the moment the scope is being shaped. A technical voice in the room before the number is committed. Surfacing the hard parts while they’re still cheap. Sometimes, putting a rough working thing in front of the client so the estimate is grounded in something real instead of a hopeful guess. That’s a big part of what we’re building toward with Instrument Intelligence. Get the scope right and most of what looks like a delivery problem just quietly disappears.
Q: Building High-Performing Engineering Teams in Agencies: Agency engineering teams face different pressures than product companies. What’s the most important structural difference between your team and a product company’s, and what ritual or practice do you use to keep engineers engaged with creative outcomes?
A: A product engineer lives with what they build. They inherit their own decisions and their own three-year-old code at two in the morning, which rewards patience and punishes shortcuts. An agency engineer ships something great and then walks away from it onto something completely different, on a timeline somebody else set. That rewards range and the rare ability to go deep fast and then let go. I’ve stopped ranking these. They’re just different kinds of brave.
What I’ve learned is that my engineers see things I can’t. They’ll look at an idea the whole room is in love with and quietly know which twenty percent is going to eat the entire timeline, or spot the one small move that makes an impossible idea suddenly cheap. That instinct is the actual product. So the practice I care about most is simple: get them in the room at the very start, when the idea is still soft, not at the end when it’s a spec to execute. The best moment in this job is watching an engineer put a real, working thing in front of a client in week one and seeing the client realize the people building this actually understood the brief. Most of my job is making more of those moments happen and then getting out of the way.
