A few weeks ago, I shared Tweak on Indie Hackers when we launched the first version.
A few weeks ago, I shared Tweak on Indie Hackers when we launched the first version.
Since then, we've been getting deeper into the workflow of how websites actually move from development to client approval.
We started with one simple observation:
Client changes can get messy very quickly.
A client asks for a change.
Then someone has to understand exactly what they mean, make sure it reaches the right person, get the work done, check it, send it back to the client, and sometimes go through the same cycle again.
When you're working on multiple client projects, those small requests can quickly become a lot to manage.
That's what made us think beyond simply collecting feedback.
The real opportunity is connecting the entire process from the client's request to the final approval.
That's what Tweak is built around:
Client request → team → developer → fix → client approval
The team can manage and assign those requests, while developers can take them directly into their development workflow through our MCP integration.
I'm looking for a few web agencies, freelancers and developers who regularly work on client websites.
If you're currently handling client changes through screenshots, WhatsApp, email, calls or a combination of different tools, I'd love to let you try Tweak on a real project.
No long demo.
Just use it on a real project and tell me whether it actually makes your workflow easier.
For those of you who work with clients:
How are you handling this process today?
And what's the one part you wish was easier?
Try it on one real project - https://tweak.page/
The request-to-approval chain vic666 described is where the real time goes. We build marketing sites and the feedback pattern is always the same: the client says "make the hero bigger," you interpret that, ship something, and then learn they meant something else entirely. The fix takes five minutes. The back-and-forth about what "bigger" meant takes three days.
What I would watch for as the product matures: the moment feedback volume exceeds what one person can triage in a morning, the tool stops being a feedback collector and becomes a prioritisation tool. Clients do not naturally rank their requests by importance, and the most urgent-sounding ones are rarely the most important. Does Tweak surface which requests are blocking go-live versus nice-to-have? Because that distinction is what turns a feedback inbox into a shipping decision.
This is a problem a lot of web teams probably experience but don’t really notice until they’re juggling multiple clients. I like that Tweak is focusing on the whole loop rather than just collecting feedback. The part connecting client requests directly to the developer workflow sounds especially useful. Curious to see how teams adapt once feedback, fixes, and approvals all happen in one place.
That request→approval chain is where stuff actually dies for me. Not the ticket itself — the “wait, which Slack thread was the real brief?” moment. If you keep the client’s original ask next to what shipped, half the rework vanishes.
Exactly. The “which version was the real brief?” problem is what we’re trying to eliminate.
The original client request stays connected to the actual element, and the team can manage and assign it from there rather than having the context disappear into another Slack thread or message.
The goal is that when something ships, you can still trace it back to what the client originally asked for.
Have you found a good way to handle that today, or is it still mostly spread across Slack, email and tickets?
The request-to-approval chain is a useful framing; the handoff between client language and an actionable task is often where context gets lost. I’d make the approval step capture both the exact change and a screenshot of the expected result, so “looks good” is tied to a concrete state and can be revisited later. For agencies, that audit trail could also reduce the back-and-forth when a client asks why something changed.
That's a really good point. Keeping the approval tied to the actual change is important, especially when you need to revisit what was approved later.
That's also why we're keeping the request connected to the actual page and element throughout the workflow rather than treating it as a standalone comment.
Curious — in your experience, is the bigger problem usually proving what was approved later, or getting the original request understood correctly in the first place?
The request-to-approval chain is a strong wedge because it preserves context that usually gets lost between screenshots and chat. For a real-project trial, I’d track time from request to first actionable task, number of clarification loops, and approval turnaround—not just tasks completed. A lightweight client-facing status view could also reduce “is this done yet?” messages without exposing the whole internal backlog.
I like the idea of measuring the workflow rather than just counting completed tasks.
The clarification loops and approval turnaround are especially interesting because they get closer to whether we're actually reducing the back-and-forth.
The client-facing status idea is interesting too. We're trying to keep the client experience simple while still giving the team enough visibility internally.
How do you currently handle status updates with clients when you're running several projects at once?
Careful you are not building a better pipe for free work. In two decades of running a services business the expensive problem was never routing the change request, it was that a frictionless request channel turns every quick tweak into unbilled scope and the agency eats it. If Tweak tagged each request in-scope or billable at intake and showed the client a running total of extras before approval, you stop being a workflow tool and start being the thing that recovers revenue, which is a far easier sale to an agency owner.
This is actually very close to something we’ve already built into Tweak.
We realised that making it easier for clients to request changes can create another problem for agencies — too many requests and unclear scope.
So Tweak includes a retainer counter that lets the team keep track of how many requests have been made during the month and how many are included in the agreed limit.
Your point about distinguishing in-scope vs. billable extras is interesting though. We haven't approached it exactly that way yet.
Given your experience running a services business, I'd be very interested to hear how you would structure that workflow.
The key insight is making the feedback routing visible. When a client request bounces through Slack/email/screenshots without a clear state, you lose track of what's actually in progress vs completed vs awaiting client approval. That opacity causes rework. By routing everything through Tweak, you're trading ambiguity for clarity - the client can see their request is being worked on, the team can see what's assigned, developers see the exact spec. Less back-and-forth equals less friction and faster delivery cycles.
Exactly — that's the distinction we're trying to make with Tweak.
The goal isn't just to move feedback into another tool. It's to keep the original request and its context connected as it moves through the team and eventually back to the client.
Otherwise, you can end up with a perfectly organised task that still doesn't represent what the client actually asked for.
That's the kind of ambiguity we're trying to remove.
The end-to-end flow makes sense, but I reckon the difficult part is preserving intent across the handoffs, not only showing where the request sits.
A client’s original annotation may become a cleaner internal task, then a developer may make a technically reasonable change that still misses what the client meant. I’d keep the original request, the team’s interpretation, and the approval criteria visible together. A before-and-after view could then let the client approve the exact change rather than a generic “completed” state.
The metric I’d watch is reopened requests or clarification messages per change. If Tweak reduces those, it is solving miscommunication rather than simply moving the same ambiguity through a nicer pipeline.
Yes, I agree — preserving the original intent is more important than simply showing the status of a request.
That's why we keep the original request and the actual element it refers to connected throughout the workflow, rather than turning it into a completely separate task.
I also like your point about measuring reopened requests and clarification messages. That would be a much better way to understand whether Tweak is actually reducing miscommunication.
We're now putting it into real projects, so that's something I'd definitely like to start tracking.
How are you doing now weeks later? Do you already have real users?
We're live now and are at the stage of getting Tweak into more real client projects.
We've had people try the product, and we're currently looking for a few agencies and developers who are willing to use it on an actual project and give us honest feedback.
That's really the focus for us right now — seeing how Tweak works in real workflows rather than just getting signups.
If you're working on client websites yourself, I'd be happy to let you try it on one project.
The end-to-end workflow is the interesting shift. Have any agencies run a real client change from request through approval in Tweak yet, and where did friction remain?
The insight about scaling client changes across multiple projects is the key here. It's not just about collecting feedback - it's about channeling it in a way that stays unambiguous from request through completion. Once that channel gets complicated, everything downstream gets worse (rework, delays, frustration).
Your flow makes the state visible: when you can see where a request is in the pipeline, you stop losing work to miscommunication. That's coordination through clarity.
Exactly. That's the direction we're taking Tweak — not just collecting requests, but keeping them clear and actionable throughout the workflow.
The team can manage and assign the issues, and developers can take them directly into their development workflow through our MCP integration.
The goal is to keep the context connected from the original request all the way to completion, so there's less room for things to get lost or misunderstood.
This comment was deleted 16 hours ago