Building the Next Generation of Software

AI does not just add a new feature to software but it changes what software is, how it is built and how fast teams are expected to move. In his talk at UXDX, Des Traynor, Co-Founder of Fin, shared the story of how Intercom rebuilt itself around AI, became Fin, and learned a hard lesson for every SaaS company: the next generation of software will not be won by better screens alone, but by deeper AI, faster teams and the courage to change everything.

The company that had to change or die

In August 2022, Intercom was not in a comfortable position. Revenue growth had been declining, the company was underperforming the market, and a new CEO had just stepped in. Then ChatGPT launched.

For many companies, ChatGPT felt like a new opportunity. For Intercom, it also looked like an existential threat. The company sold software for human customer support teams. But as people began using ChatGPT, the implication became obvious: AI was going to do customer service.

Des Traynor described the choice simply. Build a way for AI to do customer service, or die.

So Intercom chose to fight. The company built and launched Fin, its AI customer service agent. Slowly, the signs of life returned. Customers started to see value. The company invested harder, then went all in. Today, Fin is a $100 million business inside a company with $400 million in revenue. The company has since rebranded, with Fin becoming the business and Intercom becoming the help desk product.

That story can sound inevitable in hindsight, but Traynor was clear that it was anything but. The only thing that changed, he said, was everything.

Strategy changed. Mission changed. Culture changed. Values changed. How the company built, shipped, priced, packaged and sold changed. The brand changed. The product changed. The company name changed.

That is the first lesson from the next generation of software: real AI transformation is not a feature launch. It is a company-level rebuild.

You have to go too far

Traynor warned against the instinct to make the minimum possible change. Many companies respond to AI by adding a chatbot, a copilot or a few AI-powered features, then declare progress. It may create a useful press release or a good LinkedIn post, but it rarely changes the business. His advice was sharper: you have to go too far to know you have gone far enough.

That is uncomfortable. Customers may dislike the change. Teams may resist it. Shareholders may question it. Fans of the old product may feel alienated. There will be second-guessing, internal politics and constant “what about” objections.

But the alternative is worse. If AI is changing the shape of your market, preserving the old business too carefully may be the riskiest move of all.

This is especially true for SaaS companies. Investors, customers and competitors are all asking whether AI will eat software as we know it. Traynor’s view is that for many software categories, it already is.

AI changes what products are for

The first major shift is what teams build. Traynor argued that AI does not simply improve existing products. It changes product domains entirely.

Take project management or status-tracking tools. Much of their value historically came from helping people stay aligned: tracking progress, collecting updates, summarising work and showing what is happening across teams. But if AI can read GitHub, Slack, Google Docs, meeting notes and internal systems, what is the role of another tool that mainly aggregates information?

The product may still have a purpose, but it may not be the same purpose it had in 2021.

This is the kind of uncomfortable truth teams need to face. AI changes the underlying assumptions that many products were built on. Problems that once needed dashboards, workflows and manual updates may now be solved through agents that connect to the source systems and act on behalf of the user.

That means product teams have to rethink their boundaries. Where does a product stop when AI can connect to everything around it? If an HR tool can approve holiday, update a calendar, notify colleagues and adjust project planning, is that still HR software? Or is it becoming something broader?

Products are beginning to expand into the surrounding workflows they can reasonably own. Meeting tools move into account updates. Sales tools move into meeting notes. Knowledge tools move into project management. The old borders between software categories are becoming less stable.

AI changes the interface

The second shift is UI. For decades, software design sat somewhere between the command line and the graphical user interface. The command line was fast but hard to learn. The GUI was easier to understand but required screens, menus, buttons, navigation, labels and visual patterns.

AI creates a new interaction model. Users can say what they want.

In a spreadsheet, the old experience required users to learn conditional formatting. Product and design teams spent years making these patterns more discoverable, more usable and less intimidating. In the AI interface, the user simply says, “make the negative cells red”, and the software does it.

That does not just make software faster. It changes who can use it well. In the old world, some people were power users because they understood the interface. In the new world, everyone can become a power user by describing the outcome they want.

This has huge implications for product design. Many of the screens, flows and controls that teams have spent years refining may become less important. Traynor showed examples from Fin where AI can update help centre content by reading product information, identifying what needs to change and asking for approval. Instead of building multiple screens to help users find outdated content, review gaps and edit articles, the user can simply ask the system to do the work.

The interface becomes less about giving users every control and more about knowing what can be done for them.

It is not about adding a copilot

One of Traynor’s warnings was that teams often misunderstand AI UI. They start with an existing product and bolt on a copilot. But the future is not necessarily a chat box beside the old interface.

The deeper question is: when a problem occurs, how should the system handle all problems like this?

If a bug is reported, perhaps the system should file it automatically. If a policy changes, perhaps the system should update the relevant documentation. If a report needs interpreting, perhaps the system should generate the right visualisation on the fly.

Sometimes the right AI experience is a conversational interface. Sometimes it is a rule. Sometimes it is an automated workflow. Sometimes it is no visible UI at all.

This is why product teams need to think less in screens and more in outcomes. What is the user trying to get done? What inputs are needed? What can be automated? Where is human approval required? How reliable does the system need to be?

The best next-generation software will not simply be software with AI in it. It will be software rethought around agency, automation and reliability.

Reliability is the new design risk

Traynor made a crucial point for UX and product teams: in the AI era, the biggest risk is often not the interface. It is whether the AI works reliably enough.

In traditional software, most of the important parts were visible. You could see the screens, flows, buttons and states. Designers could reduce risk by improving interaction patterns and usability.

In AI software, much of what matters happens below the surface. The user may see a simple instruction box, but the real experience depends on whether the AI can interpret the request, access the right systems, take the right actions, handle edge cases and produce a trustworthy result.

This is where reliability becomes central. A workflow may have five AI-powered steps, each 95 to 99% reliable. That sounds strong individually, but when multiplied together, the full workflow may only be around 88% reliable. For an expense tool, a 12% failure rate is not acceptable. That means the experience needs a human in the loop, tighter scope or a different approach.

This is one of the hardest shifts for product teams. You cannot design your way around unreliable AI with a beautiful interface. If the system cannot perform the job consistently, the product will fail.

Start with what AI makes possible

Traynor acknowledged that this challenges traditional product thinking. For years, product teams have been taught to start with the customer and work backwards. He does not reject customer understanding, but he argues that in this moment, teams also have to start with what the technology makes possible.

That is because AI capabilities are still changing quickly. Customers may ask for things that are not yet possible to deliver reliably. They may also fail to imagine things that AI can now make possible. If teams only ask users what they want, they may chase impossible requests or miss more ambitious opportunities.

The work is to understand the technology deeply, decompose the customer problem and identify what can be done reliably today. This is where UX remains critical. Teams still need to understand the job to be done, break it into decision points, map inputs and outputs, and decide where automation helps and where human oversight is needed.

AI does not remove the need for UX. It changes where UX needs to focus.

AI changes how teams build

The third shift is how teams build. At Fin, the old product development process was no longer enough. Traynor described how the company abandoned design principles it had once been proud of because they belonged to a different era of software.

The old process was familiar: pick a job, design a solution, ship it, test it and iterate. In the new process, the team starts by asking what AI makes possible in the solution space. Then it asks what must be built, whether it can be done reliably and how to reduce the scope if reliability is not good enough.

That requires new muscles: scientific rigour, prompt analysis, prompt engineering, causality, empirical evaluation and a much deeper understanding of what is happening beneath the interface.

Design exploration also changes. Because AI makes exploration cheaper, designers can try more ideas, prototype more quickly and test closer-to-production experiences with users. Instead of choosing one direction early and refining it, teams can explore a broader solution space before committing.

Designers should ship

One of the most concrete changes at Fin is that every designer now ships to production. The company set a deadline: by August 1st 2025, every designer had to have shipped at least one change, even if it was only a typo fix.

The purpose was not to turn every designer into a full-stack engineer. It was to build the muscle of working closer to the product. Designers were no longer allowed to file tickets for certain fixes. They had to ship them. They also began vibe coding roadmap concepts so sales teams could show customers working prototypes rather than static ideas. Over time, designers began owning more of the front end, supported by a strong pattern library and tools such as Claude Code.

Engineering velocity also changed dramatically. Fin set a goal to double productivity and ended up tripling it. More changes shipped, defects reduced, production speed improved and code quality went up. The company spends a lot on AI tokens, but Traynor argued that the important metric is total cost per shipped feature. If token spend rises but productivity rises much faster, the economics still work.

Speed is the new moat

Traynor ended with the hardest message of the talk: there may be no durable product moats anymore.

Features that once took years to design, build and polish can now be cloned quickly. Beautiful reports, slick interfaces and complex workflows can be replicated by competitors with AI. A large codebase or years of history may buy time, but not safety.

In that world, speed becomes the only meaningful advantage. Not reckless speed, but learning speed, shipping speed and adaptation speed. Fast gets good before good gets fast because faster teams iterate more, learn more and improve faster.

That is a difficult message for product organisations built around slower cycles, careful handoffs and long planning processes. But Traynor’s point was clear: AI changes what you build, how you build and the momentum your team needs.

The next generation of software will not be defined by who adds the best AI feature to an old product. It will be defined by who is willing to rethink the product, the interface, the workflow, the team and the company around what AI now makes possible.

Want to watch the full Talk?

You can find the full talk here: https://uxdx.com/session/building-the-next-generation-of-software/

Or explore all the insights in the UXDX EMEA 2026 Post Show Report: https://uxdx.com/post-show-report