Launching a B2B beta without a self-serve login. Are we crazy?
My team and I are launching our RFP library tool on Tuesday, but we are doing something entirely unscalable for our beta: we aren't handing our users a login.
We know that AI hallucinates badly on unstructured legacy proposals. So, rather than throwing an AI tool at unorganized files, we are stepping in as a temporary extension of the users' team. We do the heavy lifting of manually organizing their scattered past proposal data into an accurate, verifiable library. We want to ensure that the foundation is flawless before we automate any sort of self-serve onboarding.
Has anyone else launched a high-touch, concierge MVP like this? Did your early users value the hands-on setup, or did the lack of instant access cause too much friction?
I'd love your insights/feedback here.
Replies
I actually think this is a smart approach for a beta. If your product depends on clean, structured data, manually onboarding early customers gives you a much better understanding of where the real edge cases are before you automate everything.
Some of the best B2B products started with a concierge-style MVP. The goal isn't to scale the process—it's to validate that you're solving the right problem. Once you understand the workflow and have enough patterns, then you can build self-serve onboarding with much more confidence.
I'd rather see a high-touch experience that delivers great results than a fully automated onboarding flow that leaves users frustrated.
@milan_cheeks Exactly this, Milan. Our entire focus right now is proving this architecture works with actual, messy legacy data. This will give us the confidence to automate the workflows later. Better to map the edge cases manually now than leave users frustrated with a hallucinating system.
@manisha_giri1Â Exactly. That hands-on phase is also where you learn what the product actually needs to automate, instead of building around assumptions.
Once you have seen enough real edge cases, you can turn those patterns into clearer rules, stronger validation, and safer automation. It may feel unscalable now, but it is probably saving you from scaling the wrong workflow later.
@milan_cheeks Yes totally. Appreciate you showing support. This gives me that much-needed early confidence before launch day next week.
@manisha_giri1 Absolutely, and you’re approaching it the right way. That early confidence comes from seeing the real workflow work with real data, not just from having a polished demo.
Wishing you a strong launch next week. I’ll be looking out for it.
We're not manually handling user logins during beta, but we're manually matching our users while we calibrate our fit engine. That means more hands-on with our employer partners. There are a lot of learnings that we just would not have captured had we automated this step.
@jasminediaz This resonates so much. Doing the hands-on work manually is the only way to capture those crucial learnings that help build the foundation that actually scales later.
Yes, and I'd defend it on exactly the ground you gave. If the model is answering from a messy foundation, no amount of model quality saves it. That's a data problem wearing an AI costume, and doing the first ones by hand is the only way to find out what "good" even looks like before you try to automate it.
On the friction question, my experience is the opposite of what you'd expect. The missing login is not what costs you. Doing more for people is cheap, they like it. What costs you is asking them to do one small thing themselves. In my case the setup needs the customer to flip a single toggle in their store's theme editor. One step, thirty seconds, and that single step loses more activations than the entire manual setup we do for free on their behalf.
The risk I'd actually watch is different. Concierge teaches you the wrong lesson if you're not careful: you hand-build a foundation the automated version can't reproduce, then self-serve ships, quality drops, and you can't tell whether the product regressed or the data did.
What helps is writing down every judgement call you make while organising someone's proposals. Not the output, the decision. That list is your automation spec, and it's the only place you will ever get it from.
How are you planning to know when the manual version is good enough to automate? That's the part I always get wrong.
@jernej_jan_kocica "A data problem wearing an AI costume" is pretty accurate, Jernej. I also love your comment on friction— doing the heavy lifting for them is much cheaper than asking them to change the workflow.
The point about documenting the decisions rather than the output is something I agree with as well. This is exactly the automation spec we are focused on getting right.
To answer your question: we will know the manual version is ready to be automated when the judgement calls stop being unique. Once those decisions become predictable, repeatable patterns our founding engineer can script, and we can map a client's chaotic proposal data into a perfectly chunk-cited live bid where a sales team doesn't obsessively have to verify a single source - that is when we flip the switch. We automate the moment we can guarantee we've systematically killed the 11th-hour source hunt.
@manisha_giri1Â That's the right threshold, and a cleaner one than I usually manage: "the judgement calls stop being unique." The one trap I'd add is they can stop being unique per client but not across clients, so it feels automatable on the fifth customer and breaks on a sixth with a weirder data shape. Sounds like you already know that though. Good luck with the launch next week.
@jernej_jan_kocica I really appreciate all the feedback. Thank you.