Questions
Everything people ask
Including what isn’t built yet, which seemed like the fair thing to publish.
What it is
A living map of what you've built. It holds a feature graph for each project, which is the tree of what the system is rather than the list of what's currently in flight, and it attaches the status, the tickets, the docs and the decisions to each node.
It reads from Linear and GitHub, and your coding agents write into it directly.
Technical teams shipping several projects where a good share of the code is written by AI agents. Solo founders with a portfolio, engineering leads at small startups, and consultancies who have to report status to clients.
Linear tracks work items: things in flight that will eventually be done. Stemmory tracks the system those items are changing, including features you've decided on but haven't built, which have no ticket and therefore no home in Linear.
Stemmory reads from Linear rather than replacing it. You'll keep using both.
You already have a docs folder and it's probably out of date. It goes stale because keeping it current is a separate act of discipline from doing the work.
Stemmory parses those same markdown files and derives status from your tickets, so the map updates when the work updates instead of when someone remembers.
No. It maps features, not files or functions. What it stores is your documentation and ticket data, never your source code. See the data questions below.
Getting started
A GitHub repository, and optionally Linear. Both take one OAuth click. You can start with GitHub alone. Status derivation is the part that wants Linear.
Two changes, both small. Feature descriptions live in docs/features/*.md in your repo, one file per node, with a few lines of frontmatter. And your agents need an API key to write decisions.
Tickets, commits and reviews all stay exactly where they are.
The parsed path is configurable per repository. It defaults to docs/features.
Log out of Linear, log back in, then connect again. That clears it.
The message comes from Linear's own authorisation screen rather than from Stemmory. A stale Linear session makes that screen fail to load, and it reports the failure as a connection problem instead of a sign-in one, which is why reloading on its own does not help.
Connecting takes a few minutes. Getting a useful graph depends on how much of the project you describe in those markdown files. One file per feature, and the tree assembles itself from the parent field.
Data and security
Stemmory reads the markdown files in the path you configure, plus metadata from Linear, and stores what they yield — titles, frontmatter and short excerpts — not your source code, which it doesn't store or transmit. One caveat, stated plainly: reading any repository file uses GitHub's contents-read permission, which technically can read other files too, so the guarantee we stand behind is about what we store. The privacy policy spells this out.
Postgres, on Supabase. Every table has row-level security, so a query can only return rows belonging to your own workspace. That's enforced by the database itself rather than by application code that could forget.
Not to GitHub. Reading your repo is all Stemmory ever does there, and a suggested documentation stub comes back as a downloadable patch file you apply yourself, never pushed to your repo directly.
Linear gets one write, and it's opt-in: when you confirm a feature's mapping during onboarding, Stemmory adds a label named feature:<slug> to the issues you confirm — creating that label in your Linear team first, if it isn't there already — closing the loop back into the tickets it came from. It's limited to that one label. Taking it off those issues is one click; the label itself stays in your workspace until you delete it there. Outside that, connecting Stemmory can't alter, close or comment on anything in the tools you depend on.
Not by default, and you can change it per project. A project starts open to everyone in the workspace, viewers included. Set one to restricted and only the people you name can see it — owners and admins always can, because someone has to be able to find it.
Restricted means invisible, not merely locked. The project is absent from the dashboard, the project list, search and notifications, and its address answers the same “not found” a project that never existed would. That is enforced by row-level security in the database itself, rather than by application code that could forget.
Privileged actions like billing, members and API keys are restricted by role, and each one lands in an audit log admins can read.
Each agent key is distinct, so every write carries which agent made it and when.
The human handle and device name behind a write are stored either way. What's off by default is whether your teammates can SEE them, which is a workspace-level setting. That distinction matters: in an agency context the display becomes performance surveillance, but we're not going to pretend we don't hold the value.
Billing
Paddle. Paddle.com Market Ltd is our authorised reseller and the Merchant of Record for every order, which means they're the legal seller. They take the payment, issue the invoice, and calculate and remit any sales tax or VAT owed where you are.
Your card statement and your receipt will name Paddle.
Yes — 14 days on every plan, and it runs at Portfolio level so you try the best version rather than the cheapest one. A card is required up front and the first payment is taken when the trial ends; we email you 3 days before that happens.
One click on your subscription page inside the app. No email, no support ticket, no retention call.
Paid access runs to the end of the period you've already paid for. After that the workspace goes read-only rather than away: the graph, the decisions and the journal stay there and stay readable, and sync stops. You can undo a pending cancellation any time before it takes effect.
Both directions, from inside the app, once your first payment has been taken — plans cannot be switched mid-trial. Monthly to annual is prorated against the time you've already paid for, so you pay the difference rather than a full year on top of a month you already bought.
Annual to monthly credits the unused remainder against future invoices. Neither one needs a support ticket.
Yes. A full refund within 14 days of your first payment, no questions asked.
Renewals aren't covered, because you can cancel from inside the app at any point during the term. Paddle issues the refund, since they're the Merchant of Record, and it goes back to your original payment method.
Full details are in the Refund Policy.
For new subscriptions, yes, any time.
Not for you. Once you are subscribed you keep the price you signed up at, for as long as the subscription continues — a rise in the list price does not reach existing subscribers. What can change is what a plan contains, and that only ever takes effect at a renewal, with at least 30 days' notice so you can cancel first.
Your workspace and its graph stay where they are. You lose access to the product, not the record.
Prices are listed in USD. Paddle shows your local currency and any tax due at checkout, before you pay.
Limits and roadmap
Being specific, because publishing it is the fair thing to do. The MCP server reads the graph and writes decisions — decisions only. Agents cannot create features, change statuses or edit anything through it. A token can be limited to the projects you choose, but inside that limit it acts as an admin: it reads restricted projects there too. Scope the token; project access is about people, not machines.
There's a dashboard that opens after sign-in, with rows for what needs attention and decisions from across the workspace, plus an activity feed for the workspace and for each project.
Agent tokens exist for the MCP server, which reads the graph and appends decisions. A general-purpose REST API doesn't.
Stemmory is built by one person, and is early. That's a real limitation, and it also means a well-argued request reaches the person who writes the code.
The product is sold by Adyrix Systems Private Limited through Paddle. Support goes to support@stemmory.com and is answered by the person who built it.
support@stemmory.com, answered by the person who built the product.
Something not covered
Write to support@stemmory.com. It reaches the person who built the product.