different species of crabvietnamese mud crabsoft-shell crab
3
12 Comments

Three people signed up for my SaaS... and none uploaded a document.

Over the last few weeks, I noticed an interesting pattern while building DocMetrics.

Three different people signed up. Two were from the same company. None uploaded a document.

It's tempting to conclude my onboarding is broken, but I realized I don't actually know why they stopped.

They may have been evaluating the product, got distracted, didn't have a document ready, or hit onboarding friction.

Instead of guessing, I'm treating this as a hypothesis and planning to talk to more users before changing the product.

For those of you building B2B SaaS:

Have you seen users sign up but never complete the first meaningful action?

What turned out to be the real reason?

on July 24, 2026
  1. 1

    peer-launched last week, live version of this exact problem, so caveat there. the interviews at n=3 are the right move but the question isn't "why didn't you upload." it's "what did you sign up hoping to see."

    if half say they thought docmetrics would show a benchmark against others' documents and got surprised by "upload YOURS," that's a positioning fix. if they had the exact intent and stalled, that's activation. different bugs.

    the 2-from-1-company also reads more procurement-eval than joint-use to me. worth checking their titles.

  2. 1

    Three signups are too few to justify rebuilding onboarding, but two people from the same company suggest there may be genuine internal interest. I’d contact them directly and ask what they expected to see before uploading, because the blocker may be trust or unclear value rather than interface friction.

  3. 1

    Uploading a document is not a small onboarding step—it is the moment users take the biggest trust and effort risk. Show them exactly what they will receive before asking for the file, provide a safe sample document they can test first, and then see whether the problem is friction or weak perceived value.

  4. 1

    This is a textbook activation problem, and your instinct to talk to users before changing anything is the right one. Most founders would've already redesigned the onboarding by now and still not know why it failed.

    One pattern I've seen repeatedly: the first meaningful action (in your case, uploading a document) fails not because of UX but because the user doesn't have the right input ready at that moment. They signed up on impulse or during research, and "upload a document" requires them to go find one. That's a context switch they won't come back from.

    Two things that tend to help: (1) a sample document already loaded so they can see what the product does before investing effort, and (2) a follow-up email 2–3 hours later with a one-click link back to the upload step — catches people who intended to come back but forgot.

  5. 1

    Strong points already here on intent and the trust barrier, so let me add the one nobody has raised: instrument the upload attempt itself, not just the success. At n=3 you are right to interview rather than optimise, but "uploaded a document" as your only event cannot tell "never tried" apart from "tried and it silently broke."

    Add events for upload-started, upload-failed with the reason (file too large, wrong type, timeout, CORS or signed-URL error), and upload-succeeded. For a document tool the failure path is easy to underestimate: a 15MB PDF hitting a limit with no visible error, or a slow upload with no progress bar so someone assumes it hung and closes the tab. That shows up in the funnel looking like a motivation problem when it is a bug.

    It also sharpens the interviews the others mentioned. If someone started and it failed, you ask about the file and the error message. If they never started, you are back to intent and trust. Same drop-off number, very different fixes.

  6. 1

    Machine Arena team here. Our equivalent of your upload is a spectator making a first prediction on a match, and the mistake that kept biting us in our own numbers was counting lookers as failed doers. Most people who arrive at a product this early never came to do the thing; treating all of them as onboarding casualties makes every funnel number look broken and points you at fixes for a problem you may not have.

    So beyond the interviews, which are right at n=3, one cheap structural move: label intent at the door. One harmless question at signup, roughly "do you have a document you want analyzed today, or just looking around", turns the next ten silent signups from anecdotes into labeled anecdotes. Lookers who then do nothing are behaving exactly as promised and tell you nothing about onboarding. An intender who stalls is a real signal, and that interview is worth ten cold ones because you already know what they came to do.

    It also compounds with the sample-document idea above, but for funnel reasons, not just trust ones: whoever still signs up after seeing the output on a sample is far more likely to be an intender, so the same drop-off number suddenly means something.

    And plus one on the two-from-one-company read: joint evaluation is its own cohort, and it usually resolves on the evaluators' timeline, not your onboarding's.

  7. 1

    the "two from one company" part might be signal, not just a footnote on the sample size. that reads like someone pulling a colleague in to eval together before either commits real data, a joint-decision pattern rather than a stuck-on-onboarding one. worth watching if that pairing shows up again in future signups

  8. 1

    Right call not to optimise off this yet, and worth being blunt about why: at three signups (two from one company, so really two accounts) there's no drop-off rate to read. Each of those is a case study, not a data point. Talk to them, like you said.

    The one structural thing I'd flag for a document tool specifically: making the first meaningful action "upload your document" is a trust chicken-and-egg. If the file is anything sensitive, people won't hand it over before they've seen the thing do something useful, and "sign up, now give us your real data" is a big ask on faith. That's why the sample-document path someone mentioned isn't just a diagnostic, it's probably the fix: let them see the output on your data before they risk theirs.

    When you do talk to them, the question that splits the causes cleanly is "did you actually have a document you were willing to upload right then" versus "you weren't sure what to do." Very different problems.

  9. 1

    Yes, I have seen this exact thing. The fastest diagnostic is to give them a sample document path on the first screen: “try it with our sample” next to “upload yours.” If people use the sample but not their own file, the issue is trust or readiness. If they ignore both, the issue is probably positioning before onboarding.

  10. 1

    I like that you're resisting the urge to optimize around a conclusion you haven't earned yet.

    What kind of evidence would actually convince you the problem is onboarding rather than something earlier in the decision to sign up?

    1. 1

      That's a great question.

      For me, it would take more than just seeing people drop off after signing up. I'd want evidence from conversations with users.

      If I consistently hear things like, "I wasn't sure what to do next," "I didn't understand what to upload," or "I expected to try it without uploading a document," I'd feel much more confident that it's an onboarding problem.

      On the other hand, if people tell me they were simply curious, didn't have a proposal ready, or were just evaluating tools, then the issue is probably earlier in the journey—or not really a product problem at all.

      At this stage, I'm trying to avoid optimizing based on assumptions and instead let user conversations point me to the real bottleneck.

      1. 1

        Appreciate the context.

        Would be good to continue the conversation as you learn more from those user conversations.

        What's the best email to reach you on?

Trending on Indie Hackers
I built an AI that turns an idea into a live business in under 10 minutes. Here’s what 1,000 launches taught me User Avatar 88 comments Building a startup costs $0. Your tooling budget costs $500K. Here's why. User Avatar 38 comments Building Noodle, a keyboard-first REST client for the terminal User Avatar 34 comments "Looks Good to Me" Is Quietly Killing Your Feedback Loop User Avatar 31 comments 787 tools for developers. 5 for nurses. Two weeks of tracking 14,000 indie launches. User Avatar 26 comments I didn't want to build another AI chatbot User Avatar 16 comments