Quick context: I'm a solo founder. Over the last few weeks I've been talking to freelance developers about one specific pain — getting burned by bad clients (non-payment, scope-creep, ghosting).
The insight I keep coming back to: every platform vets the freelancer for the client. Nobody vets the client for the freelancer. The information asymmetry runs entirely one way.
So I'm building Vettly — search a client before you accept the project, see reports from other freelancers, get an AI read on their brief.
I've had a few freelancers tell me they'd pay for it. Now I'm testing that signal more broadly before I build the MVP.
Landing page / waitlist: https://vettly-waitlist.netlify.app
Two things I'd love feedback on from this community:
Is the "vet the client" framing immediately clear, or did it take a second?
If you freelance — would you actually pay for this, or is it a "nice to have"?
Brutal honesty welcome. That's why I'm here.
This is exactly the kind of read I was hoping for, thanks for actually going through it.
On the input structure: you're right and I hadn't framed it that way. Open textarea is convenient for me to build but it works against consistency, and consistency is literally what has to be true for the tool to earn any credibility. Not something I'll change in caliente based on one read, but I'm parking it as a real question, probably some middle ground between "guided fields" (too rigid) and "blank box" (too loose) that still lets people paste a real message.
On price, you're touching a nerve. I've been quietly worried the $9 lifetime thing was answering the wrong question. Your framing is cleaner than mine: dropping price responds to an objection nobody's raised. The gap is trust, not cost. I don't have the trust track record yet, and no price will substitute for that. Going to sit with your "token-amount, feels closer to free" idea too, that's a different mechanism than a discount.
Traffic is still thin, so you're right to caveat. But the two things you flagged wouldn't be less true with more traffic, they'd just be more visible.
Genuine question back, since you clearly think about this in a way I need more of: when you say the trust track record has to come from usage, what does that look like in practice for a tool this early? Content? Public case studies? Just time? I have a hypothesis but I'd rather hear yours before I commit to one.
_____________________________________________________________
Good catch pulling the 'token amount, closer to free' apart from a discount, that distinction matters more than it looks like at first. And you're right that thin traffic doesn't make either point less true, just less visible for now.
On the real question: I don't think it's content, case studies, or time on their own. It's what those three are actually delivery mechanisms for, which is making the reasoning checkable instead of asking anyone to trust a verdict.
Nobody can verify today whether your tool's read on a brief is accurate, that takes outcomes over time you don't have yet. But anyone can verify right now whether the reasoning behind a specific read holds up: did it notice what a careful person would notice, did it miss something obvious, does the logic connecting the brief to the flag actually make sense. That's judgeable immediately, with zero track record required.
Which is really just your own 'gut-check, not verdict' framing taken to its logical end. If the tool shows its work instead of just a score, people aren't trusting you, they're checking your reasoning against their own judgment. Do that enough times where the reasoning holds up under scrutiny, and the track record becomes 'this reasons soundly,' not 'this was right,' which is the one claim you can actually start earning before you have outcomes to point to.
Content and case studies are just how you get that reasoning in front of more people. Time is just how long it takes to stack enough of them that the pattern is undeniable.
Curious what your own hypothesis was before I ran with mine, might be catching something I'm not.
SystemicThinker
The asymmetry you're describing is real. It's been there forever and nobody talks about it enough.
One thing I'd want to know before scaling though : the freelancers who told you they'd pay — did that happen in a conversation, or did any of them actually sign up for the waitlist on their own? Because those are two very different signals. People say yes when you're in the room. The waitlist tells you what they do when you're not.
The concept itself is clear. The harder part to validate isn't whether freelancers want this. It's whether they'll trust a brand new platform with a real client opportunity when it actually matters. That's the question the waitlist alone won't answer.
You're calling out something I've been avoiding naming. The freelancers who told me they'd pay did so in DM conversations after direct back-and-forth with me — none of them signed up cold on the waitlist on their own. Conversation "yes" and cold-conversion "yes" are two very different signals, and I only have the softer one so far.
The trust point is even harder and I don't have a clean answer. You're right that a brand-new platform asking a freelancer to reject a real contract based on our analysis is a much bigger ask than "try this free tool." That doesn't get solved with marketing — it gets solved with a track record I don't have yet. My working hypothesis is start with a low-stakes version (a free brief analyzer as a gut-check, not a verdict) and let trust build with usage before ever asking someone to make a real decision on it. That's more hope than plan right now, but it's the direction.
Since you're clearly thinking about this well — I already built that low-stakes piece as a free tool, no signup: https://vettly-brief-check.netlify.app. If you're up for it, telling me whether it feels trustworthy or off would be worth more than most feedback I get.
Went through the whole thing on your site, really appreciate you sharing it. Two things stood out, and both tie back to the trust-building approach you described earlier, not just a surface 'does it look legit' read.
The brief input feels too open right now. If people can type whatever they want in whatever shape they want, the output quality is going to swing hard between a three-line brief and a five-paragraph one, and that inconsistency works against the exact thing this tool is supposed to build: a track record of 'this reads people accurately.' Some light structure on the way in, a few guided fields instead of a blank box, would probably tighten that a lot.
On pricing: the waitlist offers $9 lifetime instead of $15, and if that's not converting yet, I don't think it's a price problem. The gap you named earlier is trust, not cost, so dropping the price may be answering an objection nobody's actually raising.
If you do want to use price there, I'd go lower than $9 for just the first 100, closer to a token amount. Not because the product's worth less, but because at that price it stops feeling like a purchase decision and starts feeling closer to free. That's really just your own free-tool logic carried one step further into the paid layer, and probably closer to how the trust you're after actually gets built.
Might be reading too much into a small sample if traffic's still thin, but if people have genuinely seen the page and still aren't signing up, I'd look at both of those before touching price again.
Appreciate you being this open about where things actually stand, not everyone would share that.
ST
This is exactly the kind of read I was hoping for — thanks for actually going through it.
On the input structure: you're right and I hadn't framed it that way. Open textarea is convenient for me to build but it works against consistency, and consistency is literally what has to be true for the tool to earn any credibility. Not something I'll change in caliente based on one read, but I'm parking it as a real question — probably some middle ground between "guided fields" (too rigid) and "blank box" (too loose) that still lets people paste a real message.
On price — you're touching a nerve. I've been quietly worried the $9 lifetime thing was answering the wrong question. Your framing is cleaner than mine: dropping price responds to an objection nobody's raised. The gap is trust, not cost. I don't have the trust track record yet, and no price will substitute for that. Going to sit with your "token-amount, feels closer to free" idea too — that's a different mechanism than a discount.
Traffic is still thin, so you're right to caveat. But the two things you flagged wouldn't be less true with more traffic — they'd just be more visible.
Genuine question back, since you clearly think about this in a way I need more of: when you say the trust track record has to come from usage, what does that look like in practice for a tool this early? Content? Public case studies? Just time? I have a hypothesis but I'd rather hear yours before I commit to one.
The "vet the client" framing is immediately clear. "Glassdoor for freelance clients" is one of those rare analogies that lands in two seconds and doesn't need explaining. Good sign.
The harder question is whether it's a business or a feature.
Two structural challenges worth pressure-testing:
The cold-start problem is brutal for this category. The product is only valuable when it has enough reports on enough clients to be useful. Freelancer searches a client name, gets zero results, leaves and doesn't come back. You need density before the product works, but you need the product working to get density. Every review marketplace hits this. Glassdoor solved it by scraping public company data first, then layering reviews on top. What's your equivalent? Without a solve for day-one empty results, the waitlist converts to signups that churn immediately.
Willingness to pay is the real test. Freelancers will say "I'd pay for this" in a conversation because it sounds obviously useful. But the check-a-client moment happens before a project starts, which is infrequent (maybe monthly for active freelancers), and the pain of bad clients is retrospective ("I got burned last time") not acute in the moment of deciding. That's a tough combination for subscription pricing. It might be a one-time-check model, or it might be a feature inside a broader freelance tool, not a standalone product.
The "AI read on their brief" piece is interesting but worth separating. Vetting a client (reputation data from other freelancers) and analyzing a brief (AI red-flag detection) are two different products. The first needs a network. The second works on day one with zero users. Worth considering whether the AI brief analysis is actually the MVP and the review network is the long-term vision.
Who are the freelancers telling you they'd pay? Platform freelancers (Upwork/Fiverr) or independent? Platform freelancers already have some client rating data. Independent freelancers have zero, which makes the pain sharper but the cold-start harder.
If you want to pressure-test which of these angles to lead with, that's what HiveMind is built for: https://hivemind.myosin.xyz
This is some of the most useful feedback I've gotten on this — thank you for taking the time.
The cold-start problem is the one I keep circling back to, and you named it perfectly: empty results on day one kill retention before the network exists. I don't have my "Glassdoor seeded public company data first" equivalent yet, and that's exactly the gap I need to solve before the review network means anything.
The split you and another commenter both pointed to is making me rethink the whole thing: AI brief analysis works on day one with zero users, while the review network needs density to matter. I'm starting to think the brief analyzer might be the actual MVP, and the review network the long-term vision layered on top.
On willingness to pay — you're right that it's the real test, and that the "check a client" moment is infrequent and the pain is retrospective. That's the hardest part of the pricing puzzle and I don't have it solved. Chewing on whether it's a per-check model vs. subscription.
Genuinely grateful for this. Mind if I follow up if I go deeper on the brief-analysis angle?
Of course, follow up anytime.
Since you're leaning toward the brief analyzer as the MVP, one thing worth getting ahead of: it solves the cold-start problem but it also changes who you're competing with. A standalone "AI reads your client's brief and flags red flags" is closer to a ChatGPT prompt than a defensible product. Any freelancer can paste a brief into Claude and ask "what are the red flags here." So the brief analyzer gets you to day-one usefulness, but you need a reason it's better than the free alternative everyone already has.
The defensible version: the brief analyzer gets sharper because of the review network, not instead of it. "This brief has the same vague-scope language that preceded 12 non-payment reports in our database" is something ChatGPT can't do. That ties the two pieces together — the analyzer is the day-one hook, the network is what makes the analysis progressively better and uncopyable. The brief analysis is the wedge, the pattern library behind it is the moat.
So the sequencing might be: launch the brief analyzer to get users and solve cold-start, but design it from day one to feed and draw from the review data, so every analysis makes the next one better. That way you're not building two separate products, you're building one product where the free-on-day-one piece compounds into the defensible piece.
On pricing — per-check probably beats subscription for exactly the reason you named. The pain is infrequent and retrospective. People won't hold a subscription for a monthly-at-most check. But they'll pay $5-10 in the moment when they're about to sign a sketchy $5K contract and want a gut-check. Price it as insurance, not a tool. "Spend $9 before you spend three weeks on a client who might ghost you" is easy math.
The willingness-to-pay test that actually means something: put a real price on the waitlist page and see who pre-commits, not who signs up free. Free waitlist signups tell you the idea sounds good. A pre-order or deposit tells you the pain is real.
This is the kind of push I needed. Two things landed hard:
"The analyzer is the wedge, the pattern library behind it is the moat" — that's exactly the framing I was reaching for and hadn't articulated. The version where every analysis both feeds and draws from the review data is the one that stops being a ChatGPT prompt. That's what I'm building toward.
And the willingness-to-pay test — "free waitlist tells you it sounds good, pre-order tells you the pain is real" — that's uncomfortable in the right way. I've been measuring the wrong thing. The next iteration of the landing needs a real price on it.
On per-check vs subscription: your logic on infrequent + retrospective pain is hard to argue with. Insurance framing especially — "$9 before you spend three weeks on a bad client" is math anyone gets. I'm going to sit with per-check as the primary model and stop defaulting to subscription just because SaaS.
The free tool version is already live if you want to see what the wedge looks like right now (brief-only, no data layer yet): https://vettly-brief-check.netlify.app
Genuine question back: on the per-check pricing — do you think you'd charge before or after showing the analysis? Show verdict then paywall the detailed flags, vs. pay-to-analyze upfront. Both have arguments and I don't have a clean read on which converts better.
Reading this, I found myself less interested in whether freelancers would pay for it and more interested in what they believe they're paying for.
Protection from bad clients.
Faster trust decisions.
Better client selection.
Leverage in negotiations.
Those can all sound similar while pointing to very different products.
The reason that stood out to me is that a lot of validation conversations can look positive before that distinction is actually resolved.
This reframe is sharp — "less whether they'd pay, more what they think they're paying for." That distinction hadn't fully landed for me until you wrote it.
You're right that protection from bad clients, faster trust decisions, better client selection, and negotiation leverage all sound similar but point to different products. And that validation conversations feel positive precisely because that ambiguity hasn't been forced to resolve yet.
That's probably the next thing I need to pressure-test: not "would you use this" but "which of these jobs are you actually hiring it for." Thank you — this gave me a clearer question to go ask.
Glad it was useful.
I think the interesting part now is deciding which of those "jobs" deserves to become the lens for future product decisions. Happy to explain what I mean over email if that's useful.
What's the best email to reach you on?
Appreciate the original reframe — it genuinely helped. Right now I'm keeping the validation process open in public so others can follow the reasoning too, so I'll stick to the thread. If you have a rough version of what you'd say about the "lens" question, happy to hear it here.