Anchor

Anchor scans new Jira tickets in real time and flags conflicts with past decisions contradictions, duplicates scope collisions before development starts so nothing gets rebuilt or reversed by accident

Comment

Inspiration

I worked as a founding engineer at an early-stage US startup building software for a deeply traditional sport(Golf). The nature of our business was fairly complex—we weren't improving an existing workflow, we were inventing one. Combined with startup velocity, business decisions changed overnight and requirements constantly evolved.

As time passed, team members left and new ones joined. Critical business logic and product decisions became trapped in people's heads. Context disappeared, undocumented decisions turned into "facts," and product drift followed.

What saved us was the engineering team's memory and product intuition. But that's not a solution. That's luck. And luck doesn't scale. So I came up with Anchor. A Product Decision Intelligence tool for Jira that helps teams stay aligned with their product’s core business

What it does

Anchor is a decision-intelligence layer built on top of Jira. Using RAG-based models, it continuously analyzes product documentation, historical Jira tickets, and past decisions to provide accurate, contextual insights for every new product decision using Open AI models for reasoning. Instead of relying on human memory, teams rely on what was actually decided—and why.

How we built it

Anchor's architecture is intentionally simple. Rather than over-engineering distributed systems, we focused on building a solution that delivers the best possible user experience with minimal friction.

When a product manager creates a Jira ticket, the Anchor Forge app captures the ticket's title and description and sends them to the Anchor backend. A RAG model using text-embedding-3-small embeding model then performs semantic search over historical Jira tickets to retrieve the most business-relevant past decisions.

These tickets are passed to Anchor-AI Model using gpt-5.6-luna model, which compares the new ticket against historical decisions, identifies potential business or product conflicts, and explains the reasoning behind them using historical context and business logic.

The resulting analysis is stored in the Anchor database and surfaced directly inside Jira, allowing teams to review conflicts and their explanations whenever they revisit the ticket.

Challenges we ran into

We had to reinvent the whole product architecture, migrating from fully AWS-based services to fully using Supabase, in 2 days with the help of Codex — which rewrote our backend queries and edge functions to match the new Supabase structure, making the migration far faster than doing it by hand.

We also worked on optimizing token usage and improving embedding match accuracy for the RAG pipeline.

Accomplishments that we're proud of

Developing and launching Anchor in less than 2 months, and getting approved on the Atlassian Marketplace.

Completing the full migration from AWS to Supabase in 2 days without disrupting existing users.

Solving a real problem for the teams who tried Anchor.

What we learned

I learned a lot, both on a personal and a professional level:

Most of the project was built with GPT, and a large part of the codebase (~70%) was rewritten using Codex. Working this way taught me how to develop a fully working prototype — and even migrate and optimize an existing one — using AI tools like Codex quickly and efficiently. Before writing a single line of code, you have to talk to people and find out if there's a real pain you're trying to solve. Build small with an intent to scale later. Don't build to optimize — build to deliver, and optimize when it's actually needed. Keep scale in mind, but don't over-engineer for it upfront.

What's next for Anchorr

Talk to more people and scale the current project — starting with the exact teams the Inspiration story came from: early-stage startups building fast, inventing workflows as they go, with high team turnover and decisions trapped in people's heads. That's the sharpest version of this problem, and where Anchor should prove itself first before expanding further.

Share this project:

Updates