aijoin team

An open-source workspace for teams who prefer tweaking their own tools and wiring AI into the way they actually work.

Sign-ups are currently unavailable.

What it's good at

Not a one-size-fits-all tracker. aijoin team is for people who enjoy adjusting their own workflow and AI wiring.

  • Start with simple projects and tickets, then bend the workflow to match how your team really works.
  • Invite teammates and organizations while keeping everything on top of your own infrastructure.
  • Try multiple AI providers or models side by side and keep their usage visible inside tickets.
  • Leave a light trail of who decided what and why through comments and small automations.

Why release as OSS

Open code and self-hosting make it easier to experiment with AI while staying close to your own rules and systems.

  • Run it next to your own apps and services so project data and AI prompts stay under your control.
  • Adjust the code when your internal rules or compliance change, instead of bending your process to fit a hosted service.
  • If something feels off, you can fork, patch, or throw it away and keep what you learned.

If you're happy with Jira, that's okay

There are plenty of great hosted tools. aijoin team is for when you want to tinker a bit more.

When hosted tools are enough

  • You don't want to think about infrastructure or upgrades at all.
  • Your process fits common workflows and permission models well enough.
  • Keeping everything in a vendor's cloud is fine for your data policies.

When aijoin team starts to make sense

  • You like changing your tools sometimes, not just using them as-is.
  • You want to connect multiple AIs or internal models and experiment safely around real projects.
  • You'd rather keep tickets, logs, and prompts inside your own cluster or network.

Sustainable business approach

The goal is to keep this hackable and alive, not to grow it into a huge product.

  • Support or consulting is available when needed, but the default is that teams can keep tinkering on their own.
  • Keep the main repo open so experiments, fixes, and plugins can flow back into the project.
  • Share setup examples based on the published Rails code and Dockerfile so people can start tinkering quickly.