The New York Developer Meet-Up: Recap

Last week we gathered in Manhattan for the first interop.io NY Dev Meet-Up to discuss developer experience, automated testing, observability and practical AI implementation, with time to compare approaches with the engineers building the products and other teams using them.

We split into breakout sessions with experts to dive deeper into what they’ve seen work well, listen to the real struggles of people in the room, and make way for open discussions.

If you weren’t able to make it, I’ve summed up the event in this post.

What should a platform become as more people build with AI?

Leslie Spiro opened with a question: how can teams explore new ways of working with AI while continuing to support the users and applications they already rely on? As AI makes it easier for more people to build applications, the platform still has to help teams make those applications usable, connected and well governed.

“Everyone is now a builder.”

Leslie Spiro, CEO, interop.io

Developers, product managers, business analysts and users are increasingly joining the ranks of builders. It’s important to make entry easier while retaining control over shared capabilities. Platform teams need ways to see what’s running, support experimentation, and apply the right checks when something becomes shared. They also still have upgrades, fixes and existing applications to deliver. The practical challenge is serving both needs together.

Kalin Kostov’s developer experience update looked at some of the foundations for that work: recent improvements to our products, developer skills and AI-assisted development.

Creating an Observability Plan: Moving Beyond Health Checks and Log Files

The observability topic was the least familiar in the breakouts, but feedback from Ryan McNeely’s session on io.Insights proved how useful it can be. The problem discussed: an intermittently crashing application, no reliable reproduction, and thousands of log files from individual machines. The solution: centralize logs so diagnosis starts sooner, add metrics and alerts to find problems before someone reports them, and add traces to follow activity across services and application boundaries.

The example used an OpenTelemetry Collector with Loki for logs, Prometheus for metrics and Jaeger for traces, brought together in Grafana.

The discussion quickly moved into business analytics

Beyond diagnosing failures, the session covered business use cases, such as following a user’s path through applications. One example? Tracing an action in App A that changes something in App B through interop, then seeing what the user does next. Another use case was onboarding: could a team study the working patterns of experienced call-center staff and use those patterns to help new colleagues?

These questions connect telemetry to business processes, adoption, and the experience of using a platform. Making that useful requires more than collecting events. Traces can link technical operations across applications, and user-interaction data can show parts of a journey, but meaningful business stages and outcomes may need application instrumentation and business context. The aim is to understand a workflow by working with the people who do it, rather than assuming that activity or time spent alone shows which process works best.

From Build to Test: Creating Reliable io.Connect Apps

AI is getting better at writing code, but producing code that works with existing apps and within an existing platform requires understanding the configuration, other applications, integrations and the complete user workflow.

Checking one application’s functions isn’t enough. A useful regression check can follow a user action across applications and verify the resulting behavior. Running those checks after changes to applications, configuration, or the io.Connect version makes the integration something the team can test continuously.

Kiril Popov’s session explored how automated end-to-end testing can help teams check those connections, with practical examples to help people write tests for their own setup and CI/CD. An example scenario covers restoring a Workspace containing a people list and a details application, selecting a person in the first app, and checking that the second displays the right name. io.Connect APIs can be used together with WebdriverIO to interact with the UI and check the outcome.

Notes from the Field: Lessons from AI Implementations

Ivan Pidov’s session drew on io.Intelligence implementations over the last year and the lessons he learned from trial and error:

1. Shape data before sending it to the model. Tools should filter, paginate and aggregate so the agent receives the relevant slice. Large payloads produce throttling and slow responses even when the eventual answer was useful.
2. Keep business knowledge available on demand. Putting every workflow and piece of domain knowledge into the system prompts increased cost and distracted from the task.
3. Enforce cost controls in code. A company-wide spending cap was too broad for one misbehaving application. Ivan described gateway limits by user, application and group, alongside deterministic tool-call limits, result limits and sorting before results are capped.
4. Cache repeated input where appropriate. In some projects, caching reduced reported workflow costs from $6–7 to $1.50–3 per run. Stable content needed to come before changing content for the repeated prefix to remain useful. Cheaper repeated context still needs to be relevant context.
5. Establish a working baseline, then evaluate cheaper models. Ivan’s team began with a capable model, stabilized the workflow and reran the same real questions as they changed models. He reported later costs of $0.10–0.15 per run. These are results from that implementation, not a general price or performance guarantee. He also distinguished the estimated initial $10–12 per run from the later measured figures and said he would automate the evaluation questions earlier next time.
6. Shorten the feedback loop between people. Don’t wait for every stakeholder to read an email, find time to review and get back to you. Instead, run focused, time-boxed sessions with everyone present, as you would in a hackathon, and bring the technical implementation, business understanding and decision-making together. Produce something people can try and respond to while they are still focused on the problem.

Across these lessons, the model was one part of the system. The tools, data boundaries, visibility, testing and implementation process determined whether the result was useful enough to adopt.

Roadmap: Connecting the Work Across Build, Run and Experience

For the first time, Yordan Yordanov presented the roadmap through Build, Run and Experience, interop.io’s frame for the three groups every platform serves. Developers build applications, platform teams run them in production, and end users experience the result as one connected workspace. AI runs through all three rather than sitting in a separate track.

Build: make application development easier

AI kits to give platform and application builders better guidance for coding agents; support for business users creating interop-enabled applications; workflow orchestration (a user describes an automation in plain language, and the platform connects the actions across applications). The connectivity roadmap includes Outlook Adapter 2.0, with Slack and Zoom adapters under consideration (if you have use cases for those, please post in community.interop.io).

Run: give platform teams better control and visibility

Building on io.Manager’s granular permissions and environment migration, the next priorities include io.Connect release management, performance improvements and commands across multiple user sessions. io.Insights work extends telemetry across Browser, Java and .NET applications. Ideas under consideration include AI-assisted support and observability, a CLI for io.Manager and platform-trace visualization.

Experience: make connected workflows more useful

Priorities include mobile and tablet improvements, closer alignment across Windows, Mac and Browser, and extending Layout and Workspace sharing to Browser. Planned Workspace controls and Web Group tiling will give teams more flexibility over application arrangements. On the user side, workflow orchestration explores turning plain-language requests into automation across applications, while further ideas include embedded Office apps and better control over notification placement and acknowledgement.

What We Take Forward

The sessions approached different parts of the same problem. If more people can create applications and workflows, teams need ways to test them, operate them, understand how they are used and how to keep improving them. The real discussions made those needs concrete: tracing an action across two applications, comparing testing setups, keeping an existing observability backend while adding another, or preventing an AI workflow from quietly becoming too expensive to use.

If one of these topics connects to a problem you are working on, bring the use case to community.interop.io and we can continue the discussion there. If you couldn’t make it to New York but are curious about these topics, post in our community too.

If you’d like to dig into any of these topics, whether in a meeting, an online huddle or a follow-up conversation, contact us.