A client finds something that needs changing on a website.
Today, that often becomes:
Client → screenshot/message → PM/QA → task → developer → clarification → fix → client review.
The problem isn't collecting feedback. It's keeping the context connected throughout the entire loop.
That's what we're building with Tweak.
The client reviews the actual staging site and points directly to the element.
From there:
Client request → issue created → team assigns it → developer picks it up → Cursor/Claude can receive it through MCP → developer fixes it → client reviews → request is closed.
The original request stays attached to the exact page and element throughout the process, so the developer doesn't have to reconstruct what the client meant.
We also have a retainer/request counter so agencies and freelancers can define how many client requests are included and see the usage as requests come in.
The goal is simple:
Don't just collect client feedback. Carry it all the way from the client to the developer and back to client approval without losing context.
If you're managing a website project with a client right now, I'll help you set up Tweak for free on one real project so you can try the workflow with your client.
How are you handling this workflow today?
Try it for free - https://tweak.page/
Top comments (4)
클라이언트 요청을 이슈부터 승인까지 한 맥락으로 묶는 흐름이 인상적입니다. 요청 카운터를 쓸 때는 “문구 한 줄 수정”과 새 화면 추가를 같은 1건으로 세지 않도록, 요청 유형과 범위 변경 기준을 시작 전에 합의하면 더 공정할 것 같습니다.
Spot on! That’s exactly the trap agencies fall into—a 1-word text fix gets treated the same as a massive redesign request in a flat revision counter. How do you guys currently draw the line between a standard revision and scope creep in your contracts?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.