Ultimarii

Duane Wood

AI Product Authority

With over 30 years of experience, Duane Wood specializes in conceptualizing and delivering internet products that drive business growth. He has a strong ability to understand diverse industries and translate insights into strategic initiatives. His track record includes executing ambitious goals through agile development methodologies. Thriving in entrepreneurial environments, Wood balances long-term vision with the ability to quickly turn concepts into reality and deliver measurable outcomes.

Leading Engineering, Infrastructure, Security, and Risk

As CTO at Ultimarii, I’m accountable for all aspects of software development, infrastructure, security, and compliance across the organization. My team manages four compliance frameworks for our enterprise customers, ensuring both regulatory adherence and peace of mind. These frameworks influence everything we do, from how we build software to how we design and secure our infrastructure. Overall, I lead a team of about 35 people.

Disciplined Bets That Unlock Growth

Most of my experience has been in startups and scale-ups, typically from seed through Series C. In those environments, decision-making is driven by timing and focus. It’s less about doing everything at once and more about understanding what’s critical now while keeping a clear view of what comes next.

“The priority is building a viable product that gives early customers confidence,” says Duane Wood, Chief Technology Officer at Ultimarii. “If they trust the product, they expand usage within their organization and advocate for it externally.”

That means every investment has to be tied to growth potential. You stay disciplined on spending and focus on what will move the business forward in the near term.

This is where stage-appropriate decision-making becomes essential. You don’t build a full security operations center in an early-stage company—that’s not where the immediate value lies. But you also can’t ignore security. You need to implement the right level of controls to give customers confidence without overinvesting in capabilities that don’t yet drive growth.

In the environments I’ve worked in, technology exists to enable growth. It supports the sales motion by making the product credible, reliable, and trustworthy. Security, infrastructure, and compliance all play a role in reinforcing that trust.

At Ultimarii, we took a deliberate approach because we were targeting enterprise customers from day one. We prioritized achieving ISO 27001 certification within the first three months and SOC 2 Type 2 within six months. Those weren’t just operational milestones— they were foundational to earning the trust of our ideal customers and gaining early traction.

A Simple Rule That Scales with Complexity

From the outset, we anchored ourselves to a simple principle: buy what doesn’t differentiate and build what does. That became our north star. If something could meaningfully set our product apart, we built it. If not, we chose the best option to buy.

That discipline helped us avoid unnecessary complexity early on. We leaned on standard integrations and commodity services, using low-cost, pay-as-you-go models. This allowed us to scale with customer growth without significant upfront investment or cash burn.

As we grew, our approach evolved. When a third-party tool became too costly or no longer fit, we reassessed. We ran cost-benefit analyses to decide whether to replace, optimize, or bring it in-house, based on cost, performance, flexibility, and long-term fit.

Security and data control became more important as we moved into the enterprise. External data processors introduced friction, from vendor risk assessments to questions around data handling. At a certain scale, it made sense to bring critical systems in-house.

That inflection point typically comes around Series B, when the focus shifts to scaling. That’s when you start pulling capabilities inside, investing in R&D, and building infrastructure that better supports your product and customers.

Speed of Innovation Versus Stability of Delivery

For us, the biggest driver of change has been the rapid evolution of large language models (LLMs). As an AI-native product, we’re tightly coupled to that pace, and over the past two years, progress has been significant.

Each model upgrade isn’t a simple swap. Changes in model behavior directly affect how our system performs and interacts with users, so every transition requires rigorous validation before reaching production.

We run both quantitative and qualitative evaluations, with subject matter experts assessing outputs against defined ground truths to ensure accuracy, consistency, and reliability.

The challenge is keeping up with the speed of innovation while maintaining that quality. Model releases come quickly, but we can’t compromise on performance.

Beyond that, most of our broader technology stack has remained stable. It’s the pace and impact of LLM advancements that demand the most attention and discipline.

  The priority is building a viable product that gives early customers confidence. If they trust the product, they expand usage within their organization and advocate for it externally.   

The Gap Between Pushing AI and Making It Work

The biggest disconnect between technology ambition and execution comes down to big goals without the alignment or planning to support them. There’s a strong top-down push from executives and boards to adopt AI productivity tools, but that isn’t always matched by buy-in from the people expected to use them day to day.

For many white-collar workers, hesitation remains. Part of it is perception. Some see AI as a threat that will replace them rather than augment their work. Part of it comes from early experiences. The first wave of LLM implementations wasn’t well engineered. There were accuracy issues and hallucinations, and that left a lasting impression.

Even as the technology improves, a trust gap remains. Organizations have to show that these systems are reliable, that outputs can be validated, and that they make work easier, not riskier. That takes time and doesn’t happen just because leadership mandates adoption.

Another challenge appears when organizations try to build their own AI solutions. Whether internally or with a vendor like IBM, they often struggle to define clear, focused use cases and don’t fully understand what the technology is good at.

As a result, requirements become too broad. The tool tries to do too much for too many people, and that’s where projects break down. They become expensive, overengineered, and fail to deliver expected value. I’ve seen this with several customers. The intent is there, but without clarity and focus, execution falls short.

Building with Intent and Proving the Outcome

Rather than a single initiative, one defining moment in my career was stepping into a very early-stage startup about six years ago. I was brought in to replace the technical co-founder after the company had built an initial system and secured funding, but lacked the technical leadership needed to move forward.

My role was to help take the company from startup to scale-up. That meant significant re-engineering, rebuilding parts of the product, and putting the right processes in place to ensure things were done properly. It was also about preparing the company for its next round of funding, moving from Series A to Series B, where investors expect much more rigor and strong engineering leadership.

That experience taught me a lot about what investors actually look for. They care about engineering performance, where the money is going, and how clearly you can connect technical investment to business outcomes. You need to show a direct relationship between what you build and how it drives revenue.

At that stage, engineering can account for 40 to 60 percent of the budget, so there’s real scrutiny on whether that spend is delivering growth. Learning how to map engineering investment to growth, communicate that clearly, and report it effectively to leadership and the board was a defining moment for me.

That’s something I carry into how I mentor others. It’s not just about building great technology—it’s about building with intent and being able to clearly tie that work back to business impact.

From Hands-on Builder to Strategic Decision-Maker

One of the biggest shifts in my career was moving away from being hands-on with coding. Early on, I was deeply involved in building systems myself. But as the organization grew and the complexity of decisions increased, that stopped being the highest-value use of my time. The shift was toward hiring stronger engineers and focusing on broader architectural and business decisions.

From there, the role really comes down to two things. First, building the right team that can execute on both the product vision and the underlying technology strategy. Second, managing the sheer volume of information that comes with the role.

There’s an overwhelming amount of input at any given time—new technologies, evolving stacks, infrastructure options, competitive signals. The real skill is being able to filter that effectively: what actually changes our product, our cost structure, or our speed to market, and what is just interesting but ultimately irrelevant.

That judgment becomes critical because information is constant—emails, articles, podcasts, internal discussions, even things that get flagged as “this looks important.” Not all of it is.

So for CTOs going forward, the job shifts from execution to judgment. Build strong teams, stay focused on what truly moves the business, and filter aggressively. Lead, don’t code, and stay curious. The role is a continuous learning journey. Things change quickly, so you have to keep exploring and adapting. But just as important is knowing what actually matters and what doesn’t.