Ladies and gentlemen, please welcome to the stage the experience builders: Brendan Gala, Brandon Daniels, Jared Ferris, Tyler Reft, Evan Smiley, and August Bender.
All right. So for the next hour we are going to talk to you about what it means to be an experience builder — a new position that we have brought into Exiger, really driven by Brandon and I, and one that I think has fundamentally changed the way that we bring software to market. So look forward to the discussion, and we're going to jump right in, because I think everybody knows the people here. As this is playing, I want you to think about who built this, and how many people, and how long it might have taken. What you're seeing happen on the screen is risk model creation: the ability to have multiple dimensions in that risk model, the ability to actually dive down and adjudicate the information to clear it, and the ability to have an AI go in and take an output from the risk model and automatically adjust it based on who that organization is and what the risk is set at — something that requires deep research. All of that was built by one person. If you guessed Jared Ferris, you might be right. Jared, remind the group here what your background is and how long you've been writing code.
My background is international affairs. I started off at Exiger and only joined product last year or so, and I've been writing code for really about five months.
Awesome. And of course Jared did have some help from his new best friends like Alexi, and we will talk a little bit more about what that means and how we are doing these things. But really, Jared took that from what we used to do with a team of multiple product managers, multiple designers, and an entire pod of engineering — literally, for the executive summary, you saw some of the stuff we never even could do, and the base risk model took over a year to get to. And he did that in about a month. Just incredible pace, and what it is to be an experience builder, which we're going to get into.
Before we do that, Brandon, I wanted to just turn to you. I know that kind of the magic of what we saw on screen there is still fascinating for me — I'm sure it is for you. But take us back. What we have on the screen here is some pictures of when we were first in the room building this. As the leader of this business, what gave you the vision and the conviction that we got to do something and we can make this happen? Why the creation of this role?
Yeah, so first of all, Exiger has always had a fantastic engineering team, a fantastic product management team, and a great set of subject matter experts. The problem is, none of those folks spoke the same language. And so there was just a long cycle between the idea, the market need, the requirement, and how we would then bring it to life. You know, this isn't an organization that does DevOps tooling, or does, you know, automated outreach or automated cold calling. This isn't something where sales folks or technology folks just intimately and natively understand what it is our customers are trying to do. We're operating in the most risk-averse environments — defense, energy, complex manufacturing — and then we're doing the hardest thing that no one wants to touch: managing regulatory process. Like, there's such a big chasm between that and what an engineer knows — like the expert in Kubernetes — that bridging that gap has been one of the most difficult challenges.
Over the break, actually, around Christmas of '25, I spent probably 72 hours straight not sleeping, working in a set of agentic coding tools. So we had been building our own agents, we had been building our own capabilities, and I spent time essentially creating my own loops, my own agents that could help me build code, that could help me QC code, that could help me then publish code and then bring it to life. And I started working in some of the agentic coding tools and saw all of that get streamlined uniformly and perfectly for me. And then what I did was I stepped back from actually coding and just started speaking into the application: the architectural requirements, the product requirements, the places I wanted to deploy, how I wanted to deploy — and watched it execute, not perfectly, but pretty damn well. And I thought to myself, this is going to change everything. So then I started researching what other people were doing, and I saw this one thing on LinkedIn where this guy essentially built automation — he built an app that went up to the Apple Store in about 50 seconds, and it got published to the Apple Store. And I looked at the app, and it was usable.
And I was forever changed. I came back to our first senior managing meeting — it was our planning meeting for the year, we were clearing our budget — and I said, 'I just need everyone to watch this 50-second video, because I've repeated this five times, and it works. Like, you can do this.' And what happened in front of all of us: somebody had an idea. It was an idea that was esoteric, and it was realized in a real application that people could use within a minute. And I thought, 'Oh my goodness, this is an opportunity for all of that expertise that's built into Exiger — from our time working on the COVID-19 response, to our time working as category managers at some of our largest manufacturers, our time as cyber experts, our time building some of the most complicated systems, our time being the monitor of HSBC — this is an opportunity to bring all that expertise right directly into the center of engineering and start building applications on the fly.'
And so I came back and I said to all of you, 'Let's be the startup that killed Exiger. Let's rebuild our process, our structure, our organizational teams to put this new role at the center of what we're doing — which is an experience builder that's working with engineers, generating code with AI.' And it set us on this path that I didn't really understand. There was this one moment, and I'll stop here. There was this one moment where I had written a — probably poorly built — but written an ABAC and RBAC application. It was essentially a service. And I said, 'The code is written. I want to deploy this as is. I want to see how it goes.' And the room fell silent, and everyone was kind of like, 'We're not going to deploy something that you wrote with AI.' And August looked at me and said, 'You know what? Eff it. Let's deploy it right now.' And we did, and it worked. And it was like this revelatory moment. It was like the dam broke open, and all of the water flowed. And the last six months since then have been incredible.
Yeah, well said. Let's hear from some of the team here a little bit about what it actually means to be in the role. Maybe we'll start with you, Jared, since we've kind of kicked off with something that you built. But what are you regularly doing today that you didn't do six months ago?
Well, you know, other than spending all day talking to robots, I used to spend all my day thinking about, 'All right, how do I write this just right so that the engineers know what I want?' And I have to think 10 steps ahead. I can't really see what it's going to come to life as. And now, when I have a little bit of an idea — you know, 'it'd be great for this model to do this' — I can just do it, and it's there. I can test it. I can iterate. And then only when I have something really crazy and vague do I go to Alexi and be like, 'All right, I did this thing. Now I need you to bring it to life, harden it, and go from there.' And it's just there. What used to take weeks, months, is now just there. And it's very cool to see your ideas just come to life.
What's that been for you personally versus what you were doing prior — whatever it is you were doing?
The biggest thing is — I think you said it well today — so much more excited to show up. Because it used to just feel like logging time: you have an idea, you know it'd be great, but it has to go into the backlog. You have to wait a quarter, you know, you're thinking quarters ahead, and now I'm thinking days ahead. So I can wake up, have an idea — you're on the walk, you think of it, and you're like, 'Wait, I can just go do this tomorrow.' And it just brings an excitement to the day that you used to have.
Tyler, how about you? What have you found sort of most interesting about the difference in your responsibilities?
Yeah, I mean, mine is very similar to yours, right? Six months ago I would spend a lot of time in Jira, Confluence, writing up the specs as Jared mentioned, getting sprint plans planned out and the quarterly plans — basically having that conversation with the engineers in a text format. And there's not a day that goes by now that I'm not pulling down code into my local environment, reading that code, modifying that code, generating code that is ultimately landing into our production environment. That is a daily thing and experience for me now, and it helps so much with our communication from product and what the market is asking for to our engineers, so we can make sure that we're building the right things at the right time.
What's your favorite Git command?
Favorite Git command. I think... force push, yeah, force push. You know, I often have multiple cursors open at any given time. I'm bouncing around from branch to branch. So I would have to say I use git switch all the time.
And I think, just digging on this a little bit more — as somebody who stepped into more of a product management role, has this made you a better product manager, or...?
Oh, absolutely. Definitely made me a better product manager. Like I just mentioned, the communication between engineering and product — from someone that's traditionally a non-technical person to communicating with someone that's very technical — to step in their space a little bit and start to understand their language, but also teach the engineers and mentor the engineers a little bit about product as well. And that has been a huge improvement on our skill sets.
All right, Evan. Evan has been our sort of fearless leader in making sure that all of this hangs together, and has done an incredible job since day one. She's in that picture you just gave us. Evan, tell us — as you think about really the entire SDLC — how has your relationship changed between the functions as part of this new role?
Two things come to mind. One is cultural and one is process. So, kind of touching on some similar themes that have been brought up: a builder is a multidisciplinary role. We really focus on how we've upskilled traditionally non-technical roles into builders, but engineers are builders too. And so what that upskilling looks like is getting them closer to the market — they have to be customer champions and product knowledge experts. And so, as we close in that Venn diagram of skills, we are finding that people can start speaking the same language, as you had mentioned earlier. So someone from a product management background can now contribute to an implementation conversation and understand what's being discussed, and people from an engineering background start thinking in terms of business outcomes and business trade-offs. So we're more aligned sooner in the process. And then the second, being process: as builders, I've really seen a shift towards what we've been calling systems thinking — so not just systems architecture and systems engineering, but thinking about how can we build a way of working so that any builder, with their Venn diagram of skills, can contribute at the same pace and the same quality, going from product idea to product delivery. Yeah.
Great. I just want to tee off on that. That's one of the most important things. If you can get your engineers in front of your customers — so if engineers are not measured on how much code they write, if engineers are not measured on how many tickets or merges or pull requests they have, if engineers are measured on feature development — then I want engineers to sit with our customers while AI is doing the first-generation coding. Now, the first-generation code might be overly complex, might be hand-rolled — you might have to actually strip it back and bring it back to a framework and say, 'Actually, there's a set of libraries that do this much better than your hand-rolled code. We're going to put it back to this.' But you can actually have AI do that, too. If you have AI writing the code, you can actually sit your engineers in the room with the customer and have them listening while code is being written. And that diagram of product managers and subject matter experts becoming more technical, but also technical folks becoming more market aware, is really where this unlocks such a huge opportunity for all of us.
August, what about from your perspective — as the owner of kind of the infra and DevOps side, how have you changed our process, and what difference have you seen from where you were prior?
Yeah, the main thing that I really take value in here, from an infrastructure perspective, is the time to delivery. So we went from two years planning out — 'here's the big plan that we need to do' — to, 'Hey, can we deploy to this new region? Okay, I can do it this week. Does that work for you?' And I think that for everyone in sales and everyone else — not just from the engineering side, but everyone who's non-technical — can now come in and get that information quickly, be able to communicate out, and get closed deals faster, as well as be able to build the right things for the customers in real time. It's such a huge difference. And what that comes back to is being able to bring that back to an infrastructure perspective allows us to lower cost, deliver faster, and deliver more consistently at a higher uptime.
Great. Okay, we want to shift a little bit into what it actually means to do this — and what's the thought process that an experience builder is going through when they take on a task. So we're going to look at something here around automated supply chain creation. Tyler, I'm going to turn to you on this one. But before we jump into what's happening on screen in the video, give people a little bit of your background and why that is important as an experience builder.
Yeah, absolutely. So my background is actually, for the greater part of my career, a supply chain practitioner. And I still like to think I still am. But it's only been in the last couple of years that I've stepped into the product development world. And why that's important as we're building out these experiences is because I have felt the pain firsthand of what our customers are going through. And I understand the problems that we're trying to solve for our customers and the market — I felt the pressure of that. And that is very important as we're building out these solutions for our customers, to ensure that we're building out a solution that is truly going to get them to the outcome that they're looking for, that's truly going to solve the problems that they face day in and day out in a very dynamic market, in an ever-changing world.
Great. So what's playing on the screen — I know it's super hard to see here — is somebody submitting a product through the system, and it's automatically jumping in and creating the supply chain. What's less important on the video, more important — take us through what happened? Who are you talking to as part of that? Are you just spraying a whole bunch of text at a model and hoping to get the output, or what's your approach when you tackle something?
The first approach that I took specifically in this example is I sat myself back down in a room and I put myself in the seat of our customers. Understanding the feedback that I've been hearing from the market, but also basing it off of my own experience. And I just sat down and I thought to myself, okay, if I was back in this seat, how would I go about solving this problem — whether that be with a team of analysts or going through manual processes myself. And after I mapped that out, did that mind-mapping exercise, then I asked myself the question: how can I use the AI technology that I now have in front of me — that I wish I would have had years ago, as I was sitting in that seat — to unlock the potential of responding to the types of problems that we see in supply chains today? And after I laid that AI technology on top of it and came up with that solution, that's when I brought in my fellow engineers, my experience builders, and even my leaders, and I walked them through that solution. And I challenged my own bias — I took their feedback and I implemented it into my solution, and I moved into a prototype phase, where I rapidly prototyped what that solution was, to prove out: is this going to give our users the outcomes that they want? Is it feasible for us to actually deploy a solution like this? And from prototyping we transitioned into an engineering hardening phase, where we looked at scalability and accuracy and measuring those outcomes to get into our production environment.
So, Evan, Tyler thinks he's a principal engineer. Give us the other side of this story. What does it mean to take what he built — which obviously had a tremendous amount of thought into it — hit against our products, including deep services, database things, as well as obviously the front end of the thing; a total AI orchestration layer that was needed to create this. But take us through your side. What's the engineer thinking about to actually harden something to bring it into the system? Take us through that process.
Yeah, so hardening is really just how we ensure a feature is quality, secure, and scalable. And so it can look like a few different things throughout our process. It could be an implementation meeting or conversation that's happening while we're prototyping, how we're going to build these services and make sure that they're communicating. It could be fixing issues that come up in our identity and automated tests in our CI/CD, which is built to be the gate to production, to make sure that we're catching everything, that everything is secure and scalable. Or in some cases it could be a refactor of a prototype. And refactor is not such a big scary word for us anymore. But yeah, again, we're building a system so that any builder can contribute quality code at the pace we need. Yeah.
Brandon, over to you. Brandon is not only our CEO, he's also one of the critical builders as part of the product — many of the components in there, as we talked about, were from things that he'd written. But take us through your side. I mean, as a builder, not as a CEO, what's your process like? How do you feel?
Well, I mean, the first thing is, as a CEO, if you're running a software company, if you're running a company that relies on automation, if you're running a company that's in AI — and I'm talking any automation — if you are not pushing code, you are dead. You're dead. You just don't know it yet. You're a zombie. You're a walking dead, right in front of us. And I know that because when our teams are working, the only way that I know that any of this is possible, any of this is quality, any of this is working, is by having experienced it at some level. Now, I have to back away — you know, I can't be a bottleneck for a bunch of features when I'm trying to get ready for a board meeting. But at the same time, I also have to know it intimately and work in it every day. And so, as a CEO, I think that this is the most fundamental change in every industry that we've certainly ever seen. Like, I mean, I think this is pre-World War II industrial ramp-up kind of stuff.
The second thing is, for me — you start to — I mean, imposter syndrome like re-emerges when you're building entire applications yourself. So one of the first things I did was I got off of the Replits and the other automated building tools that have integrated infrastructure, and I went through the hard and difficult and ugly and embarrassing and humiliating path of trying to deploy it on my own infrastructure, and having some of our engineers yell at me over the version of Spring I was using or whatever. But at the same time, that gave me insight into how hard it is going to be for people to build these systems that don't have the complete manufacturing line. Like, this is going from custom cars to Henry Ford, right?
And so, through this process, I've realized we're not building an app. We're not building, you know, the best supply chain and procurement automation tool. What we're building is that assembly line. We're building that assembly line that says, 'Okay, you've got an idea? Awesome.' And I don't doubt that in a year from now some of those features — so in the new platform the system will automate taking a screenshot, you know, help you to write a bug request or a feature request. I would guess that in a year from now we'll start letting customers see where that comes out through our AI SDLC and land in a branch for them, so they can see what the feature looks like and see if it would work. That'll be a good idea, or that'll be a good way to get sort of the difference between bad ideas and good ideas, because sometimes we think something will be good and then we're like, 'Oh, be careful what we wish for.'
But the biggest thing for me is, our assembly line is a safe place for our customers to innovate, ideate, and build. That's the fundamental shift. I was with a customer earlier this week, and we thought we knew where they were going. We didn't. We spent time with them. They said, 'Our biggest issue is trying to get information from distributors, trying to get information from engineers, trying to get information from the early design process.' And we said, 'Okay, well, if that's the biggest issue, and that's what stops us from doing automated classification of export controls, let's build that together right now.' In those few hours, we literally built together a portal which automatically captured all of that documentation and brought it into a secure and centralized place. If we didn't have the infrastructure that Evan was talking about, if we didn't have the DevSecOps capabilities that August was talking about, then again, we're just deploying to a host app on our local, or we're deploying to a Repl.it or Vercel where that stuff can't meet the FedRAMP-grade requirements that we have. I think that's the change for me: I don't think we're building a platform. I think we're letting our customers build the platform.
Yeah, couldn't agree more. Jared, I think one of the things that I encounter is I have all these ideas, I go build it, I see it come to life, and then I go talk to people. And — you and I were in London last week talking about one of your builds with the team, and they're on the front lines. They're getting, you know, kind of driven by our customers to satisfy their needs. How, as an experience builder, when you're in that process — you built something — what's going through your mind when somebody says, 'We got a problem, we got to extend this'? Like, you know, is it, 'Oh crap, I got to go back to the drawing board,' or is this something where you can easily see a path that, 'Okay, I understand how all these services hang together. I can actually do these things'?
You know, one of the biggest differences is before we often had to choose. So we'd go into these meetings, and it would be, 'Well, you know, no two customers are alike, and they have different needs.' And we would go through the planning and be like, 'Okay, we can do it this way, or we can do it this way.' And now we're able to have our cake and eat it, too. Like, that was the takeaway from last week. It's like, 'Okay, you know, we need this for some of our customers with this very key requirement, and it sort of is counter to one of the paths we went down.' We don't have to take a step back. We can just add on additional configurability. Like, that's one of the things I love so much about the risk model we have here — all the configurability we dreamed about, we can just build it. And instead of having to go back and forth and think about, 'Well, we can do this, but then this other feature gets pushed back three months,' instead you can come away out of the weekend, and it's just there. And I built some of the things we talked about on the flight home, and it didn't take away from any other features.
And then, you know, the other thing is what's been so exciting here is, you know, having been talking to customers as a product manager about risk and all the things they need, we had a very long list of things that customers had asked for, or that they knew they wanted, and we just were never able to get to because it just kept getting pushed back quarter after quarter. Some things that would seem so easy but were actually really hard. Like, 'Oh, you know, I have nine dimensions of risk, you only have eight. I would really like you to put this out, rename it.' It's like we had a scoping session — like, man, this would take three months in your world. And we had a customer call and was like, 'This would be cool,' and, you know, demoing 10x your AI. And then, 'Oh, you know what? You're right. We've had other customers in the past.' And then the next day he just did it. And so it's just no longer either/or. As soon as we get that feedback, it's just there, and we can have a lot of different personalities within the application to serve your use case.
Speaking of either/or, August, from your perspective, what would frighten you about people just being able to push a PR out and making its way to production? How do we put some controls in place to make sure that, you know, as a customer who likes to log in, know what I'm going to see, things aren't changing?
Law enforcement's paying. Overall, the answer is actually more AI, surprisingly, because we're trying to do a couple of different things here. We're not just building code with AI, but we're also auditing that code with AI, and then using that to also be self-healing. So when someone pushes something out, maybe there's a bug in it that they didn't catch, the AI will catch that. Fix your PR, push it back to the pipeline, and say, "Hey, is this really what you want?" Okay, cool, let's go. So it's how do you get that out faster? And I think from the engineering and an infrastructure point of view, we can now have that factory that can check and self-correct. And that just accelerates everything in every job role more and more over time. And I'm actually more excited than I am worried, which I think is the most worrying thing.
Yeah, I mean, it's a valid point. To Brandon's point, it is an assembly line. I think the sort of adoption and revamp has been across the board. Writing code is this overall process. It's all of these things going through a re-look and, in some respects, to say how do we do this better. Okay, so I think that the moral of that story, to make it easy, is a ton of work. I mean, it is really incredible for our customers to be able to be in a session and in four hours see a completely new application built. But to make that possible, it is a ton of work. Like you can have a thousand ideas, you can implement them all really quickly right now. The ratio of build expense to maintenance expense is one to ten. Like to maintain the application, to manage the bugs, to manage the "oh, I didn't think of that," to manage the continued evolution, to manage the scale, to manage the factors that we talked about, it's an incredible extension. So the automation and AI around that maintenance is, I think, a real differentiator for how we're building this platform.
Yeah, and I think what I want to move on to next is really we're not sitting around and being complacent. Like this world is shifting so quickly, we are revisiting how do we get better. What else can we be doing? And so one of the things I had asked the team to do before we got up here was, instead of us telling Claude what Claude can do better, we asked Claude how we can do better. So we asked Claude to be our performance manager and have them writing code.
And what you can see on the screen is some of the output of that, which is terribly hard to read from up here. But my most positive and favorite one is probably the top one, if you can see it, which I apologize, says: "In six months you went from asking for help running commands in the terminal to orchestrating parallel agents across multiple services, writing plans before code, and gating merges on validated CI review, with rework dropping by half even as the work moved into further cross-service contract territory." A glowing review, which was pretty incredible. But I think what we have seen is some really — you know, this is, I think, revealing. I was talking to Brandon about his review today, and I used OpenAI at one point, and he was like, "Wow, it was serious." You know, it was very constructive feedback. And I think some of the pieces in here, I'm curious if the team feels they're a fair assessment of what we've done or not. And I'll try to read off one of them, which is, you go beyond the — you sell beyond the code, which is basically like you need to start shipping much smaller features and ensure that you're getting something out rather than trying to think of every single way in which that thing is going to break. But curious if the panel here feels that that's a fair assessment or not, and what do we do about that?
