ReponaHQ Blog
Why I'm Building Repona
Why I'm building Repona for small development teams, what I think is missing from today's tools, and how I plan to approach it.
Most software projects start with a problem someone can’t quite stop thinking about. Repona is one of those projects for me.
I’ve spent a lot of my career building software and working with the systems that support it: repositories, CI pipelines, deployments, issues, pull requests and the decisions that connect them. All of these tools matter. But the longer I work with them, the more I notice how much of the real story of a project lives between them.
A pull request tells you what changed. An issue usually tells you what someone wanted to happen. The reasoning behind a decision, the alternatives considered, and the context a teammate needs six months later? Those are much easier to lose.
That’s one of the reasons I’m building Repona.
Small teams deserve thoughtful tools
I’m interested in the teams that don’t have a dedicated platform department or the time to maintain a complicated collection of integrations. A group of two to fifteen developers can do remarkable work, but every additional workflow has a cost.
A small team still needs the essentials: code hosting, reviews, clear work tracking and a way to understand why the codebase looks the way it does. The challenge isn’t a lack of features. It’s making the useful pieces work together without creating more administration than the work they’re meant to support.
I want Repona to be approachable for those teams. Not a miniature copy of every enterprise development platform, and not another dashboard that asks people to keep the same information up to date in three places.
The context around code matters
Some of the most valuable engineering conversations happen before a line of code is written.
Why did we choose this architecture? What trade-off did we accept? Is the constraint that shaped this decision still true?
Architecture decision records, or ADRs, are one way to preserve those answers. I’d like them to be a natural part of the development workflow rather than documents that are created once and forgotten. Decisions should be discoverable, linked to the work they affect and useful to the next person who comes along.
The same thinking applies to issues, code reviews and other project knowledge. Better connections between them can make the work easier to follow.
Where AI fits
I’m also curious about what agent-assisted development can become when it’s grounded in the actual context of a project.
There’s plenty of excitement around asking an AI to write code. That’s useful, but I think some of the more interesting opportunities are in the surrounding work: finding relevant decisions, understanding the history behind a change, or helping a team move a well-defined task forward.
I don’t want to bolt AI onto everything for the sake of it. The goal is to explore workflows where an assistant genuinely reduces friction, while keeping developers in control of what changes and why.
Starting small, building in the open
Repona is early. There is a direction, an evolving codebase and a long list of things I’d like to try. There isn’t a finished platform hiding behind a launch page, and I don’t want to pretend otherwise.
The initial focus is a solid foundation and a small set of connected workflows. I’m also interested in ways Repona might work alongside existing GitHub repositories, rather than requiring teams to move their code just to try a new idea. These are directions I’m exploring, not promises about what will ship or when.
Building something like this means making choices, learning where assumptions were wrong and occasionally changing course. I’d rather be open about that process than present a perfectly polished roadmap.
Why write about it?
This blog is a place to share the process: technical decisions, design trade-offs, experiments that worked and ones that didn’t.
Some posts will be about Repona itself. Others will be about the engineering problems and lessons that come up while building it. I hope those notes are useful even to people who never use the product.
For now, I’m building, learning and seeing where the idea goes.
If you’re working on a small development team and any of this sounds familiar, I’d be interested to hear what slows you down—and what you wish your tools understood better.