Validation check: Flagging rawChatGPT/Claude inputs atsignup to force better clones?
Hey hackers,
I’m building Postessia, a platform designed to deeply clone a user's personal writing style.
But I’m running into a bizarre, modern "garbage in, garbage out" problem.
During onboarding, users frequently paste a raw, unedited text sample straight out of ChatGPT or Claude and say, "This is my writing style.
"The issue?
If you train a style-cloning engine on a generic LLM sample, the outputs just sound like a second-generation copy of generic AI fluff. It kills the product value.
To fix this, I’m planning to add an AI Structural Baseline Check right inside the sample paste box.Before the app processes the sample, the backend will scan for:Low Burstiness: Sentences with a static, machine-like 15-word rhythm.Low Perplexity: Hyper-predictable, mathematically uniform word choices.
AI Framework Flags: The "throat-clearing" intros ("In today's digital age...") and the standard AI buzzword toolkit (tapestry, delve, crucial, testament).
If it triggers the flags, a subtle UI alert will pop up:“We detected standard GPT/Claude structures here.
Postessia is going to actively override this baseline to inject human sentence variance and token diversity into your variations.”Instead of letting them get mediocre results, I want to show them that Postessia actually understands what a real human footprint looks like.
We haven't coded this yet, so I want to ask you:
If an onboarding flow flagged your pasted text as "AI-structured," would you find it highly valuable, or would you feel called out/annoyed?
Does this feature make the cloning tool feel more premium, or is it an unnecessary friction point at signup?
Would love to get your raw feedback before I start building this out over the weekend!
Reframing it as an Optimization Matrix instead of a detection alert solves the UX problem cleanly. Human writing that reads like AI output becomes a normalization case instead of a false positive, which is the right architectural choice. One thing worth testing early is how precise vs loose the structural scoring is. Tight professional writing and generic AI output overlap more than a first pass accounts for. If the thresholds are too tight you lose legitimate users, too loose and the feature becomes noise. Are you planning to test with actual human-written samples across different styles before shipping?
The real validation question here: is the pain frequent enough that people will change their workflow for it? Gut check — would YOU pay for this if you hadn't built it? If you hesitate, run a smoke test before building more: describe the outcome on a one-page landing, drive a bit of traffic, count emails. Cheaper than shipping the wrong feature.
The optimization breakdown after generation is the cleanest middle ground. It shows the engineering without making users feel defensive. One timing detail: surfacing it front and center for the first few outputs turns it into an onboarding hook. Users see why the result sounds better and trust the tool faster. One thought: what happens when someone submits genuinely good human writing that triggers the same structure flags?
You’ve given me a massive breakthrough here, MoAutomates! Surfacing it front and center specifically for the first few outputs as an onboarding hook is genius. It completely flips the script—instead of an invasive "check," it acts as an immediate diagnostic showcase of what the engine is actually analyzing under the hood.To your point about genuinely good human writing triggering false flags: that is the exact engineering challenge we are balancing right now. If a human writes with tight, mathematical precision, a standard classifier gets confused. By framing it as an "Optimization Matrix" rather than a "Detections Alert," we ensure that even flawless human copy is treated as a baseline for formatting style, not a violation.This changes how I’m going to map out the onboarding logic this weekend. Huge thanks for anchoring this down with such practical UX timing!
The detection is smart but I would keep it behind the scenes instead of showing the alert. Let the model silently deweight the AI-sounding inputs and use the training to produce better output. If the user sees a flag and then gets better results anyway, they will trust the tool more. If they see a flag and feel accused, they leave. The UX win is making them think "this tool writes better than I do" not "this tool caught me cheating."
"That is an incredible piece of UX psychology, thank you!
You're completely right about the risk of making the user feel accused or 'caught cheating'—especially when many people use AI to clean up their rough thoughts and genuinely view that as their baseline draft.
The approach of silently de-weighting the AI signals and using our internal framework to fix the burstiness and token diversity under the hood is a massive UX win.
It shifts the user reaction from 'This tool is criticizing me' to 'Wow, this tool somehow knows exactly how to make my thoughts sound incredibly punchy.'
That said, if we go the 'behind-the-scenes' route, do you think we lose the opportunity to showcase Postessia's core engineering value during onboarding?
Maybe a middle ground could work: instead of an error-style flag, a small 'Optimization Breakdown' appears after the generation, showing them exactly how the engine injected sentence variance and removed robotic predictability to level up their draft.
Really appreciate you breaking down the psychology behind this!"