AI can build your apps. Who’s going to run them?

The build got cheaper. The run didn’t.

Ask an AI coding assistant for a customized market data visualization app and you can have something running before lunch. Ask for a second app that reacts to the first, and you can have that by the afternoon. So it’s a fair question: if AI can build our apps, can’t it build the platform that connects AI-built apps too?

It can certainly write code. But building was never the most expensive part of a desktop platform. Running it is: keeping hundreds of apps defined, configured, versioned and supported, for every user, on every machine, every day.

AI doesn’t make that part easier. It makes it even more complex, because it lets you create far more apps than you could before. Finding a way to control and manage that operating layer is what io.Manager is for.

More apps means more to run

When an app took a team a quarter to build, the number of apps grew slowly enough for a platform team to keep up. When it takes an afternoon, it doesn’t. Every new app, whoever or whatever wrote it, brings the same operational questions:

• Who can see it, and which version do they get?
• Which layouts and workspaces does it belong to?
• Which configuration does each desktop receive, on which platform release?
• When a user says it’s slow, is it the app, the machine, or the platform?

AI answers none of these for you. It just means you have to answer them more often.

What running it actually looks like

One trading firm we work with runs more than 160 web apps, over 500 saved layouts and 250-plus workspaces across hundreds of trader machines. They use io.Manager as their solution.

Here is what running that environment involves (the screens below use sample data).

Every app, defined once. Apps are registered centrally, with who can see them and where they run. Add them one at a time, import definitions in bulk, or pull them straight from an FDC3 App Directory. An app generated by AI on Tuesday goes through the same front door as one your team spent a year on.

Every desktop, accounted for. Traders often spread their apps across several machines and monitors. io.Manager tracks each machine, its user and its display setup, so the platform team knows exactly what an app is running on before anyone files a ticket.

Layouts and workspaces everyone can share. Traders save their window arrangements as layouts and workspaces, and io.Manager stores them centrally, public or private, with an owner and history for each. That turns out to matter as much to developers as to traders. When a trader reports a problem in one panel of a layout, a developer opens the same public layout and reproduces it without leaving their own development setup. With io.Connect now running on MacOS, that includes the Macs most developers work on at this firm. 

“Whenever a trader says they’re seeing an issue in a particular layout, developers can go straight to that layout and replicate it. It makes us more productive.”

— interop.io client at a US trading firm

Configuration works the same way: io.Manager can serve settings for each io.Connect release from one place, so a new app or a platform upgrade picks up the firm’s settings instead of inventing its own.

Proof of what’s slow, and what isn’t. When a user reports that the desktop is slow, io.Insights sends CPU and memory telemetry for the platform and every app into the observability tool you already use. The platform team can look at one user’s machines, spot an app whose memory keeps climbing, and settle the question without pulling in endpoint engineering.

“It gives us a view of what the user has and what they’re dealing with, without having to involve all the endpoint engineering teams. We can see io.Connect’s memory and CPU usage on each of their machines and dispel any misattributed issues.”

— interop.io client at a US trading firm

When something does go wrong, io.Manager’s diagnostics let the team pull logs, refresh a page or restart a user’s desktop remotely, and review crash reports and user feedback in one place. See it in action in the io.Manager Command Center video, and for hands-on detail, our community guides to diagnosing high desktop CPU usage and growing memory.

Can’t AI just build that too?

It can build a version of it. An AI assistant can easily produce a config server, an app registry and an admin screen in a week or two. The code is the cheap part. What you’ve actually signed up for is a second product that your firm now owns, for as long as the desktop runs.

That product has to authenticate against your identity provider, whether that’s Okta, Auth0 or your own. It has to run on the database your infrastructure team supports, whether that’s MongoDB, PostgreSQL or SQL Server. It has to serve the right configuration to every platform release still in production, upgrade without breaking the desks that depend on it, send telemetry to your monitoring stack, and give support staff a way to reach a user’s session when something breaks at 7 a.m.

io.Manager ships with all of that, maintained by a team whose only job is this product. None of it is yours to build or maintain. Every hour your engineers spend building and patching it is an hour not spent on the business workflows that actually set your firm apart.

AI-built apps need more governance, not less

AI also changes who builds. Apps that once came only from a central engineering team now come from desk developers, quants and business teams, often faster than anyone can review them. That’s a good thing, as long as they land somewhere governed.

With io.Manager, every app is registered in one place, with an access list that controls which users and groups can see it. Configuration comes from one source, so a new app inherits the firm’s settings instead of inventing its own. io.Insights shows how each app behaves in production, so an AI-generated app with a memory leak shows up on a dashboard before it shows up in a trader’s complaint.

Not everyone who works on the platform needs the keys to all of it, either. io.Manager 4.0 adds granular permission groups for individual resources and actions. A support team can inspect sessions and crash reports, a platform team can manage apps and configuration, and another group can have read-only access to layouts, so access follows least privilege as the number of teams and apps grows. The io.Manager 4.0 release highlights have the details.

It also keeps the people building those apps close to the people using them. A developer who builds with AI in the morning still needs to see exactly what a trader sees in the afternoon: the same app definition, the same layout, the same settings. Because io.Manager holds all of that in one place, the developer can load the trader’s environment on their own machine instead of guessing at it.

The more apps you create with AI, the more you need a platform that keeps them manageable, consistent and supportable.

Start with one workflow

Let AI do what it’s good at: helping your teams build the apps your business needs. Let io.Manager do what it’s built for: running them in production.

You don’t need to replace your existing applications or commit to a big-bang transformation. Start with one workflow or one business unit, show the operational and engineering benefits, and expand as the business case grows.

That’s how the firm above has done it, moving apps off Java Swing and older technologies one at a time, with every new web app landing in the same managed environment.

Bring us one of your current or planned interoperability initiatives. We’ll map the management services you would otherwise need to build, and compare the effort, cost and time to production with io.Manager.