Skip to content
ProductDevelopment.io
Why ProductDevelopment.io

Built for teams where agents write code too

Coding agents now do real work, but they still plan from whatever you paste into the chat. ProductDevelopment.io gives them — and your team — one plan with its context attached: which application, which stack, which customer, which meeting, which rules.

What makes it different

01

Agents plan from the repository

UsuallyYou paste ticket text into the chat and explain the stack again, every session.
HereThe agent sends the git remote of the open codebase. The workspace matches it to the application and returns its tech stack, owners, active cycle and open tickets ordered by priority and blockers.
plan_context · plan-open-tickets →
02

Agents cannot overwrite your team

UsuallyA broad API key, and whoever writes last wins — including an agent working from a stale copy.
HereEvery write carries the version it read, so stale writes are rejected. Bulk edits of up to 100 tickets apply all-or-nothing. Agents get the role and read/write scope of the person who connected them.
OAuth 2.1 · versioned writes →
03

Work knows what it is built on

UsuallyThe stack lives in a README, and nobody decides who picks up a bug until someone asks.
HereEach application records its type, database, hosting, functions, frontend, backend and repository. Ticket-type rules set the default owner, starting stage and allowed stages.
applications · type rules →
04

Client calls become reviewed tickets

UsuallyNotes in one app, customers in a CRM, follow-ups retyped into the tracker by hand.
HereImport a meeting from Granola, a file or a paste. Action items are pulled out, you choose which become tickets, and each ticket links back to the meeting and the customer. Converting twice never duplicates.
customers · meetings · conversion →
05

Delivery dates from real history

UsuallyVelocity guessed in a spreadsheet, on charts that forget tickets that moved or reopened.
HereReports replay each ticket's history: cumulative flow, time in stage, lead and cycle time percentiles. The forecast runs 2,000 Monte Carlo simulations for P50, P85 and P95 dates.
12 report sections →
06

Your data stays yours

UsuallyYour plan sits in someone else's cloud, and leaving means an export request.
HereThe web app, REST API and MCP server run from one codebase on one SQLite database — built to run on your own server, with commands to back up, verify and restore it.
backup · verify · restore →
Side by side

Against the setup most teams run today

A tracker, a CRM, a notes app, a spreadsheet and a chat window full of pasted context. Here is what changes when it is one workspace.

What you needTypical setupProductDevelopment.io
An agent finds the plan for the repository it is inYou paste links and context into the chatplan_context matches the git remote to the application
Agent edits cannot overwrite a teammateDepends on the API; last write often winsEvery write carries the version it read
Agents act with a person's role and scopeOften a shared, broad API keyOAuth per person, read or write, revocable
Tech stack and owners recorded per applicationLives in READMEs and people's headsApplications with stack and per-type rules
Customers linked to the projects built for themA separate CRMBuilt-in customers, linked to projects
Meeting actions become tickets, linked backRetyped from a notes appGranola, file or paste; reviewed; no duplicates
Delivery forecast with probabilitiesAdd-ons or a spreadsheet2,000-run Monte Carlo, P50–P95
Run it on your own serverOften cloud-onlyOne codebase, one SQLite database
Who it is for

Made for three kinds of team

Studios and agencies

Several client applications at once, each with its own stack, customer and meetings — and one team moving between them.

Product teams coding with agents

Claude Code or Codex already writes real changes. Now it reads the same plan, follows the same rules and leaves the same trail as everyone else.

Founders who want their data

Your roadmap, your client list and your meeting notes in a database you can back up, verify, restore — and host yourself.

Your data, your server

One codebase. One database file. Yours.

The web app, CRM, REST API and MCP server are one TypeScript application on one SQLite database. It is built to run on a server you control — so your plan, your client records and your meeting notes do not have to live in someone else's cloud.

npm run db:backupOnline SQLite backup with a SHA-256 manifest
npm run db:verifyChecks a bundle before you rely on it
npm run db:restoreRestores to a new file, revokes copied access, pauses pending jobs
Access, the same everywhere
Four rolesOwner, admin, member and viewer — the same checks for the browser, Slack, the REST API and every agent.
Scoped accessOAuth with read or write scope and rotating refresh tokens, workspace tokens that expire, and sessions you can revoke.
Secrets encryptedSlack bot tokens and Granola keys are stored with AES-256-GCM. Passwords are hashed with scrypt, and logins are throttled.
Hardened requestsA fresh script nonce on every page, bounded upload sizes and read deadlines on the API and MCP endpoints.

And for the humans: C creates a ticket where you are,⌘K searches everything, in light or dark.

Straight answers

What it does not do yet

A private beta should say where the edges are. If one of these decides it for you, tell us — it moves up the list.

  • GitHub or GitLab pull request sync
  • Importers from other trackers
  • SSO / SAML
  • Email notifications for ticket changes (in-app and Slack today)
  • An AI model inside the app — your own agent does the thinking
Questions

The ones people actually ask

A product development workspace — tickets, cycles, roadmap, customers, meeting notes and delivery reports — built so that coding agents like Claude Code and Codex can read and update the same plan your team uses, under the same rules.

See it on one of your own applications

Request access, tell us what you build and which agent you code with, and we set up a workspace with you.

Request accessSee the product