Product Engineering, AI Operations[Launched]

The PM: Project Data Without Reporting Friction

The PM: Project Data Without Reporting Friction preview

System Architecture //

Next.jsTypeScriptJira REST APIConfluence REST APIOpenAISupabaseOAuth 2.0

1. Product Overview

The PM was my product for teams that live in Jira and Confluence but do not want to dig through filters, JQL, reports and dozens of tabs every day

The idea was simple: a manager, lead or founder asks a question in natural language, and the system finds the relevant data in the team's work tools and returns a short answer with context

This was not another dashboard built for the sake of having a dashboard. I was building an interface to existing operational information, so people could ask about tracked time, tasks, status, projects, risks and decisions in the same way they would ask a colleague

2. The Problem

•Jira contains the data, but answering a simple question often requires knowing the right filter, JQL or reporting structure
•Team activity is split between Jira, Confluence and local project context
•Leadership does not need another panel; they need a concrete answer about time spent, work completed, ownership and risk
•Confluence stores decisions and documentation, but the relevant passage is not always easy to find through ordinary navigation
•An AI answer without source access would be unreliable, so every answer had to be grounded in live Jira, Confluence or local data

3. What I Designed And Built

•A single chat-first interface for questions across Jira and Confluence
•A natural-language layer that identifies intent and selects the right data source
•Time-tracking queries covering total hours, project, user and task breakdowns, plus top-3 and top-5 results
•Task lists without complex filters: In Progress, missing tracking, time thresholds or project scope
•Read-only Confluence search with concise answers about decisions, risks and project context
•Jira and Confluence synchronization into a local database for faster queries, metadata retention and future offline analytics
•OAuth authentication, encrypted user credentials and access checks before touching connected data
•A deliberate MVP boundary: read-only analytics first, followed by synchronization, scheduled questions, export and controlled write operations

4. Architecture And Delivery

Natural-Language Questions

The user could ask something like “how much time did we track last week and what did it go into”. The system interpreted the intent, built the Jira API query, calculated the result and returned a compact answer without unnecessary reporting ceremony

For task lists, the answer included issue key, summary, status and time spent, so the user could move from a total number to specific work items

Hybrid Data Model

I separated the product into two data paths. Metadata such as projects, issue types, keys, summaries, statuses, assignees, sprints, Confluence spaces and page metadata was synchronized locally

Fresh or heavier data, including worklogs, full issue descriptions and page content, was fetched through the API when needed. This kept the product responsive without sacrificing freshness

Source-Grounded AI

The LLM was used to understand the question, map intent to Jira or Confluence and post-process the response. The facts themselves had to come from connected systems rather than model assumptions

That distinction mattered: The PM was an interface to working data, not a generator of confident but unverifiable answers

A Safe MVP Boundary

Creating and editing issues, automation and complex permission schemes were intentionally kept out of the first version. The product had to answer reliably before it received the authority to change Jira or Confluence data

5. What The User Got

•One clear interface instead of manual switching between Jira, Confluence and reports
•Management answers without requiring JQL knowledge or deep Jira expertise
•A fast view of tracked time across projects, people and tasks
•Confluence decisions and risks found through ordinary questions
•An architecture ready for scheduled reports, Slack or Teams, exports and controlled write operations

6. Technical Result

The PM became a full product MVP built with TypeScript and Next.js, with a chat-first UI, Google authentication, Atlassian OAuth, Jira REST API, Confluence REST API, OpenAI integration and Supabase for user data and synchronization

The most important decision was not one AI feature. It was connecting natural-language intent, user permissions, live data sources and a short, verifiable answer

Similar solutions now exist on the market, which is exactly why this project remains valuable as experience: I took a real operational pain point through MVP constraints, product architecture and a working interface that makes complex project data easier to use

Ready to solve a similar challenge?

Building reliable systems requires precision and experience. Let's discuss how surgical engineering can restore pace to your product