How Roleplane Solves Developer Context Loss to Improve AI Productivity

I wanted the AI assistants in a team to get the context they need for their job without everyone pasting it by hand. Developers should get the engineering docs and the repos, project managers the roadmap and the Trello board, support the runbooks and the help center. When I looked at how teams actually do this today, each person connects their own tools to their own assistant, or pastes the same background into every new chat. One person's Claude knows last week's decision, another person's ChatGPT still works from an old plan, and a new hire starts from zero. I also noticed that the more tools a company connects, the worse it gets, the AI gets everything a person can see, so the answers get noisier instead of better. Nobody owns that context, so it quietly drifts apart. A smart model with no context is just an expensive guess. So I started Roleplane, connect your sources once, shape what each role's AI gets, and deliver it to Claude, ChatGPT, or Cursor through one link.

It's too early for real numbers. What I can already say is that my first pitch flopped before it reached anyone. I wrote it around limiting what the AI can see, because that's how most tools in this space sell. Reading it back, that's a feature, not the pain. The pain is that each role's AI lacks the context for its job, so I rewrote the landing page, the ads, and the emails around that. Now I'm testing three messages against each other in twelve subreddits where developers, founders, and engineering leads hang out, with the same budget for each. For cold email, every first line has to mention something specific about the company, and each message goes out at around 9 am in the recipient's time zone. The landing page changes its headline to match the ad, so I can see which pain people actually click on and sign up for.

Usually about an unfamiliar way of managing context that they hadn't encountered before. I am trying to make the onboarding process as smooth as possible for them. I'm setting up the first pilots by hand. The team picks the pages, channels, repos, and servers for each role. I connect them read-only, and each person adds one link to their assistant. Servers get a separate user per role, a short list of allowed commands, and a log of every command, so nobody keeps SSH keys on a laptop. The first thing I expect to hear about is trust, who else can see the data, and how to switch it off. That's why every pilot is read-only, the access is created on the team's side, and it's deleted when the pilot ends. We agree on that in writing before I touch anything. The other thing I expect is questions about cost, since most teams already pay for Claude or ChatGPT seats. The founding price is $150 per month for a team of up to 25 people, and teams pay only after it works. I'd rather hear these questions now, while the setup is still manual and easy to change.

Most products in this space treat it as a security problem, which tools the AI is allowed to call. There are already a dozen well-funded gateways doing that, and some of them are free for small teams. But a team rarely loses work because the AI called the wrong tool. It loses work because the AI doesn't know the product, the decisions, or last week's incident, so it fills the gaps with a confident guess. The other mistake is giving every role the same pile. Connect Notion or Slack to an assistant and the engineer's AI wades through sales decks while support's AI reads code. Context has to be shaped per role, which pages, channels, and repos, trimmed or summarized, plus the rules that role's AI should follow. In practice, the best context for an engineer's assistant is small and current, the docs for the service they work on, recent decisions, the last incidents. Getting that right for every role is the real work. Access control is part of that, but it's not the point. You feel it in the answers, not in settings.

First, run pilots by hand with the first teams and learn which sources matter most for each role. Then build the self-serve version, connect Notion, Slack, GitHub, Linear, Google Drive, and servers once, describe in plain words what each role should get, and preview what that role's AI will see before applying it. Changes should work the same way, describe what to change in a chat, see the difference and what the role's AI will see, then apply it. After that, more connectors, chosen by what pilot teams actually ask for, and the same setup for new hires on day one.

The landing page has been live since October 2. Three Reddit ad messages start on October 12 across twelve subreddits, and the first pilot spots are open at a founding price of $150 per team per month.

I've worked as a software engineer and team lead for over eight years. Day to day, that meant writing and reviewing code and helping teammates get up to speed, which is exactly where missing context hurts the most, every new person and every new assistant has to learn the same things again. What I also bring is a habit of testing ideas before building them. I run each product idea through the same steps, research first, then a small paid test of demand, and only then code. Roleplane is going through that process right now, which is why the first pilots are set up by hand instead of with a finished product.

Starting with the wrong message. In the first weeks, I described Roleplane as a way to limit what each AI can access because that's how the market talks about it. It made the product sound like one more security tool, and engineering leads already have plenty of those. When I rewrote everything around the real problem - the AI missing the context for each person's job - the pitch got shorter and easier to explain. The lesson, describe the pain the user already feels, not the feature that solves it, and test the message before building more product. I'm now testing three different messages in ads before deciding which one stays on the landing page for good.