Ask any founder whether they get feedback and the answer is yes. A friend tries the app. A reviewer sends a long message. A customer emails a complaint at 11pm.
Ask what happened to that feedback, and the answer is usually vaguer. Some of it got fixed. Some got forgotten. The person who sent it rarely heard back.
What feedback-driven development means
Feedback-driven development is our name for treating feedback as the input to the build, not as a side channel. Every piece of feedback goes through the same loop, and nothing leaves the loop without a decision and a reply.
The phrase has been used before, for a developer's own habits and in academic work on code review. Nobody we've found uses it for what founders actually need: a dependable way to turn other people's opinions into shipped changes.
The loop
- Capture. Log the feedback exactly as it arrived, with the date and who sent it. Paraphrasing loses the detail you'll want later.
- Split. Break it into separate items, one per point, each with its own ID. One long message often holds five or ten different issues.
- Decide. For each item, choose one of three outcomes: fix it, respond to it, or park it with a reason.
- Ticket. Give every "fix" a ticket that links back to the original words.
- Ship. Make the change in small, reviewable pieces, with before and after screenshots.
- Reply. Tell the person what you did about each point, including the ones you chose not to act on.
- Close. Each item ends with a trail: their words, your decision, the ticket, the change and the reply.
The reply is the step most teams skip, and it's the one that matters most. People who see their feedback acted on send more of it.
Fix, respond or park
Not every point deserves code. The decision step stops a loud opinion from turning into a redesign.
| Outcome | When to use it | What the person hears |
|---|---|---|
| Fix | It's clearly right, and the change is in scope | "Done, here's what changed" |
| Respond | It's a fair point, but the answer is an explanation or a business decision | "Here's why it's like that, and what we're doing about it" |
| Park | It's valid, but not now | "Logged, here's when we'll revisit it" |
Decisions that change the business, like pricing, positioning or who you name on the site, always go to the founder. The loop makes them visible; it doesn't make them for you.
A worked example: our own site
We ran the loop on qeetoto.com first. A reviewer sent one message with ten separate points about the site.
- Captured and split into ten items, from "the landing page looks unfinished" to "the text colours are inconsistent".
- Decided item by item: most were fixes, a few needed a business decision, one was a partnership idea rather than a site change.
- Shipped as small pull requests, with desktop and mobile screenshots for each.
- Within two days, seven of the ten were closed, each with a written answer ready for the reviewer.
One point, "pages are too text-heavy", changed how we write everything. It became a site-wide rule: every guide now opens with a short answer box, like the one at the top of this page.
Why it works better than a feedback board
Feedback boards and roadmap tools are good at collecting requests and counting votes. They still leave the founder to triage, build and reply.
Feedback-driven development is the other half: someone owns each item until it's closed. For a solo founder with ten sharp comments rather than ten thousand votes, that's the half that's missing.
How Qeetoto can help
We offer feedback-driven development as an add-on to our Marketing & Growth service.
- Free to start: we'll capture, split and triage your feedback, and draft your replies, for any app.
- Fixes included where we run the product: we build and ship changes for products we host and run with you, for example through LaunchUK. For code we don't control, you get a prioritised list of fixes to make yourself.
Got a pile of feedback you haven't dealt with? Get in touch and send it over.