We Finally Shipped Self-Service Signup. Here’s What It Actually Took.

For the first three years of Viewabo, if you wanted to try our product, you had to contact us. This is especially relevant when thinking about self-service signup SaaS.

Also, that’s a contact form. A reply. A demo call, maybe. And then, if everything went well, we’d manually create your account and send you credentials.

Furthermore, we knew this was a bottleneck. We built it that way intentionally, early on, because we were a small team validating product-market fit and didn’t want to support random signups who weren’t our target customer. The sales-led model made sense for a while.

Then it didn’t.

Moreover, this is the story of what it actually took to add self-service signup to a B2B SaaS product that started life as a “contact us” tool, the engineering decisions, the mistakes, the things we’d do differently, and what the early data showed.

Why We Delayed So Long: Understanding self-service signup SaaS

In addition, i want to be honest about this: the delay wasn’t purely strategic. Some of it was just the usual founder trap of believing a thing is “next sprint” for many sprints in a row.

But there were legitimate reasons we held off:

1. Trial fraud and abuse risk. B2B SaaS products are constant targets for automated signups, fake email addresses, and people trying to scrape your customer lists. With a manual process, we had a human filter. Going self-service meant building that filter into the product itself.

2. Billing complexity. Integrating Stripe subscriptions into a Rails app sounds simple until you’re dealing with trial periods, failed webhooks, customer objects vs. subscription objects, proration, and the fact that Stripe’s test mode and production mode behave differently in subtle ways.

3. Onboarding UX work. When a human was activating accounts, we could email new users personally and walk them through setup. With self-service, you lose that. The product has to do that work, which means the product has to be good enough to do that work.

Each of those is solvable. None of them is a reason to stay sales-led forever. But they’re not nothing, either.

What We Actually Built

The core changes were:

Stripe integration for trial management. New users sign up, and Stripe creates a trial subscription. No credit card required at signup, we’re running an opt-in trial, not opt-out. (More on this decision below.) When the trial expires, Stripe handles the billing flow. Rails listens to webhooks.

Account provisioning on signup. When a user completes the signup form, the app creates their account, sets their trial end date, and fires a welcome email. This sounds obvious but requires careful handling: what happens if the webhook fires before the user record exists? What happens if the user refreshes during account creation? Edge cases are where self-service breaks.

Feature flagging. We shipped the code behind a feature flag (SETTINGS__SELF_SIGNUP_ENABLED) so we could enable it in production without a deploy. This let us test in production with real data before flipping the switch for everyone. I’d do this again on any significant self-service launch.

The sessions filter fix. Here’s an example of the kind of edge case self-service exposes: our sessions page had a “Requested” filter tab that only made sense for legacy sales-led accounts (accounts where customers requested sessions, rather than agents starting them). Self-service accounts don’t work that way. When a self-service user’s browser had a stale bookmark to ?filter=requested, they’d land on an empty page with no explanation. We had to add a fallback that detects the account type and shows the right default view. Small thing, big impact on first impressions.

The Credit Card Question

We debated this more than anything else.

However, opt-out trials (credit card required at signup) convert at roughly 48% from trial to paid, according to 2026 benchmark data from Artisan Strategies across 1,200+ SaaS companies. Opt-in trials (no credit card) convert at around 18%.

Specifically, that’s a significant difference. The case for requiring a card is real: you get fewer signups, but the signups you get are more qualified and more likely to convert.

Consequently, we decided not to require a card. Here’s why:

Therefore, viewabo is a “see it to believe it” product. Our core value proposition, that a customer can click a link from their phone and instantly share their camera with a support agent, no download required, is not something you can explain in a pricing page blurb. You have to use it. You have to send that first link, have a real person click it, and see it work.

That experience requires friction-free signup. If we put a credit card gate in front of it, we’d filter out the exact people who most need to experience the product before they trust it enough to pay.

Our calculation: higher signup volume + lower trial conversion rate = more paid customers than lower signup volume + higher trial conversion rate, for our specific product and price point. That math might be wrong. We’ll know in 60 days.

What We Got Wrong

We shipped the code but not the marketing site. This one is embarrassing. Self-service signup went live in the Rails app, but our marketing site still had “Contact Us” buttons everywhere. For days, people who might have clicked “Sign Up” hit a contact form instead. Organic conversion from our homepage was effectively zero during that period.

The lesson: your code shipping is not the same as your product launching. The marketing site, the onboarding emails, the help docs, these have to ship in sync with the feature, not after.

We underestimated the empty state problem. New users who sign up and land on a dashboard with nothing in it don’t know what to do. We had a “Create Session” button in the right place, but the blank state gave no context for why they should click it, what would happen next, or what a session even looks like. Activation rates for the first week were lower than they should have been because the first-time experience wasn’t clear enough.

We’ve since added more explicit “here’s your first step” copy to the empty dashboard state and added a setup guide link. It helped.

Webhook handling was more fragile than expected. In testing, everything worked. In production, we had a few edge cases where the Stripe webhook for checkout.session.completed arrived before the Rails job that creates the user record had finished. The webhook tried to attach a subscription to a user that didn’t exist yet. We added retry logic and idempotency checks. These are boring engineering problems that every SaaS eventually solves, but “solve them before launch, not after” is better advice than “fix them when your first few users have broken accounts.”

Early Data

It’s early, and I’m sharing this with the caveat that a few weeks of data isn’t a trend.

What I expected: a trickle of signups, mostly from organic search or direct traffic.

What happened: signups clustered in the first 48 hours after launch and then dropped to a slower but steady rate. This is consistent with what I’ve seen described as the “launch bump”, the initial traffic spike from people who’ve been waiting or who hear about it through founder channels.

The thing I’m watching most closely: activation rate. Of the people who sign up, how many complete their first session within 72 hours? That’s the number that predicts paid conversion. For Viewabo, “completing a session” means sending a session link to a real customer and having them click it. It’s a meaningful activation event, not just clicking around the dashboard.

I’m not going to publish that number yet because the sample size is too small to be meaningful. Ask me in 60 days.

What I’d Tell a Founder Doing This for the First Time

1. Ship the feature flag first. Deploy the code behind a flag weeks before launch. Let it exist in production. Test it. Fix the weird edge cases that only appear in production environments.

2. The marketing site is part of the launch. Not an afterthought. Update your CTAs before you flip the switch.

3. Your empty state is your first conversation with every new user. If the empty dashboard doesn’t tell people exactly what to do next, with specificity, not vague promises, you’re losing activation before you’ve started.

4. Decide the credit card question early and commit to the reasoning. The right answer depends on your product, your CAC, and your activation dynamics. There’s no universal right answer. But you need a thesis, not just a default.

5. Opt-in trials work best when the product’s value is fast and visceral. If your product takes 30 days to show value, maybe a card gate is worth it. If your product shows value in 5 minutes (like ours does), opt-in gets more people to that value faster.

What’s Next

We have a list of things to improve in the next 30 days:

• Better first-session prompt in the onboarding UI
• Lifecycle emails via Loops: welcome, Day 1 nudge, Day 3 tips, Day 7 midpoint, Day 13 urgency, Day 14 expiry
• The marketing site CTAs, this week
• PostHog funnel tracking so I can see where people drop off

Self-service signup isn’t a launch, it’s a starting line. Every week for the next quarter, the work is making the funnel work better.

I’ll write a follow-up in 30 days with real numbers.

George Cheng is the founder of Viewabo, a remote video support tool for field service and hardware support teams. Viewabo lets support agents see exactly what their customers see, without asking customers to download anything.

Publishing Instructions

1. Log in to WordPress (blog.viewabo.com)
2. New Post → paste the content under “Full Blog Post Draft” above (start from the H1 line)
3. Set status: Draft (NOT publish)
4. Set focus keyword in Yoast: self-service signup SaaS
5. Paste the SEO Title and Meta Description into Yoast fields
6. Set permalink to: /self-service-signup-b2b-saas
7. Add a featured image (screenshot of the signup flow, or a simple text graphic)
8. Review the numbers in “Early Data” section, adjust if you have more precise data

When to publish: Any time this week. No time-sensitivity. Post to LinkedIn when it goes live.

For additional context, see recent analysis from OpenView research on trends in this space.