The first version of Funk could open pull requests. It could file issues, move cards, and nudge a branch that had gone quiet. It demoed beautifully. We removed all of it two weeks before launch, and the product has been better ever since.

Write access changes what a tool is for

The moment a tool can act on your repository, every conversation about it turns into a conversation about trust. Which scopes does it hold. What happens if it misfires at 2am. Who reviews what it opened. That is a reasonable set of questions, and answering them well is a whole product in itself. It is just not the product we wanted to build.

We wanted the thing you open on Monday to tell you where you actually stand. That job is finished the moment the page renders. Adding a button that changes something turns a five-second glance into a decision, and decisions are exactly what a status page should be making easier, not heavier.

What read-only bought us

Onboarding collapsed to one screen. Most providers offer a read-only scope, so connecting Funk is a smaller ask than connecting almost anything else in your stack. Security review, when it happens, is short, because the honest answer to what can this thing break is nothing.

It also made the scoring honest. A tool that can fix a stale branch has an incentive to find stale branches. A tool that can only report has an incentive to be right.

The line we will not cross

We will keep adding signals, integrations, and ways to slice them. We will not add a button that writes to your code. If a score tells you something needs attention, the next click should take you to the provider, in the place you already trust, with the context already loaded.

What we gave up

Read-only costs us the demo moment. There is a version of this product where the score drops, you click one button, and the stale branch is rebased for you. It is a better demo. It is a worse tool, because the moment it exists you have to trust it at 2am, on a repository you have not looked at in three weeks, in a state nobody anticipated.

It also costs us a category of feature request we would enjoy building. Auto-close stale issues. Auto-bump dependencies. Auto-open a draft pull request when a branch has been quiet for a fortnight. Every one of them is reasonable in isolation, and every one of them turns a page you glance at into a system you have to supervise.

We keep a list of them. It is not a roadmap. It is a record of the things we decided not to be.

A tool that can fix a stale branch has an incentive to find stale branches. A tool that can only report has an incentive to be right.

What this means for your security review

The honest answer to “what can this break” is nothing, and that sentence does more work than any compliance document we could write. Read-only scopes are the smallest thing most providers offer, which makes the review a scope list rather than a negotiation. Several teams have told us Funk was approved in the same meeting it was proposed, which almost never happens for something that touches source control.

It also changes who has to approve it. When the answer is read-only, the decision often does not need to reach the person who owns production. That is not a loophole. It is the correct amount of process for a tool that cannot change anything.

We publish the exact scope list per provider, and we do not add one without saying so in the changelog. If a future integration cannot work read-only, we will not ship that integration.

The version of this we would build again

If we started over tomorrow we would take the write scopes out sooner. They shaped six weeks of work — permission models, confirmation dialogs, an audit log, a rollback path — and none of it survived. That is six weeks we could have spent on the scoring, which is the part anyone actually uses.

The constraint arrived late and improved everything after it. That is usually how constraints work, and it is why we now write them down before we write the code.

Written by