Measuring AI Outcomes Beyond Tokens and Prototypes With Ninox
AI at WorkNovember 11, 2026
62
00:25:4423.56 MB

Measuring AI Outcomes Beyond Tokens and Prototypes With Ninox

If your organization switched off its AI systems tomorrow, would customers, employees or the finance team notice any meaningful difference?

In this episode of AI at Work, I speak with Frank Böhmer, founder and CEO of Ninox, about the growing gap between AI activity and measurable business value. Companies can count tokens, prompts, users, copilots and prototypes, but those numbers mainly reveal participation. They do not show whether a customer issue was resolved faster, an audit passed, an error rate fell or a team handled additional work.

Frank argues that token consumption is a particularly weak proxy for success. An organization would never judge an employee by the number of meetings attended or the number of words typed into email. Paying attention to how many tokens people consume creates a similar incentive. The CFO wants an operational result, not proof that a model stayed busy.

That distinction becomes important as natural language tools make software creation available to people who could not previously build applications. Frank sees genuine value in vibe coding because it reduces the cost of experimentation. Someone can describe an idea and create a convincing prototype in hours. The difficulty begins when that prototype meets the operational world.

A production application needs reliable data, authentication, role based permissions, testing, integrations, audit logs and clear ownership. It must continue working as the organization grows, regulations change, employees leave and processes evolve. Frank suggests a more demanding question than asking whether an application can be built in an afternoon: can the company trust it three years later?

We discuss where developers fit when AI can generate interfaces and basic code. Frank believes experienced developers move toward architecture, security, integration, data modeling and the consequences of design decisions. Plausible output can conceal incorrect assumptions and forgotten edge cases. As the volume of generated software grows, businesses need people who can distinguish a durable design from a shortcut that only works today.

The same reasoning applies to process automation. Automating each step of an inefficient workflow can create a faster inefficient workflow. Frank encourages teams to reconsider the process using the capabilities now available. If AI can bring the right information to the employee immediately, some handoffs, searches and approval steps may no longer be required.

For leaders assessing an AI project, Frank offers both a rigorous method and a simple test. The rigorous version begins with a baseline covering process time, cost, errors, delays, people involved and the final outcome. The company then compares those measures with the AI supported version. The simpler test asks what would happen if the agent were switched off tomorrow. If the business barely notices, the project may be an experiment rather than an operating capability.

We also revisit shadow IT. Business teams create their own solutions because central IT can never satisfy every request within the available time and budget. Banning creation will not remove that demand. Frank recommends an approved environment where employees can build quickly while identity management, security, backups, auditability and deployment remain under organizational control. This changes IT from the team expected to build everything into the team that provides the safe foundation.

Should leaders celebrate wider AI adoption, or reserve the word success for the moment a process becomes measurably better? Listen to the episode and share your thoughts with me.

Useful Links

[00:00:06] If your company switched off all of its AI tomorrow, would anyone notice the difference? Well, my guest today is going to help separate AI activity from business value. Token consumption, prompt counts, user adoption, rapid prototypes, all these things show that people are experimenting. But they cannot tell a CFO whether a process has become faster, cheaper, safer or more accurate.

[00:00:34] And my guest will explain why vibe coding is excellent for testing ideas, but often incomplete as a route to durable business software. And we will also discuss the permissions, integrations, audit logs and ownership required when the application meets reality. And why experienced developers are becoming more valuable and exactly how companies can bring shadow applications into an improved environment.

[00:01:04] And he will also give you a wonderful, simple test. Turn off the AI and see whether the business cares. But who is my guest? What does he do? Well, it's time for me to officially introduce him now. So thank you for joining me on the podcast today. Can you tell everyone listening a little about who you are and what you do? Yeah, Neil. Thanks very much for having me. So I'm Frank. I'm founder and CEO at Ninox.

[00:01:33] And we help organizations build the applications they actually need. So without having the need to invest into heavy traditional software development processes, but also without working around rigid standard software. And what I find particularly interesting is really the range of problems our customers solve.

[00:01:58] In the UK, for example, Ninox is used in very different industries. For example, in the healthcare space, we have the NHS using Ninox to keep track of patient recovery after they had a stroke. And on the very other end of the spectrum, we have companies like Osprey in the construction industry. And they use Ninox to keep inspection and quality records together in one place.

[00:02:26] So we work with this type of organizations that have real operational challenges, often in processes that are very complex, too complex to maintain in spreadsheets or with email back and forth, but where they also cannot find suitable standard software on the market or where a rigid enterprise system just doesn't make sense. And we see this type of organization increasingly using AI and AI-enabled local platforms like Ninox

[00:02:55] to quickly turn business problems into solutions that actually work. Well, there's so many reasons I was excited to get you on the podcast to join me today, because there's a lot of noise around AI at the moment. Also, a certain amount of fear around token consumption and the costs or hidden costs around that. And your pitch here challenges Silicon Valley's focus on token consumption. It feels like a real breath of fresh air.

[00:03:22] So why is usage a poor measure of whether AI is creating value at work? Let's tackle that right from the outset here. Yeah, yeah. I think that's a great question, Neil. And actually, it's been almost a weird anecdote of the short AI history now that we've seen companies like Matter putting leaderboards out there, incentivizing their employees to spend as much tokens as they want or can.

[00:03:49] And that clearly led in the wrong direction. So I think the one big learning, of course, is that consumption is not the same thing as value. You certainly wouldn't have come to the idea to pay your employees or measure your employees' performance by the number of meetings they have or the number of words they write in their emails. So why should you pay models as much as possible?

[00:04:14] And you certainly can have your employees generating millions of tokens, writing thousands of prompts, experimenting with AI every day. But none of that necessarily tells you whether there is actual business value, whether your business has become more productive, more profitable or less risky. So I think ultimately, and you can ask the CFOs, they don't want to spend money.

[00:04:43] They want to invest into outcome. So ultimately, companies don't really want to buy tokens. They want an optimized supply chain. They want an audit to have passed, a customer issue resolved faster or just resolve an operational weakness. So I think the important shift is asking no longer how much AI are we using, but what actually has changed because we're using AI now.

[00:05:13] And yeah, usage can be an interesting support matrix if you want to understand maybe if a business unit has less adoption of AI. So in that case, it can be an interesting metric, but it shouldn't be confused with the result. Yeah, 100% with you on that. And another big phrase that we keep hearing over the last two years is vibe coding, which can produce an impressive prototype in hours. No arguments there.

[00:05:41] But what is it that separates a useful experiment from an application a company can safely maintain for years to come? What are you seeing here? Yeah, so vibe coding, a very interesting trend.

[00:05:58] But I think if you ask an engineer, even predating AI, what they would tell you is that building the first version of your product, that's the fun part, right? That's the easy part. And in that sense, the vibe coded prototype is the easy part.

[00:06:17] And it is actually quite remarkable how quickly people who did not have access to this type of technology before now can describe their ideas and create something that seems to look like a working application. And that can be genuinely useful because dramatically reduces the cost of experimentation. So prototyping is a very useful discipline.

[00:06:44] But ultimately, any business application has to survive contact with reality. It needs reliable data. It needs user authentication and authorization. You want to have role-based permission control in place. You want to be able to test the application. You want to have audit logs. And applications don't live in isolation, right? They need to be integrated into an often complex IT environment.

[00:07:14] So things need to keep working as the organization grows, as regulations change, as requirements change, and when employees leave and when the processes change. So I think at the moment we are seeing a lot of impressive prototypes that never move really beyond that prototype stage into full production.

[00:07:39] And I think the real test is not, can I build this in an afternoon? But can my organization trust this really in three years? Will it hold up to the demands and requirements of the future? And when we're talking around AI in the workplace and getting the most value from it, how can a business leader build AI-supported applications without losing control of their data access,

[00:08:07] their permissions, testing, and ownership? It's a big concern for many leaders, right? Yes, absolutely. And I think the answer is almost in your question here, because the key is to separate both things. You want to separate the building part. You really want to enable your business users. But on the other hand, you want to stay in control.

[00:08:29] And the reason why you want to enable the business side is they are the ones who know their processes and their problems much better than anyone else. And they have the demand and they have also the incentivization to build digital solutions. But the applications built, they cannot live in an isolated way. And they cannot have every application, their own user management or their own security modules.

[00:08:59] So they need to be embedded into an environment where the organization at large stays in control and can control who has access to data, what users are allowed to change something, how is testing conducted, how is the application deployed and operated, and where's the ownership? Where do you go to when something breaks? So who do you call?

[00:09:24] And in that sense, I think AI can and really should lower the barrier of building software. But it really shouldn't lower the standards we apply to software development. A good platform gives people freedom to create inside clear guardrails. But it also ensures that there is this sustainable foundation in place.

[00:09:52] And, of course, as natural language tools lower the barrier to software creation, something we're seeing right across the board now, where do experienced developers and human judgment, where do they become even more valuable? Because there's a lot of noise on our LinkedIn news feeds around the technology replacing people. But human judgment has never been more important, right? Yeah, I totally agree, Neil. So I think developers, ultimately, they're moving up the stack.

[00:10:21] An experienced developer can create way more value up the stack. So if the AI can do the basics, the code generation, create user interfaces very quickly, then the human expertise comes into play when it comes to things like overall architecture, security, integration, when it comes to data modeling or just to understanding the consequences of design decisions.

[00:10:48] So I think you could use the word maybe taste for it. So the intuition and experience person can bring to the table to understand if a decision leads into the right direction or you call it maybe judgment. So the expert judging if the proposal from the AI is on the right side or if it's just kind of a shortcut that would work now but would not sustain.

[00:11:17] I can produce, we all know that, something that looks very plausible extremely quickly. But an experienced person will be able to recognize if there are underlying assumptions not held, whether there are edge cases not considered or whether the application will be scalable. Yeah, will it still work if there's 10 times or 100 times in the scale?

[00:11:47] So I don't see natural development or natural language development eliminating human expertise. I think it will, as you say, make it even more important because now already way more software is generated and there will be good software generated and be bad software generated. And we need the humans to tell the good from the bad. Yeah, I completely agree.

[00:12:14] And there is also a big debate at the moment around adding AI on top of old existing processes that were essentially built for a completely different era from starting from scratch and building new processes with the technology. And you've got somewhat of a unique vantage point here. So what have you learned from customers about the difference between automating an existing process and redesigning the process around AI? What have you seen here?

[00:12:41] Yeah, I guess it's an older dash that automating a bad process gives you a fast bad process, right? And that has not changed with the advent of AI. So the first instinct is often to look at the process as it is implemented right now. Then look at every single step and see if you can automate those individual steps. And that sometimes can be useful.

[00:13:09] Maybe you find a huge chunk of very repetitive manual work and you can ship in an agent and gain the efficiency harvest. But I think the real interesting projects, they start when you ask a different question.

[00:13:30] So if you ask the question, if we had AI and if we had access to the right information and bring all the information at hand right to the point, would we design this process the same way at all? Yeah. And perhaps you just don't need those many approval steps or perhaps information doesn't need to be manually transferred between systems.

[00:13:58] You don't need that person or that human in the loop who searches through 10 records because AI can bring in it the information immediately, automatically. So I think if you look at it from that perspective, that's where the larger productivity gains tend to appear. And ultimately the technology matters, but I would really try to think about it.

[00:14:26] How can we design the workflow around what the technology can bring to the table? How do we maximize the impact of this new technology? And I always try and give people listening a valuable takeaway. So what kind of, let's create a practical test that a leader could use over the next 90 days to maybe decide whether an AI project is producing durable returns rather than impressive activity metrics.

[00:14:55] Because I think it's a big topic right now and you can improve what you measure is the old mantra in IT. So what would you suggest here for people listening? Yeah, let me think about it. So yeah, I guess you could go by the books. Take an important business process, break it down, make sure that you understand it properly, that you can track the individual steps and create a clear baseline.

[00:15:27] Measure how long does it cost? How many errors occur? How many people are involved? Where is it delayed? Where are the business results? What's the outcome in the end? If you can measure all those things and then you measure the same things for the AI optimized version.

[00:15:46] Then I think you would be able to tell if that AI use really leads to a cheaper, more accurate process or if it was kind of just an experiment.

[00:16:05] But often in practice, I have to admit, you might not always have kind of all the resources or the attention to really do it in the rigorous way. So there's also a very simple question you can ask. Just ask, if we switch this AI system off tomorrow, if we switch off that agent, will the business really recognize? Will your bottom line be affected by that?

[00:16:35] And that gives you almost like, I think, an Occam's razor type of approach where you can say, okay, here's just a fancy experiment or here's something that creates real value. And something we've both seen in our IT careers is the shift to BYOD. Remember that? And it went to shadow IT and shadow AI now people are talking about. And of course, low-code platforms can spread software creation across a business.

[00:17:04] But for people listening, how can they prevent a new generation of maybe shadow applications from repeating the governance problems created by shadow IT? Because they say history doesn't repeat itself, but it rhymes. And we've kind of been here before. But any advice here? Yeah, I think shadow coming from IT. So we don't like shadow IT for good reasons. Yeah, because of the governance problems it creates.

[00:17:33] So you might run into security issues or compliance issues or just kind of lose track of what's actually going on in your processes. So there's many reasons why IT tries to contain shadow IT. But there's also a clear reason why it is there.

[00:17:55] And the reason is, the brutal reality is that IT is never in a position, has never been, and I think will also never be in a position to deliver to the overwhelming demand of the business side. So there's much more demand for software or digital solutions than IT can deliver within given budget and time constraints.

[00:18:20] So just telling your employees to not build things, I think that that won't work.

[00:18:28] But what you can do is to implement an approved environment where your employees can create solutions quickly, but where also the fundamental requirements like identity management, security policies, backups, auditability, those things are solved. And that gives you something more. It gives you kind of visibility.

[00:18:56] So maybe you're removing the shadow. The IT or the software creation still happens on the business side, but it's no longer in the dark. It's in the light and it's sustained by a platform that manages all the fundamental requirements. So low code done properly isn't about removing IT from the equation. Yeah, it's putting IT into a different position.

[00:19:23] There being not the department that needs to implement and build everything, but the department that enables and empowers the business side. And we talk a lot around what we should be measuring. And we see it all over our LinkedIn news feed. We've covered a few of them today, what businesses should be measuring in the workplace, especially when we're talking around AI at work. But I'm going to be off a different side to that coin now.

[00:19:50] And what should companies stop measuring if they want teams to focus on useful AI outcomes instead of celebrating token spends, prompts, prototypes or adoption statistics is another one. And what should they stop measuring, do you think? Yeah, I guess I wouldn't necessarily stop collecting those numbers. But don't treat them as success metrics.

[00:20:15] Number of prompts or tokens consumed, the numbers of AI users or the co-pilots you have deployed, the prototypes you've created. What does it tell you? It tells you about activity, but it doesn't. It doesn't tell you anything about value created. So I would much rather see a company say, okay, we reduce the time required for this process by X percent. Or we cut our errors by half.

[00:20:45] Or our team can now handle twice the workload without adding headcount. Those are the business metrics that really measure. So focus on the outcome. The danger of measuring AI activity is that people start to optimize for activity. If you measure outcomes instead, people will start to ask much better questions about where is AI really useful. Well, I think that's a powerful moment to end on.

[00:21:12] And for everyone listening that would like to dig a little bit deeper on everything that we talked about. We did cover a lot in a short amount of time, especially around the work that you're doing as well. Where should they go? Well, I guess the easiest place is to go to a website. It's ninox.com. You can find a lot of useful information on our site. But especially you can also just sign up for a product. It's free. Try it out. It's really easy to get started with.

[00:21:38] And maybe you find a simple process to apply ninox. Of course, you can also find us on LinkedIn. We regularly share customer stories, talk about product developments and our general thinking about AI, low code and the future of business software. And for anyone listening who has a process inside their company that still might depend on spreadsheets, email, a lot of manual work.

[00:22:07] That's exactly the type of problem we want to solve or we want to help you actually to solve on your own. Yeah, it's great what you're doing here. Absolutely incredible. It's actually allowing teams to describe what they need and watch their software take shape. But again, before I let you go, for anyone listening wanting to maybe listening to you, they've gone straight to your website. What can they expect? How easy is it to get up and running and maybe walk me through what they can expect? I think you're immediately faced with a prompt.

[00:22:37] So you can state your business problem. Keep in mind, we focus on internal processes. So don't ask us to create a computer game. That's not what we do. Then it will run you through an onboarding sequence and help you to get the foundation of your new platform built. And also keep in mind, so Ninox is a local platform.

[00:23:05] It's about managing data and information, even complex information. So it's about generating documents. It's about complex business problems you might have in your organization. So we support you with AI, but we also give you drag and drop capabilities to adjust anything on the go. So it's very easy to get started and it can get you a long way.

[00:23:33] Well, I always say at the end of every episode that technology works best when it brings people together. And one of the things that I love about what you're doing here as well is you're working hand in hand with the community, inspired by real use cases, real feedback. And it's that community aspect that really comes across. And if anyone does go to the website there, have a look around this. So many great use cases, which should spark a few ideas as well. But I'll have links to everything. I encourage people to check that out.

[00:24:00] But Frank, thank you for sitting down with me and bringing all this to life today in a language everyone can understand. Really appreciate it. Thank you so much, Neil. It was a fun session. I think Frank's test is wonderfully difficult to gain. If removing an AI system tomorrow would leave the business unchanged, the organization probably measured activity rather than value. Rather than value.

[00:24:28] Durable returns appear in process times, error rates, workload capacity and customer outcomes and risk. The same discipline here applies to software creation. A prototype can prove an idea quickly, but production applications need data controls, permissions, testing, integration, audibility and an owner when something breaks. But Frank's answer to shadow applications is refreshing.

[00:24:56] Give business teams an improved place to create, while IT supplies the shared foundation. So a big thank you to Frank for reminding us that freedom and control can coexist, especially when the platform is designed well. But the big question is, which AI system inside your organization would people genuinely miss if it disappeared tomorrow? As always, techtalksnetwork.com.

[00:25:23] You can find everything we've talked about there and much more. And hopefully I'll get to speak with you. Bye for now. Bye for now. Bye for now. Bye for now.