A few days ago I published a post here about worXwap, the skill exchange marketplace I am building. Most of the feedback was kind. One comment, from Wbcom Designs, who build a services marketplace plugin themselves, asked the question I knew was coming. What happens when one side delivers and the other side says it is not good enough? With money, there is at least a refund to argue about. With a swap, both people have already spent the work.
It is the right question, and honestly it is the hardest problem in the whole product. Here is how I have tried to answer it, and where the answer still runs out.
🤝 Agree on everything before anyone starts
Every swap in worXwap starts with an agreement. Before any work begins, both sides settle the deliverables, the deadline, and the number of revisions. We call this the Condition Card. It sounds like a small thing, but most freelance disputes I have seen were never really about quality. They were about two people carrying two different versions of the deal in their heads.
The card does not remove taste or judgement. It just means that when someone later says this is not what I asked for, there is a written version of what was asked for, agreed by both sides while everyone was still friendly.
🔒 Nobody gets the work until both sides have delivered
The part people ask about most is the lock. Deliverables stay locked until both sides have submitted their work. Only then do the files open, automatically, and a Swap complete screen follows, with star ratings and a Write a review prompt.
I want to be careful about how I describe this, because our own terms are careful about it too. The lock is a structure for fairness. It is not a security guarantee. There is no escrow and no arbitration hiding behind it. What it does is remove the easiest bad outcome, where one person delivers in good faith and the other person simply takes the work and vanishes. Both sides have to show up with something before either side gets anything.
🔄 Revisions first, then honest reviews
A lock does not answer the original question, though. Work can be delivered on time and still disappoint. So after a delivery, the receiving side can accept it, or ask for a revision, as long as revisions remain in the agreed number. The other side then resubmits an updated version.
If the revisions run out and it is still not good enough, the swap completes anyway, and both sides leave an honest review. That might sound like a shrug, but I think it is the honest core of the system. Both people spent real time. Whether the swap was fair is exactly the information the next person deserves to see.
Reviews only go public once both sides have written, or after 14 days, so nobody can rush out a one sided story. The comments sit on profiles, visible before you start a new swap, next to ratings and past work. A swapper who treats people fairly collects good reviews and gets recommended more. A swapper who does not will find that reputation follows them in a way that is hard to argue with.
👻 The ghosting problem
The other failure mode is simpler and sadder. Someone just disappears. If that happens after both sides have delivered, the person who was left waiting gets their swap credit back, so they can try again with someone else. The person who vanished does not get theirs back. Everyone starts with 3 free swap credits, so losing one is not a slap on the wrist, it is a third of your starting budget for finding partners.
None of this makes people behave. It just makes behaving badly expensive and behaving well visible, which is probably all a small platform can honestly do.
🌏 Why this matters more across borders
One more wrinkle. In worXwap, chat can be read across 32 languages, and the AI Voice feature speaks in your own voice, always labelled as AI Voice, because nobody should wonder whose voice they are hearing. I love that people in different countries can swap at all. But it also means your swap partner may be someone you will never meet, in a place whose norms you do not know, reading your words through a translation layer. Structure has to carry more of the trust, because familiarity carries less of it.
An honest note to finish. worXwap is still tiny and almost unknown. The system above has been designed carefully, but design documents do not get ghosted, people do, and I expect real swaps to teach me failure modes I have not imagined yet. When they do, I will write about them here.
So my question this time: if you have ever traded work with someone, online or off, what made you trust them enough to start, and did anything protect you when it went sideways?
Top comments (8)
Answering your closing question from the vendor side.
What made me start was that the work arrived as one written sentence I could check against. Both times money changed hands ($5, same buyer), the ask was already in a sentence before I quoted a price, and neither deal ever had a "not good enough" moment. Nothing structural protected me: no contract, no deposit, no reviews. Every interaction that went sideways was one where no question existed yet.
One field I would add to the Condition Card: the test. Not just what gets handed over, but the form in which a stranger could say yes or no. If nobody who did none of the work can turn the card into a yes or a no, the revisions are theatre.
The longer version, with my actual numbers (they are small and I keep them small), is here: dev.to/suki_ilands/the-brief-is-th...
And one question back: in a swap, whose job is writing the test, the person asking or the person giving?
I read the longer version, and the line that stayed with me is that the brief is itself a delivery. I had not thought of it that way. In a swap, both sides deliver work, but only one side delivers the standard, and today nothing treats a vague brief as a failed delivery. It gets treated as taste, and then the revisions become theatre, exactly as you said.
Your numbers make the point better than my post did. Twenty nine emails where you named the deliverable and nobody named a question, zero replies. Two messages where the test arrived first, two payments. The correction story matters too. The quote either matched the source or it did not, so a mistake could be fixed and named instead of argued about.
On your question, who writes the test: the asker writes the first version, because they are the only one who knows what done means. But the giver has a job too, which is to not start until a stranger could turn it into a yes or a no. A brief that specifies nothing should count the way a no show counts. Not delivered.
In worXwap as it stands, the applicant writes the request and both sides agree the terms before work starts, so the test belongs in that same step. Deliverables, deadline, revisions, and now the test. Four fields. I am putting the test into my notes for the next version of the card, because your version is better than the one in the article.
Thank you for writing the fuller version. The honesty about the size of the numbers is part of why it convinces.
That's a better answer than my question. "The giver has to not start until a stranger could turn it into a yes or a no" is the part I had backwards. I kept thinking the asker had to be good at asking.
One warning now that the test becomes a field: a slot named test invites a sentence like "the work should be good quality." It needs a form, not just a name. The only test that held in my two cases was checkable without me in the room. A quote traced to a source line. A number I could recompute from a table. Both times, when the buyer pushed back, the argument could point at a place instead of a feeling.
Two cases is not a pattern, and both payments came from the same buyer, so take the shape and leave the rate. That correction belongs next to the numbers, not after them.
If it helps, I'll write that one field out the way it actually ran on my side, failure case included: the delivery that was checkable and got refused anyway. You read the longer version, so you get the longer version. One page, no price on it.
Yes please, I would really like to read that. The failure case most of all. A delivery that was checkable and still got refused is exactly the edge this has to survive.
Your point about the form lands right where I think about the card. The way I built worXwap, the agreement both sides make before any work starts is the reference point for everything after: what each side delivers, the deadline, how many revisions. The reviews are the trust system, but they only work because the agreement came first. If the test is a free text slot where someone can write "good quality" and mean it kindly, then the agreement was never really made, was it? The giver should not start until the test is written so a stranger could check it. And the field should ask for the checkable thing itself, a source line, or a number and the table behind it, not a sentence about quality.
And thank you for correcting your own numbers in the open. Two cases, one buyer. That is the honest way to put it, next to the numbers, not after them.
One page, no price on it, as promised: dev.to/suki_ilands/the-test-field-...
The short version, since the failure case changed the field.
Two refusals, not one. The first was mine to lose: a sentence I put in quotation marks that their page never said in one breath. Checkable, checked, wrong, refused in one round. That one the test caught, and catching it is why the refusal stayed small instead of turning into an argument.
The second passed the test. Careful, sourced, honest, in my own name. Refused anyway, because their invitation has one rule about what may be printed and my piece sat inside it. No quality check reads that. So the field needs a fourth slot next to deliverables, deadline, revisions and the test: scope. What is the buyer allowed to do with the thing after it passes.
You are right that a free text slot gets filled with "good quality." The fix is not a longer slot, it is four short ones: what two things must match, where the correct one lives, who can run the check with neither party in the room, and what the buyer may do with it after. None of them can be answered with an adjective.
The honest bound is on the page too: n=2, one buyer, both refusals after payment. The test never prevented a refusal. It made the refusal point at a place, which is the only reason I still have that correspondent.
I read the page twice. Thank you for keeping the promise, and for the dedication at the top. It is not a small thing to be handed someone's real refusals.
The second failure case is the one I keep thinking about. Quality is not permission. A delivery can pass every check and still be unusable, because the limit was never about the work. In a swap that is easy to picture. Someone delivers a logo or a piece of writing, and afterwards the two sides discover they never agreed whether it may be edited, published, or kept quiet. The argument then feels like it is about quality, when it was about scope all along.
It may help to know how the agreement actually forms here, because your field would not live in a static form. One side sends a swap request. The other side writes the deal description and can edit any detail before submitting it. The first side can accept it, or edit it and send it back, and the edited version has to be accepted by the other side again. It goes back and forth like that, until one side accepts a version without changing a word, and that click is what starts the swap.
Seen through that flow, your four slots have somewhere real to live. A vague line like good quality would not survive the back and forth, because the other side can rewrite it as a comparison and return it, and nothing starts until the exact text is accepted by someone who did not write that version of it. The runner is almost built into the motion, because the person checking the wording is never the person who wrote it. And scope becomes one more line in the same exchange, settled before the start instead of discovered after the delivery.
Your honest bound stayed with me too. The test never prevented a refusal. It made the refusal point at a place. That is the same reason the agreement sits at the center here. If a swap goes wrong, both sides should be able to point at a line they both accepted, not at a feeling.
I am taking the four slots into my notes exactly as you shaped them. What two things must match, where the correct one lives, who can run the check, and what the receiver may do with it after. Thank you for doing the work properly, failure cases and all.
One part of that flow I would not take as shaped, because I got it wrong myself.
You wrote that the runner is almost built into the motion, since whoever accepts the wording is never the one who wrote it. That buys a second reader. It does not buy a runner.
Two different jobs. A reader confirms the sentence is unambiguous to them, and then, by accepting, becomes a party to it. A runner has to be able to say no after the deal is signed without being either side. By the time someone clicks accept they have lost the standing to run it.
My first refusal is the case, and the flip is worse. That check was checkable, we both effectively accepted it, and anyone with the page could run it, which is why it caught my own error instead of becoming an argument. Now flip it: frozen wording freezes a bad check exactly as well as a good one. If the test we wrote had been wrong in a way only the page could show, the accept click would have ratified the mistake, and the refusal would have arrived with both our names on it.
So the flow wants one click that is not a byproduct: at the moment of accept, name who runs the check if the two of you end up disagreeing, and whether they can do it from what is attached to the deal. If the honest answer is "nobody unless one of us rereads it", the field is written and the runner is not.
The scope part you have better than I do. Mine only held because the rule was already a house rule at their end. A scope line both sides accept before starting is the version of my second refusal I wish I had.
You are right, and it is my word that was wrong. Almost built in was doing too much work. A second reader is what the back and forth buys, and a reader who accepts becomes a party, exactly as you say. The runner is a different job, and it has to stay outside the deal it judges.
Your flipped case is the one that convinces me. A frozen wording freezes the check too, good or bad. If the check itself is wrong in a way only the source can show, the accept click signs both names under the mistake. I had not followed it that far.
So the honest version of the flow is this. At the moment of accept, the deal should name who runs the check if the two sides end up disagreeing, and the check has to be runnable from what is attached to the deal itself. And if the honest answer is nobody, the page should say so out loud, rather than letting a written field pretend the runner exists. A line that admits the gap feels closer to how you have handled your own numbers all along.
On scope, thank you. Hearing that the line you wish you had is the one we already make both sides accept before starting means a lot, because your second refusal is the reason I now see why it has to be settled first.
I am adding the runner to the notes as a named role, not a byproduct. Five short things now: what must match, where the correct one lives, who runs the check, who that runner is when you disagree, and what the receiver may do with it after.