The Problem: When the Roadmap Is Written Behind Closed Doors

At most software companies the roadmap is written in a meeting room. A user sends a request, the request becomes a support ticket, the ticket goes onto a list, and nobody knows what comes out of that list. We have lived that loop and know all three of its outcomes by heart:

• cancelAn invisible queue: The person who asked never knows where the work stands; "we are looking into it" stays true for months.
• cancelPriority by guesswork: Whatever matters is decided by the loudest customer or the most interesting technical problem.
• cancelDuplicated effort: Ten people with the same problem open ten separate requests, and none of them knows about the others.

We built the request board as the opposite of that. Every request is public, every vote is visible, every official reply of ours is written under the request.

“Every reply we write under a request is also a promise we make to ourselves.”

The Request: A One-Sentence Problem, Three Short Parts

Writing a request on the board does not take a technical specification. The requests that actually work are always made of the same three parts: what the real need is, why it matters, and how it is handled today. The last part is the most valuable. A sentence like "whoever has time on Tuesday fills in a 62-row spreadsheet" tells us both the size of the problem and the bar the solution has to clear.

Once a request is open, other users vote on it. When a request reaches 100 votes it goes into review. Our first official reply always says the same things: how long we aim to take, what it will cover and, most importantly, what it will not do. On the signature verification request, that sentence was "it will not tell a court anything".

Building: Time-Boxed, Narrow in Scope

We put a time box on every piece of work and write it openly under the request. Most requests go live within 3 to 5 business days. What makes that possible is that we write microservices that do one job instead of one big platform: Detector watches a single value on a page, PDF Editor redacts personal data in the browser, Subtitles turns a recording into text. A new request is often one floor below an engine that already exists.

It does not always hold, and we write that down too. The request to watch a single price on a page took 9 days, because three of the five suppliers built their prices in the browser rather than on the server. We noted that under the request on the first day of building; as a plan, not as a surprise.

While we build, we talk to the person who asked in the same thread. The best ideas often come from there. On the price watching request, "send the old and the new value together in the alert", and on the signature request, "show the reference signature next to the score", both made it into the product before the first release.

Live: Public to All, at Cost

When a request is finished it opens up not just to the person who asked but to everyone. It gets a "Completed" tag on the board, its product page goes live, and anyone can add it to their own Incapon dashboard in one click.

Pricing works with the same openness. You pay only the cost:

Model and server costs are passed through at their real unit prices; we add no margin and no flat subscription on top. If a tool costs you nothing in a month it does not run, the architecture was built right.

Requests that need privacy have a separate option: the tool stays entirely yours and never lands on the board. For the general tools that do land on the board, your database, your API keys and your identity are never shared.

The Lesson: An Open Board Forces Us to Think Narrower

A problem starts as a single sentence. Written in the right three parts, a few days later it becomes a tool anyone can use.