Suppose there's a complementary software project management methodology to what you're currently kinda doing (e.g., Agile, Kanban)... and someone built a tool for it that integrates smoothly with your existing GitHub/GitLab/Jira/Forgejo/etc.
For the sake of argument, assume that this is a project management tool that many kinds of teams -- both fast and slow, small and large, less-formal and more-formal -- would want to use. (Of course, different teams and companies will use it in different ways.)
To provide this hypothetical project management tool as an indie startup, I'm thinking:
* Solo indie development to start, hopefully soon bootstrapped with revenue, possibly never fundraising. (I already have the development and ops skill, domain expertise, and misc. small business experience; but fundraising would effectively burn up all my time.)
* Grassroots marketing. Pricing probably monthly recurring CC charge per-team/project, which a PM or tech lead in a larger company can just expense, to get going immediately. Hopefully per-team avoids high-touch enterprise sales sucking all my time and sanity.
* I want the tool to provide a Web UI to all team members, but I really don't want myself to be storing credentials to customers' GitHub/etc. So, I'm thinking, either package it as a Docker container that the customer self-hosts, or (less likely) as a desktop program with which each team member uses their GitHub/etc. credentials. I have to try to keep this from being much more adoption friction than going to a Web site, though.
* I'm going to use the customer's GitHub/etc. for their data, kludging in my additional semantics where necessary. I don't host any of customer's data on my servers, I don't require customer to set up a new storage service, and I don't introduce a new distributed system syncing problem between desktop local storage.
* I'd outsource the recurring billing&payments.
* I'd have a simple license compliance mechanism that only displays a nag message, but never blocks work (even if license seems exceeded for months, or license server can't be reached). I have a couple ideas of how to do this, which I think would probably work well, and probably avoid a situation like old popular shareware that became known as something everyone used but no one ever paid for.
* I'd try not to do any 'analytics' leaking from the customer, except for the minimal needed for license compliance (e.g., maybe just send one or two integers to the license server, for number of users and/or repos so far that month).
Obviously, I'm leaning unusually strongly towards not grabbing the users' data, nor making them dependent on my servers. Partly because that simplifies bootstrapping an indie startup, partly because of values about what's appropriate and what I'd like to see from vendors, and partly because it might make later bigger enterprise sales easy (e.g., security assurances). My money and leverage comes only from customers continuing to be happy running the software, and making that easy for them to keep doing.
Feedback appreciated.
Not sure how yours is going to be different, but I always welcome more options in the Anything But Jira™ world...
Re auth/user data, maybe you're overthinking it a bit...? You should be able to use sign in with Github and request certain permissions scoped to certain repos & operations without having to store their credentials or force them to self-host. (eg see https://docs.github.com/en/apps/oauth-apps/building-oauth-ap...)
As for storing project data, if you request read/write permission to those repos, yes you can put your own data in there, but that's probably not something every org would want to give you (as opposed to just metadata about their PRs, commits, comments, etc.)
I suppose you could build the whole thing to be self-hosted inside a repo, built to a Github Pages inside it and maybe run on Github Actions or similar... but I think that's a lot of complexity/fragility/maintenance burden over a traditional hosted SaaS like Linear, which basically just takes a few seconds to sign up and start using. And then you end up having to debug everyone else's infrastructure too when your app breaks in various ways, vs having one version that you control yourself.
Anyhow, good luck! Always exciting to see better PM tools.