How I Gave My Clients a Direct Line Into My App's Backlog Using OSC

Every developer who does client work eventually hits the same wall. The client has feedback. They drop it in Slack, copy someone on an email, or bring it up in a call. You write it down, convert it into a ticket, guess at the priority, and try to keep the context intact. Half the time you lose something. The other half you're playing telephone between what the client meant and what ends up in the backlog.

I wanted to cut that loop out entirely.

What I built

I run a few apps on Eyevinn Open Source Cloud (OSC), a managed cloud platform where you deploy your own code alongside 180+ unmodified open source services, without touching Kubernetes or DevOps. Last week I used the new My Apps Collaborators feature to give clients a direct line into the app's backlog. No OSC account required on their end.

Here is how the invite flow works. From the My Apps dashboard, I generate an invite link for an app. I send it to the client. They follow the link, enter their name and email, and get access to a simple request form tied to that specific app. They can submit feature requests, bug reports, whatever they want to flag. No sign-up, no subscription, no OSC credentials.

On my side, every submission lands in the app's Agentic SDLC queue rather than my inbox.

The triage loop

This is the part that actually saves time. When a collaborator submits a request, an AI agent picks it up before I ever see it. The agent categorises the request, checks it against the existing backlog to catch duplicates, and decides whether it is actionable. If it passes that filter, it gets structured as a ticket and added to the backlog. If it is vague, out of scope, or already covered, it gets flagged rather than silently dropped.

By the time I open the backlog in the morning, the client's raw input has been processed into something I can actually act on. I am not doing intake triage. I am making decisions on pre-filtered, structured work items.

That is the Agentic SDLC model: AI agents handle the repetitive cognitive load around request handling so developers can stay focused on building.

Why open source matters here

Client projects have a tricky ownership question. You are building on infrastructure that the client will eventually depend on. If that infrastructure is a proprietary SaaS with vendor-specific APIs, the client is locked in the moment you ship. That is a liability.

OSC is built entirely on open source software. Every service I deploy is a managed instance of something that already exists as an open source project. If I ever need to move off OSC, or if a client wants to self-host their setup, the underlying software is not going anywhere. There is no lock-in by design, even when AI agents are making infrastructure decisions at speed on my behalf.

For client work specifically, that matters. I can hand over the stack with confidence.

Where it goes next

Collaborator documentation is coming. The feature shipped this week, so the docs are still being written. Once they land, onboarding a client will be a five-minute process.

If you work on client projects and the feedback-to-ticket loop is burning time, this is worth a look. Try it at osaas.io/my-apps.