From programming at ten to bootstrapping a company
Yuriy: Hello everyone. Hello Adam. Thank you for joining us.
Adam: Hello. Thanks. Nice to be here today.
Yuriy: Adam, I'm super happy that we have a chance to have a conversation with you. With your experience being a developer forever and working with the Navy and Department of Defense, I guess you're one of the most experienced people in creating successful products in regulated industries, and also with AI. So can you tell me how did this experience help you to be where you are now?
Adam: It was good. I mean, in life you have lots of experiences. There are things you do and along the way you think they may not be important, but as you get along in life you realize how useful they were.
So I started off as a programmer. I was a programmer at the age of 10, if you read my bio. And back in the United Kingdom in the mid '80s, software, computers was a very empowering thing. It let you as a person build things that others wanted. And I remember writing computer games when I was about 10, and people at school thought they were cool. And when you're a geek in school and people think things are cool, that makes you feel cool, which is nice.
And then I went to university and I ended up getting a job in IT rather than in my degree, which was physics. And I really loved the idea of computers at the time, because it was the beginning of the internet age and the world was really opening up. You could work anywhere in the world. I moved to the United States after college and I worked in the IT industry, working with some commercial clients and then, as you mentioned, the government and defense and things. And the great thing with computers, you could work in any industry. So I worked in telecommunications, finance, and then I did some government work. And I got to work with people from other parts of the United States and other countries. And I just think technology is a really good opener, and as a developer you get to try out all these different things. You get to work in these industries, you get to solve complicated business problems, you get to meet clients, and you realize how technology is such an enabler for the world.
And then in 2006 I left where I was working just to found my company. And I think being a developer was very helpful, because if you need to raise money to pay someone, that means you've got to go find funding, and that changes the trajectory of your company. So I bootstrapped Inflectra, and because I was the first programmer, I didn't have to pay a salary to myself. I could just take my kids out of daycare and just be a stay-at-home dad, and I did that part-time whilst coding the very first version.
So I think having been a programmer, having the business experience from my former job, gave me optionality in life. It gave me the optionality to found a company, build the first version myself, have the business skills from working in IT before that in how to do sales, how to do marketing. Whereas I think if I'd left college and tried to start a company, which a lot of people do out of the gate, I feel like I wouldn't have had those skills. I didn't do an MBA, I didn't have a business education. My parents weren't working on Wall Street. So I didn't have some of those advantages that people have. So by going to work in an IT consulting business for eight, nine years, I learned some of those softer skills and business, accounting, sales, collections, how to collect invoices, how to do revenue recognition — things that as a programmer I wouldn't have been exposed to. But when you look at the fact that I could have been a programmer and I'd done these jobs together, it gave me that ability to start a company and bootstrap it.
And so, why bootstrap it? Well, one of the things I thought at the beginning was: how do I start a company? I've got a young family. If I raise money, I'm going to be working 100 hours a day. I'm never going to see my young family. So for me it was a lifestyle decision. And for those that listen to this podcast, if you've not started a company because you feel like you haven't got the time, your lifestyle doesn't allow it — bootstrapping is a much more affordable, available option. And especially with AI now making programming more accessible to non-programmers, I do feel like it's a great option to build a business, and allows you to do it at your own pace and your own scale, and have it work with your lifestyle.
Raising money is great. Everyone reads about the hundred million ARR companies out there, but people forget there's a lot of problems that you can be solved at two million ARR. A small company that can solve a very specific niche can be done without raising a lot of money, and you can do it as a solo entrepreneur or a small business. There's just lots of great problems out there that you can solve. Just do it easier, cheaper, better, better usability. I think a lot of people just don't appreciate that.
So, I guess the long answer is to say I feel like being a programmer as a background, spending some time in business and industry, was a great nurturing experience for starting my own business.
Why he built a company around the work he hated
Yuriy: But you didn't select the easiest area where to work. Quality assurance and regulated industries is not the main idea for developers to work in, because a lot of people usually hate regulations.
Adam: Yeah, they hate regulations. Well, when we started the company, it was just testing and QA. We hadn't taken on the regulated industry piece. It was just QA. And I have to tell people — I always tell people — I hate QA. I hate testing. I really hate both with a passion.
So how it happened is, I was working on the project for the US Navy, and we had to run testing, and I was the project manager. I'd moved from being a tester to project manager and architect, and my colleague and I were running testing, and we hated it. We had spreadsheets, we had whiteboards, we had printouts, and we had like US Marines and US Navy personnel literally typing manual tests and writing down the result on paper. And we had to pay people overnight to take what they'd written down, put it into an Excel sheet so we could track the testing. It was insane.
So I said to my friend, there must be tools out there that could do some of this. And there were, there are tools — but they were hundreds of thousands of dollars, they were incredibly complicated to use, and their deployment was a massive IT undertaking. And I said at the time, there are modern SaaS platforms out there that could do some of this. Why has no one done this yet? And I said, this is — it's not that hard. It's not rocket science. I had a physics degree. I know what rocket science is. My son is an aerospace engineer. He does real rocket science. I don't. This is just software.
So my friend said to me, "Well, go ahead and do it then." So I said, "All right, I will." So I waited a year or two till the timing was right for me and family, and then I left the company and started the business. But my friend had inspired me by challenging me, to say: there's a problem. We know there's a problem because we're facing it.
So I think when you ask me why did I pick QA — it was just a problem that I saw that I was experiencing, and other members of the company, the Sapients, were experiencing. So I knew it wasn't my unique problem. So if people listening to this podcast think about, do I have a problem that can be solved? Venture capitalists will say, "Oh, what's your total addressable market?" and all that stuff. What's your TAM? I think at that point I was just thinking: well, I know I've got a problem. I work in a consulting firm. We have this problem. And I might have colleagues working at other consulting firms that compete with us. They also have that problem. I've spoken to them. So I feel in my intuition, in my gut, there is an addressable market. And I know that our company can't afford it, and we're a consulting firm. Well, we choose not to afford it, I should say — they could afford it, but they chose not to. It would make the project unprofitable. So I realized that if you look at the economics in the market, there's the gap in the market, and that's why I chose it.
And then the regulated industries came later, when we wanted to further differentiate ourselves against other companies that then got into the market, because we were one of the first. Others started to follow us, and we realized that there was a higher price point and a stickiness that you get by getting up to those more regulated clients than simply everyone. Now, we do sell opportunistically to everyone, but our go-to-market and our white papers and our messaging is more geared towards the high-compliance industry customers. But we do sell to anyone who wants to buy with a credit card.
And that's another thing to remember: opportunistic selling is different to marketing. We'll sell to everyone, but we focus on driving sales and marketing to specific audiences. And I think as a small company you have to often do that. You can't always be 100% focused on one customer profile, but you can't market to everyone because you haven't got the budget — $100 million to spend on ads. I remember seeing Monday.com and — what was it? — ClickUp wrapping entire buses and trains in every major city with adverts. I'm thinking, my mother knows about these companies. She has no idea what these companies do. So that's mass marketing, right? A highly unqualified audience, but that's saturation marketing. When you're a small company, you haven't got that kind of budget. So you have to know your ICP, but you also going to be opportunistic as well.
What changes when you sell into regulated industries
Yuriy: So basically you solved the problem you fell in love with, because you hated doing some part of the work, and then you switched to more complex industries, but ones that are sticky. From your experience in consultancy working with different types of products, what are the differences in mindset when you switch to regulated industries? Are there any? Because at the beginning everybody solves the problem, but I guess the mindset and the process for developing the products may be a bit different. It's not fail fast, because the mistakes are expensive.
Adam: That's a good question. I think maybe because we're uniquely servicing QA, QA even in a small company to some degree mustn't fail. It's funny — our audience, at least initially, was testers, and I would say now with our bigger focus we see project managers, VPs of IT and risk managers, but the core market was always testers and QA. Now, they will find any fault with any software, even if it's a two-person company. So I would say on the quality side we've always had to have that high bar of quality, because if you're going to persuade someone who's testing other ERP systems or websites to use your product, they can't turn off that part of their brain. They will find the bugs whether they intend to or not. So I feel like for us, at least, quality was a constant, whether it was a big customer or a regulated customer or not.
The big thing that changed, I would say, between the two was really around configurability, compliance, traceability, auditability and, unfortunately, content. So when you're selling to anyone who's building a website or anyone who's going to do an app test, you can have relatively high-level marketing. The application doesn't have to have a lot of enterprise-type features like audit logs, tracing of every single change that was made. There's a lot of features that you build for the administrator that you don't need to build for a non-enterprise, non-compliance-focused customer. So I would say the ratio of functionality for end user to admin becomes quite different. That ratio changes when you hit the compliance market, because they're going to want things like single sign-on, OAuth, LDAP. They're going to want audit trails of system change. You change someone's role, you change someone's account permissions — audit log is necessary. SIEM integration, APIs, a lot of those enterprise features, MFA, they become really important.
Secondly, you've got to spend a lot of money on things like SOC 2, ISO 27001, all of the audits, and those are time-consuming and require an organization that is willing to implement these changes across the organization. We're not a big company, but it was a huge undertaking to get the SOC 2 and ISO certs, because what it meant was we had to behave like a big company. And I mean that we had to become bureaucratic. For example, before that, we could simply say, "Oh, we're going to change someone's role." We change their role in Google Workspace. Now we've got to log a change request. It's got to go to someone. It's got to be approved. Even to make simple changes in the company, now we have to have an audit trail and record — and we use our own tool to do that, actually.
But I think it just made it, from a very free-wheeling culture where everyone was like, "Oh, we're all going to get along and we all make decisions informally" — when you're working in high-assurance industries, they expect you to follow a more stringent set of processes internally. So I think it was the culture change around that, and some people really hating it, and some people actually left the company over it, because they said, "I didn't want to work at a company that was this bureaucratic." And I'm like, "Well, we're not really that bureaucratic, but we are more than we were 2 years ago, but we have to be." So I think that was a huge change.
And then I think also marketing — you have to write a lot more white papers, because you're going to go work in life sciences. Well, there's 10 white papers for life sciences that they have to have to understand how to configure the tool. And you might need a third-party consultant to work with you to help your customers get the most value out of using this. So it does increase the complexity of onboarding, increases the complexity of marketing, and it does increase the complexity of sales. We do mostly self-service sales to the opportunistic clients. We do mostly directed discovery call, demo, POC to the larger clients in the regulated space. So it does change your go-to-market. So I think those are some of the things to think about.
And the product itself — you have to also balance that usability versus complexity. That's always a hard one. People say, "I want it to look like Jira. I want it to be usable, but I also want to have all these features that they don't have."
The enterprise sale is a ten-person journey
Yuriy: So you mentioned you're also using your product. That helps you to understand what you want to build, what kind of features to add. But now your main persona is buyer persona, not the user persona, because if an admin buys the software, that's good for business. Do you see any changes in how companies buy software? Is user satisfaction getting more important, or is it still the buyer persona who decides?
Adam: Oh, it's interesting. It seems to change a lot. Wow, how do I answer that question. It's always a multi-faceted buyer.
So I would say certainly we're selling into teams. If we were selling a product that you would buy as an individual — so let's say we had software that you as an individual would buy yourself, like an IDE or a tool for me as a developer, for me as a tester — then I think the user persona is almost the most important. They like the tool, they've got a credit card, it's under their limit, they go buy it. We're selling team software that has to appeal to at least a team of about 10 people, maybe an enterprise of several thousand. So it's always going to be a multi-faceted user-buyer persona.
So what we see is, first of all, there's the end user who has the problem. So this might be the tester, might be the QA manager. That's one persona. So it's the beneficial user persona.
Then you've got the impacted user persona. These are the adjacent users that aren't going to benefit from the product, but they need to use it for the other people to benefit. So for that example, a developer. They might not want to use a tool to do bug tracking or project management or testing. They'd rather use what they're doing today or just use Excel or Google Sheets. But if they don't fill the data in, then the managers and the testers won't benefit. So they often can be roadblocks. They can be what we call bomb throwers.
Then you have like the economic buyer, as you mentioned — this could be the VP of IT. Then you have the compliance teams. Then you have the actual purchasing department, and they have other goals. They may have goals to buy from certain socio-economic groups or certain countries, or they have a master service agreement with a big company which they want to buy from, and maybe you subcontract. So it's like a 10-person journey when you're selling into these medium to large companies as an enterprise sale.
SMB is a bit different. We don't do as much SMB, it's more medium business. If you're doing small businesses, then often the CEO is like, "I want this tool. I'm going to buy it. The users, they'll use it." I think larger companies, the VPs and CIOs, they're never going to use this tool. Maybe look at dashboards. So you have to think about: I want functionality that I can show to the CIO as a nice dashboard. I want to have the end users find it not so frictionful that they hate it. I want the people who benefit from it to love it. The people who have to use it, to at least tolerate it. And I want the procurement people to at least think it complies.
So I'd say we've seen much more of that. And before they talk to you, I would say there's much more research people are doing. They're going to ask AI. They're going to go to ChatGPT or Perplexity, and they're going to say, "I'm looking at 10 tools in my segment. Tell me about them." They're going to go to G2 Crowd. They're going to go to Capterra. They're going to go to PeerSpot. When they talk to you for a demo or even a trial, they have probably read five or six pieces of content, and they have questions — and maybe they've got hard questions that you haven't even thought of.
So I would say the buyer is an informed, researched buyer. And you, as a product marketer, product salesperson, product owner, you have to give all those pieces of content in every format — video, text, you name it. And you need to start thinking about where are they searching, where are they going.
We're spending a lot of money right now not just doing SEO, but doing — I guess I don't know what the new term is, but SEO for AI. So our SEO company, they run giant queries every day, every possible set of questions that people are asking, and they run a sentiment analysis and they run a visibility analysis. And every week we meet with them and they'll tell us, "Well, this week Inflectra as a company, relative to its competitors, went up by 2% in visibility, but went down 1% in sentiment. Where do they get that sentiment from? Well, there was a negative review on G2, or some AI somehow managed to come up with an answer that was negative. Where do they get that source from? Let's find that source."
So it's very much a real-time analysis you have to do to understand what your users think of you, where are they posting content, and where are the AI engines getting their content from. It's often your users. So you have to keep users happy after you bought. It's an endless cycle. It's very interesting.
How Inflectra added AI without adding a chatbot
Yuriy: Yeah, it's definitely an interesting time. And regarding AI, as I know you're also adding some AI features to your product. What is your experience now? Are you happy with the value it provides? Because everybody is hyping that in a few years almost everything will be automated with AI. What are your thoughts on that? Do you actually have some numbers to measure the success ratio of AI quality assurance, for example?
Adam: I can, actually. It's interesting. We were an early adopter of AI. Two and a half years ago we added AI into our products. We first did it with a bring-your-own-LLM model, so we could test out different models and get it to market quickly. We've replaced that now with a natively embedded AI using Amazon. We're an AWS partner. We're actually a GenAI partner of AWS, one of only 58 companies in the world.
So we really worked fast to work with Amazon, because we recognized a couple of things. Companies, especially in high assurance, are not yet ready for AI, or they weren't ready a year ago. But other fast-moving companies were already moving in this direction. And they're not thinking of QA. Look at what everyone is doing or has been doing — marketing and blog and content writing; they've been doing code generation, lots of code writing; agentic AI writes lots of code; and they're doing a fair amount of chatbots and assistants. But no one's been thinking about the quality of the AI, or even using it to catch up with the code. So people are writing more code, the quality's deteriorating, and from QA standpoint it's actually been a nightmare.
So what we did is we said, let's think about what are our clients trying to do. And let's look at the application. Let's look at the friction points in our app and let's use AI to solve them. So rather than just throwing it — we could easily just said, "Well, everyone's got a chatbot, a copilot. Let's throw a copilot into our tool and we'll wash our hands of it and say, you got your AI, there you go, have fun." We didn't do that. We took a user-centered approach. We said, what are the challenges with our product? Where do people spend time?
And if you look at our tool, what they were doing is they get a requirement or they write a requirement for a user story, and they have to write test cases. They've got to write tests. They've got to automate the tests. They've got to identify the risks. Are the requirements any good? No, they're probably rubbish that someone wrote. How do we review those? How do we improve them? And that's what took time.
So we actually added built-in functionality using AI. We weren't selling AI. We weren't saying, "Here's AI." We were saying, "Here's some new functionality to review requirements against the industry standard and automatically improve it for you." Let's have it write 20 test cases for you automatically. You can then edit them, and that will be much faster than if you wrote them by hand. Let's identify risks. What risks are in this new functionality that you're creating?
So what we did is we identified like 10 business use cases and friction points. So some of it was improving the quality of the data they had. Some of it was reducing the time to get from 20 test cases — which would take maybe 2 days to write, we now write them in 2 minutes. Now you have to edit them, obviously. We found, though, if you look at the time it takes to take a test case that we've written and edit it versus creating it from scratch, and the number of clicks it takes particularly, it's a 60-70% improvement in speed, and we've got clients that have given us this in testimonials. And they find one or two test cases they didn't think of, or risks they didn't think of, and the value there is a quality, which is: I would have missed that until we hit development, hit production.
So it's, A, reducing time, which is great. B, improving quality. And that's when I will go back to people saying, well, everyone's talking about speed, speed, speed. Well, AI can be a force for improving quality. It can be a force for decreasing quality if you just take its answers and go with it. So we've actually managed with our AI to improve quality and improve speed and improve satisfaction. And we did it using very simple use cases. The AI is not very complicated. An AI researcher would say, oh, it's so basic — but our customers say that's amazing.
I think that's the difference. Take a user-centered view. If you start with — you know, Steve Jobs always said this — start with what the user needs, not what they said they want. The user will say, "Oh, I want a chatbot, I want AI." No, no, that's not what you need. Let's study the user. Let's look at what they actually need, and let's think about what AI can bring value, and other things that are not AI, and let's give them to the customer.
I think that's the biggest thing I would say, my lesson I've learned throughout 20 years of running Inflectra — 19, almost 20 — and the 8 years at Sapient: your customers never know what they want until they see it. And the biggest mistake people will make is they'll ask the customer what they say they need, and you get 20 features. And then, instead — a good designer would look at the 20 features and say, well, these are symptoms of a problem. What's the problem? Let's give them one feature that solves all 30: the 20 they thought of, the 10 they didn't think of, and do it in one holistic way that is easy to use.
And I think when it came to the AI, we did that. We said, let's think about what can AI do for our customers, how do we make a solution that gives value, not just features. And I think that's why we've been successful with the AI. And I know in the testing space there's a lot of empty promises, a lot of hype. If you go to any conference right now in testing, they'll say there'll be no more developers, there'll be no more testers. You push a button, you get the app, and you push a second button and it tests it for you. And there's some truth to both of these things, but it's not the whole truth. So I think looking at what users need and what products need is a more complicated story than that.
Where AI helps testing — and where it doesn't
Yuriy: And do you also cover code reviews, or only testing?
Adam: We don't ourselves do code reviews. Other people, I'm sure the tools do that. We actually use GitHub Enterprise for a lot of the security testing. And we do some code generation, so we can generate automated tests, we can generate sample tests. And we do a lot of analysis functionality, and we want to do more of that. We can find flaky tests. We can also do some autonomous testing, where the AI can actually start to control the screen using visual testing.
Traditional automation is very much around clicking on a button, looking at the web page or the app, and if the app changes it can often break the test. So we're using — how can we use AI to make our tests more resilient and more like a user, and find usability issues? So there's some tools we're starting to integrate where you can tell the AI, "Is this a good page? Does this page look good? Has it got good usability?" And the AI will look at the page and give you a qualitative assessment.
So at the same time we're running a traditional functional test, which is click through the 20 steps in my workflow to get from a new flight reservation to a booked ticket — or an ERP might be, I'm going to make a purchase requisition and get our goods and complete the order. Well, in that 20-step process, which we can automate and we've done that before, we can now ask usability questions at key points. And the AI can look at the screen and will come back and say, "Well, this page violates some accessibility. This page has buttons of insufficient contrast. We think this is very cluttered. Or this application is not as usable as it was two versions back." So the AI can start to give you some qualitative measures in conjunction with some of the more traditional pass/fail metrics you get in testing.
So I would say we're not using it so much for code reviews, but we are using it for more of the heuristic side of testing, that's often always been human-centric. And if you look at AI generating code — if we are going to get to a world where we're generating 20 times the amount of code per person, who's going to test that? We don't have testers already. So I think having AI be able to speed up testing and increase quality, not decrease quality, is going to be critical.
Yuriy: I totally agree that it's always tempting to become platforms that cover everything, and then you're starting competing with tools that are specialized in reviewing the code. But it's also interesting, because I've seen a bunch of benchmarks about code review tools, and on average they produce much more false positives finding bugs. I guess that GPT-5 has the best metrics — only 50% of advices are incorrect, because they refactor some stuff that is not necessary, and you need to have this kind of experience. Because there are a lot of complaints that AI thinks that they are building rockets, or something that has to be for enterprise-level security, like they are building Amazon software. But actually for most businesses and solutions this type of complexity is not necessary, or sometimes it can hurt.
Adam: Yeah. I mean, our AI journey was very simple. Most of what we're using — we have two products. One is only using prompts. There's no RAG, there's no vector databases. It's just simple prompts and some good prompts, good testing and good use cases that deliver value. On the other tool we're starting to use some agentic work, we're starting to do some RAG, we've got some RAG and vector database embeddings. But again, very sparingly. In fact, what we vector-embedded was just the user manual. We took the user manual and we embedded that into the RAG, so that we could give the user very good answers and very good assistance. And then we also give the user the ability to give feedback.
But the automated testing code generation — it takes a manual test and it writes the automated test for you, and we've got a very high success rate on that, because it's conservative. We're not trying to do everything for the user. We're taking an app that they've already learned the page objects from, and we're just writing the code for them, or the codeless framework for them.
And because we're doing it in very simple, I think conservative steps, we're showing the customers: it took you 6 hours today to do it manually, but with AI you're now assisted to do it in 2 hours, and the quality is good if not better. We didn't say it would take 2 minutes. That level is not yet — that's coming. So it's like building slowly, showing value, showing productivity, building trust, building confidence is the way we've done this. We haven't tried to give them a rocket ship of AI. It's more like a faster car, maybe a different kind of engine. That's really helpful for them in accepting it as well.
The other thing is also change management. Everyone's really worried about them losing their jobs right now, and we're trying to show people this is AI that's going to help you change your work. It's not necessarily going to be the end of work as well.
Why agentic AI is a security problem, not just a quality problem
Yuriy: Also an interesting question — it might be totally stupid, because I'm not in your industry, but from my experience I do a lot of coding with AI. And as far as I understand, there are some areas of software development where you still need people to do it, like some APIs, integrations, when it's really hard to create end-to-end tests because everything changes on the fly. Do you think that AI can also help to handle this type of work, when you can use just-in-time testing with AI engines? Because we have MCP servers, we have CLI.
Adam: MCP is interesting there, because there are some tools now that can write MCP servers from an API. So if you've got an application with an API, you can wrap that with an MCP server, so the AI can write the code on the fly.
I do think AI will definitely speed up API testing, API integration, no doubt about it. A lot of the work of API integration is just boilerplate. It's so boring. It's copying Swagger files and writing code. I mean, AI, I think, will help with all of that.
Now, APIs get changed, they get broken all the time. They shouldn't. I have a big philosophy about we should never break an API. We have seven versions of our API to avoid doing this, and many other companies don't do this, and it's very frustrating for people who are building integrations. But that's the world we live in. So I think AI can certainly help speed up the testing of APIs. It's not going to be a panacea.
Now, is it going to be the point where an application will dynamically look at the API on the fly and be orchestrating it? That's what some people are saying. So I don't think we're there yet. That's where the AI is literally — it's like RPA, but with AI. So the idea there would be there's no static code for APIs. When I make a request, the AI on the fly builds the code, runs it, and then destroys itself, fully ephemeral. I don't think we're there yet. It's too expensive. AI is not fast enough, and it's too dangerous, because the API might be misinterpreted.
So I think AI is helping in terms of doing testing. It can write boilerplate code. It can speed things up. I don't think it's going to completely change how we do API testing yet. Potentiality is there, obviously — like any type of testing, it could do a lot of that work autonomously. I still think you'll need human oversight to it.
There's big issues on the cybersecurity side of that, of course. If you've got live APIs and someone's in your organization, a machine writing code, interacting with it — malware, that's a huge target for malware. I mean, you've now got an authenticated, authorized user inside the organization, inside the firewall, making authenticated, authorized calls against other APIs. To me, that is the most dangerous vector if you could get into that. So I think people are still very worried about that environment in production. I've been going to several CIO roundtables, talking to some CIOs in major banks and other large companies. I think that's their nightmare scenario. That's why they've been very hesitant with AI, especially when it's AI that's agentic.
Content AI is one thing, generative AI, because you can write false blogs that get you sued. You can write false HR manuals that get you sued. You can have false refund policies that can get you forced to pay penalties to customers. Even with the content side, there's risks. You can write a defamatory article, get it published. All that stuff happens. Now, with agentic AI, you've now got effectively a cyber hacker working on your payroll. So I think people are very worried about agentic AI autonomously.
It doesn't mean it's not going to happen. I mean, malware is already agentic. So you have agentic malware. So the fact that the cyber attacking world is already using agentic AI means we'll have to have agentic AI as a defender. It's an arms race. But I think big companies are still trying to grapple with that reality.
Why QA is becoming a more important discipline
Yuriy: I believe that you're in one of the most interesting industries now, because everybody is focusing now on generating code. But as you mentioned, quality assurance is becoming even more important. And somebody said that we expect a billion developers, people who will be trying to generate at least internal tools by themselves using AI — but then we still need people to do quality assurance and understand that software is secure and reliable. What are your thoughts on that?
Adam: I 100% agree. I mean, I think for us in the QA world, it's a huge industry opportunity. I think people who focus on the development community — I feel like that's a market that may be different, or more challenging.
I think a lot of developers may end up becoming testers, because — not because there isn't development work, don't get me wrong, there's always development tasks. But I think the number of developers we may need may be less relative to the number that graduated in that industry, and the number of tests we have may be under the number we need. So I do think we're going to see a slight reskilling.
People who may have gone into software, people who go into computer science — and I mean that in its broadest sense — always knew that it was never about programming. Programming is one piece. It's architecture, design. It's about scalability, maintainability, a whole aspect of computer systems. I think if you go into it with a computer science mindset, you're going to think of it the right way. You'll have many different jobs. And right now there may be more of a trend towards risk management, more of a trend towards QA. If you went to college and you thought, I want to be a programmer, and that's the job I want — that may be changing. So I think you are going to see a greater emphasis on QA, risk management, cybersecurity, performance, all of the functional and non-functional aspects, ethics, bias.
AI itself is difficult to test. So we're actually beginning to think about how do we test AI with AI. Because I don't mean using AI to test systems — we're doing that already. I mean, how do you test an AI system itself, when you ask it the same question 10 times and you get 10 different answers? That's a non-deterministic system, which is intrinsically harder to test than a deterministic system. So we made testing harder itself, as well as developing more stuff.
So I think those are the two big challenges of our era: how do we test more stuff, because we have more people slash machines together writing stuff, and the stuff we're writing is harder to test intrinsically because it's non-deterministic. We need to find new ways of doing testing and new tools, techniques, and I think there's a bigger opportunity in the testing space. I think the CEO of Cursor at a conference even said, how are we going to test all this? So they recognize this. It's a hard challenge.
And what I think anyone listening to this podcast looking to get into testing — I would say testing was always seen as a bit of a stepchild of development. Always was. I mean, I was the same. I was like, "Oh, I want to be a developer." But I think testing is becoming a much more important discipline. And risk management, too. I think a lot of the software disciplines in computer science will become more important. And maybe sexier, too.
The UI of tomorrow may not be built for humans
Yuriy: And you mentioned that you have some experience with user interface testing — like if it's correct, if it looks like the designs and matches the requirements and the accessibility requirements. What are your thoughts on that? Do you see the progress of the tools that we have, and what is the future there?
Adam: Wow. I mean, there's UI testing and UI design. So there's accessibility, and there's UI more generally.
Accessibility is becoming more important because it's becoming legal. I mean, Europe in particular, but even in North America somewhat. Much as regulation is a bad word. So I think on the accessibility side, first of all, that's becoming more important because there's now becoming real penalties for not doing it. And there are tools now that can make this better. Both AI and non-AI tools have made this easier than it was maybe two or three years ago. So I think accessibility is becoming more important and easier to do, and there are tools that are helping. And hopefully even the AI agentic tools that build the apps have this somewhat built in, maybe from scratch. At least they have an appreciation.
I've seen some developers who build horrible, horrible UIs. We had one developer who should remain nameless, who decided the first version of his application to make everything in plaid. Like, literally stripes, and I don't know what was going on. So developers are often horrible at making UI. Agentic tools like Cursor and so on — the app they build at least is vanilla. It's at least not maybe not terrible, maybe not great, but it's at least a starting point. So I think that's helping.
Now, in terms of usability design and testing, it's interesting. I always thought this would be a discipline that AI would be more difficult for, but I've heard that you can run a video recording of someone using an application through AI, and it can find in transcripts what are the key obstacles, what are the key points of improvement. So AI is already helping looking at traditional usability video recordings, and it can start to find key points and key assumptions. The challenge as a human, if you're watching a long video of someone using an app clicking through it, is it's hard to stay focused. It's quite tedious and mind-numbing. AI is starting to find patterns in what people are doing in screens, and be able to improve it.
Now, maybe the other question we should be thinking about, though, is what's the UI of the future even going to be? Because we keep thinking about screens, but the new XR glasses are coming out, and Meta's got the glasses, and there's been many abortive attempts — Google Glass was a failure, I think Apple Vision Pro has not been a success. But I think we're starting to get into the point where we're going to have more wearable UI, and that means the UI is going to be different. And obviously voice, if we're using AI assistants. Is the future going to be asking it to do things? Is the AI doing things? Because we always have thought about UI for humans, right? We build the UI for humans. Maybe the users are not humans.
If I'm going to book a trip somewhere, I'll ask my assistant, book my flight to Amsterdam — I'm going there in a few months. I need to stay at a hotel, can you book that for me? And it will do that for me. It will find the best price. It will use an agentic workflow to find my company's travel policies. It will go to the conference website, figure out whether there are any block-booked rooms. There's like 10 things I have to do today to do that. It would do all those using a series of agentic workflows and come back and say, "Here's your flight, it's sent to your phone. Your boarding pass will be in your SMS." If we do all that, maybe half of those UIs go away. Maybe there's a series of REST services and MCP servers. So the UI of tomorrow may be different.
Yuriy: We are currently exploring a lot of generative UI and voice conversational interfaces. But there is always a place for UI when it's faster. For example, if you need to explain or compare some information, talking about that or providing lots of text takes time — then you have a few icons, charts to show what works better for you. And if you need a confirmation, especially for regulation, you need buttons and signature boxes. But you don't want people to be afraid that AI didn't hear correctly — you said no and it said, "Okay, thank you for approval."
Adam: That's true. Yeah, and I think it's a really good point. Understanding what's appropriate for which medium is a really good point you make. Are we looking at everything to be visual? Are we looking for some things to be audio? What's the right medium for the right part of the transaction?
Yuriy: I guess it also depends on the environment, and a hybrid approach would be the future most likely. Like as we do this call with you today, I guess we will have similar interactions with AI. But do you have a call with your marketing managers or finances? You want them to share a screen to show you something, because you would still prefer to have visualizations.
Adam: Make sure they're listening to you and not multitasking. That sort of thing, too. Well, it's interesting though — think about, security has gone facial recognition. When I go through the airport now, in many cases I won't show a passport. I've got Global Entry in the US, I can walk straight in with my face. Now, if it gets hacked, it's a whole other story. But even that years ago would have been science fiction. So it's amazing what regulations will change, and maybe signatures will become a thumbprint, or maybe it'll be a retina scan, I don't know.
Assuring the quality of agents
Yuriy: There is a new industry — it's also about quality assurance of software, but about agent orchestration quality assurance. How do you assure that an agent behaves in the correct way? Is it traceability, is it about logging everything? It's still software, but it looks like all the new types of software are rising — there are companies who raise money for audio quality assurance, or model quality assurance, etc.
Adam: We are looking at some of that. We've actually got some new R&D in the works that I can't talk too much about, where we're looking at potentially ways to assure the quality of agents and agentic systems. We're working with our AWS partnership team, actually, on doing some of that, maybe getting some funding to do some things there.
But I agree with you, that's a huge issue right now. How do you guarantee these agents are going to do what they're supposed to do, and they're non-deterministic by their very nature?
And that's one of the things that people don't realize. When you look at RPA or traditional workflow automation, it's 100% deterministic. You script what it's going to do and it does it. The great benefit of an agentic AI type system is it can adapt to unexpected things that happen within parameters. The danger is it might do outside of its parameters.
For example, if it's fraud detection, a traditional RPA system would look at loan documents and it would know, if it's this or this or this type, do this; if not, do something else. AI can look at it and say, it's not — I haven't seen this exact case before, but it falls within my parameters, and I can do some research and come back and say, based on my research and my parameters, I can approve this loan, or I can maybe deny it. And it wouldn't be 100% deterministic. It might be based on it doing background research of its own, and then it knows to flag it to a risk officer. Now, that's not deterministic. How do you test for that? Much harder, because you're not just testing an algorithm with 100 different branching points, a decision tree. You're testing a decision tree that's being written as it's being used.
Yuriy: Yeah. One part is assuring the system is stably working up to 99.9% of the time. And another is how do you build this system and test during improvement and adding new features, new tools, new agents — that you didn't degrade that. You just added a new tool, but suddenly AI started using this tool instead of others that it has to be using.
Adam: Right. Right. Right.
Finding points of rejuvenation after twenty years
Yuriy: Thanks for the chat. What's very interesting is that you look like you're still the person who is just entering the profession, because usually this kind of engagement and love of the work you see in people who are starting their careers. You're here for 20 years, but it looks like you still like what you're doing, even if you mentioned that you hated quality assurance. What is your secret? How do you make yourself still motivated?
Adam: That's a great question. Easy to answer, maybe hard to replicate, I don't know.
First of all, I was very intentional building the company. I built the company to be a company that I enjoy working at. By bootstrapping the company, first of all — and I'm not saying you can't raise money and enjoy what you do. When you raise money, you create an event horizon. You create a 5-year window till you raise the next money, the next money, the next money. And we may raise money at some point, so I'm not saying don't ever do this. But certainly I was intentional about where I was in my life, what I wanted to get out of that.
And at each stage as the company's grown from being sub a million dollars to being where we are today — and also going from a small number of clients, mostly all online, to having a partner network, working with people around the world, expanding as larger accounts, doing things I hadn't done before, different types of marketing, hiring people who knew marketing better than me — I think it was the enjoyment of watching the company grow and building a team of people I like to work with. So I like working with my team most of the time. Occasionally we have arguments, so I won't say it's all the time, but most of the time I love coming to work. It doesn't feel like work. The team is a good team. Our clients are generally good. We're not stuck doing the same thing. We're building new functionality.
I mean, I think every so often you get into a rut. So I think two or three years ago, we had a web app, we had an automated testing tool, we were adding functionality, but it felt like we got into a bit of a rut. And if you'd asked me the question, was I still passionate? Yeah, somewhat, but maybe not as much. And then the AI came along, and it was like, wow, this is going to change everything. And I think five, eight years ago it was cloud, and before that was maybe mobile. So I think if you like what you do and you're open to the innovations, I think you get these new points of rejuvenation.
But if I was doing the same thing 20 years that I started doing 20 years ago — a small team building one app that did one thing, and it was the same go-to-market — I think we'd be bored, and I probably would have sold it or given up. I certainly wouldn't be as excited about it as I am today.
So I do think if you're going to be in a business for a long time and you're not going to try and sell it in 5 years, you've got to find these points of rejuvenation. Find things that challenge you. Find things that excite you. Find things that scare you. So I would say getting involved with AWS and building that partner channel, looking to innovate in AI, was kind of scary, because until now we hadn't really done that. We'd mostly been agnostic to the cloud. We'd been, whichever cloud you want to use, we'll use. We decided we're going to really partner with one, invest a lot of time and energy into that channel, into innovating, into building AI.
So I think every 4 to 5 years you have to rejuvenate what you're doing and find something new that excites you. Otherwise you're just going to get bored, and then you start to get jaded, and then you won't be excited about what you're doing. And I think then it's time to leave and find someone else who will run the company, or sell to someone. It's okay to do that. When you've lost the passion for what you're doing, it's time to think of something else, I think. Obviously you may need the money, so maybe you don't. But ideally.
Yuriy: Yeah, I totally agree. The first 5 years you learn a lot of new things, like marketing, sales, etc. And then hopefully there are some new things coming, like AI or new technologies, or a new size of the company and new challenges.
Adam: Yeah — partnerships, international expansion, hiring people in other countries, expansion, sales on the business dev side; on the product side, cloud native, microservices, mobile. I mean, there's been so many — React, the front-end technologies like React. Technology moves fast, and if you keep up with it — and you can't always change everything, obviously. You've got to have your products still working. You still got to support current customers. That's always the thing. You can't throw everything away and start again. But you can find ways, I think, to infuse new challenges, whether it's on the business development side or the operations side or on the technology side.
Yuriy: And I agree with you, as you mentioned, you need to have people who also like what they do, because that brings you this energy. If you're the one person who likes what you do, it would be hard. But if you have a team who mostly likes coming to the job —
Adam: Right. And one thing I will say that may be unpopular is that there may be times where you've got to let people go. If there are people you feel like are jaded at the company and have lost that passion, maybe they shouldn't be there anymore. We've had to do that too. So during the last 19 years, we've had times where we realized that someone who really loved working for the company when it was this size or worked in this way, they really haven't enjoyed the shift. They were staying because maybe they just needed a job, or maybe they stayed because they couldn't think of anything else to do.
Sometimes we've got to ask people to leave, because in the end, if you have people who are like a drag on the company, it starts to affect everyone else. So I do think as a founder and CEO, or if you're a leader in any capacity, you need to make sure the organization is healthy. And if you have people who are either just maybe jaded, or maybe toxic even, but even just people who maybe have been there too long — it's good for them actually in the long run for them to go somewhere else, because they're not really happy there. They're not making everyone else happy there, and I think it drags the company.
One book for the audience
Yuriy: Thank you. That was a very energetic and valuable conversation with a lot of gems. We talked about the progress of AI and software development teams, and your interesting and motivating story about founding the product, that you love what you do. Do you have anything you would like to leave for our audience at the end?
Adam: One thing I always like to think about is what would be helpful for other people. One book I read a long time ago when I started the company that would be very interesting, I think, for people — it's called Selling the Wheel. Maybe you read it. It's a great book. I think it talks about the different stages in a product life cycle, and it was really helpful for me thinking about the company.
It's called Selling the Wheel, and it's about someone who invents the wheel. So there's no wheels, they don't exist yet. It's like the Stone Age. And the guy invents the wheel. And everyone's like, "What's a wheel? Why do I need a wheel? I don't need a wheel. I've got a buggy, I can pull it along, it doesn't need a wheel." And I won't spoil the book, but the whole point is there's different parts of the product life cycle, and using the analogy of the wheel it's really helpful in looking at your new idea and saying, where is this idea on the innovation spectrum? Because how you develop it, how you fund it, how you sell it is completely different.
And I think it really helped me understand that we were building a product that was in many ways a competitive product to what existed already, but cheaper, better. It wasn't wholly new. And that meant we marketed in a certain way. If you're building something that's completely new and revolutionary that no one's heard of, it's a different kind of product, different kind of marketing. And I think that book is really helpful. It's kind of light reading. It's not too heavy. So I would say Selling the Wheel, great book. Really helped me on my product journey.
Yuriy: Thanks. I'll buy it today.
Adam: Thank you.
About Adam Sandman
Adam Sandman is the founder and CEO of Inflectra Corporation, which he bootstrapped in 2006 after nearly a decade working in IT consulting with commercial, government and defence clients, including the US Navy and the Department of Defense. Inflectra builds software testing and QA tools, with a go-to-market focused on regulated, high-compliance industries. The company is an AWS partner and, per Adam, a GenAI partner of AWS.
