Launch HN: Rownd (YC W22) – Add authentication and accounts to any website
For example, one of our customers is a film festival. The festival requires everyone who buys a movie ticket to make a user account. That's a big drag on conversion rates and requires technical upkeep. We take care of all that for the festival and make account creation and maintenance less painful for their users, which leads to more ticket sales. Further, the day of the festival, they can text “tickets” to xxxxx (our short code) and we send a specialized magic link so they can log in quickly and see their itinerary and tickets.
Rownd works across all your websites and apps, so (for example) if a user has subscribed to your newsletter, that data automatically gets contributed to their account for your app. No one needs to re-enter their email address!
Turning a website visitor into a user is hard. Turning a waitlist member or a newsletter subscriber into a user is even harder. There is a huge gap between marketing pages (landing pages, blogs, docs) and actual products (web apps and mobile apps). The culprit is the traditional sign-up/login page. Sign-in pages add friction and lose users in your product funnel.
Your marketing pages should transition seamlessly to your actual product, but most sign-up flows act as a giant wall: stop, enter information that the company often already has from previous interactions, verify email/phone, remember your password (hopefully it’s in the password manager!), and finally, if you’re lucky…you’re in.
We eliminate this gap, stitching together user accounts from your startup’s CRM, mailing lists, and database, making authentication work seamlessly across your websites and apps. If a user verifies their email or phone number anywhere (including in marketing emails), we authenticate them everywhere. Visitors and subscribers become account-holding users.
We give you a code snippet for websites (which you add to your footer), and an SDK for web apps, to add authentication. Our “hub” (i.e., our standard sign-in and account management widget, specially designed to look and feel trustworthy) is then visible on your pages, and the account data is available to the browser/app through a simple API. Additionally, if you already have information about that user in other sources, such as CRM/marketing tools (Hubspot, Mailchimp, Airtable, etc), we integrate it into the onboarding/authentication process. The account data is available to your website or app through our browser API, so there is no need to build a backend for user management.
In more detail: We create an anonymous account around any visitor to your website. When a user comes to a site that has the Rownd Hub, a unique ID is created. Any form that is attached will fire that data to our Hub as well. The registration process can take place over several days if a visitor returns periodically. The data is stored in browser memory until they either press the "verify my account" button or click a button or link that is tagged as a Rownd authentication button (a bit like how Discord lets users view a server, but only comment once authenticated). If you link us to relevant data in your CRM, Airtable, or database, we make “claimable accounts” that are initialized from these data sources. Users claim their accounts and sign in with our passwordless authentication (via email or phone number today, but eventually ...
112 comments
[ 4.0 ms ] story [ 258 ms ] threadAdditionally, we don't think you should have to have a React/Vue/Next.js/etc site just to add auth. We want this to be plug-and-play anywhere and work across all of your web properties (and eventually mobile too). That could make the marketing, docs, and support experiences better at so many websites with a level of integration that used to take weeks or months to build (if anyone even bothered).
Indeed, we support password-based authentication. Developers can also choose social login, passwordless, or web3 (instead, or in combination). In practice, ~60% of developers are enabling passwords for their applications.
Our technology is agnostic and also supports traditional frameworks (node/express and ruby/rails have SDKs, python/django is under development).
We also support auth across N subdomains and mobile (currently just react native).
Thanks for the feedback and kind words! Really looking forward to making authentication and account management easier for developers and end-users with you!
> We also support auth across N subdomains
I read this to mean you support a session on a.domain.com being valid for b.domain.com -- but you still don't support the same email address tied to different users at different subdomains, correct?
Clerk.dev focuses on creating a great login page using low-code tools to get there.
We want to kill the login page. We want first time users to be able to enjoy an app or website first and then, when they fall in love with the product, then you ask for validation/authentication.
We ask "what does it mean to be authenticated?". We go beyond authentication by creating accounts for end-users, giving them control over their data (GDPR, CCPA compliant) and allowing developers to use that account data to customize pages well beyond a single app. Authentication is more of a check box for us, what you do with the data is our product.
Overall, If you are using Clerk.dev, I'd feel confident that your apps are safe and your users are protected. They use the latest tech and have a great team.
That said, we're not just authn/authz software. We're helping companies improve their UX across every facet of their web and mobile presence. We focus on how account data spans various systems, not just isolated within one datastore. We also consider how user data flows through various UIs, is part of personalization, etc.
At the end of the day, we want to make the relationship companies build with their users more akin to how it works in real life. It's often a conversation, not just a transaction.
What other features are you interested in?
Edit: Also, if you're willing, can you shoot me an email robert (a - t) rownd.io? would love to chat about your thoughts on the product.
We fundamentally believe that the end-user should control their data, we turn it into a feature.
Thanks for the question!
And that checks a box to say they’ve authenticated with just that site? If the user has already verified their identity on a different partner then what’s actually happening for subsequent partners?
How is the data siloed across partners?
Could be neat to back into a shared payment identity like bolt if the user opts to share that info. ie they’re on a new site that recognizes their Rownd profile and they can autofill/share certain info.
I really like the idea of a single source for privacy/GDPR control across all the sites I use. I hope y’all get great adoption.
We currently require verification on each partner site to ensure that the person signing-in is actually the holder of the email/phone. In the future though, we plan to allow a user that's authenticated at one Rownd partner to click a single button on a second partner site to simply pass the existing verification and account info across. In that case, no email/sms is needed as long as its done in the same browser/device.
Thanks for the question and your support!
We also "verify" and authenticate, but that is where we diverge. We also help websites manage "profiles" and "accounts" and that data can be made available for customization and personalization. From what a user sees to how they interact with a site or app.
Finally, we give the user the ability to retroactively "revoke consent" to their data. When they turn it off, the site and app no longer have access to it.
Great idea. How would you want that connection to look like as a user? I'd image we could "link bolt to your profile" on bolt enabled carts...
The actual processing could be handled by y’all rather than passing raw cc info to each partner.
I realize that’s pretty far from your mvp but as a user I’d rather save all personal data with one data store which can enable access or usage to selectively to apps.
As a partner, I’d like also like to have one spot to save user data. And if you’re streamlining onboarding it makes sense for that to include payment info or payment ability.
My rownd profile also becomes an auditable source of all my infos access and usage :clap:
As of right now, the authentication spans apps/websites owned by the same customer. If a user goes from one Rownd customer to another, they will have to re-authenticate and enter their data.
We are visioning a world where end-user can go from Rownd customer to Rownd customer and we can just ask "do you want to continue as Harrison and share x, y, z" so they can experience customizations and personalizations faster on sites. But we just launched and are examining that use-case!
A simple example is analytics
It’s a huge and ambitious goal and I’m looking forward to using them in the future as we expand our stack.
We currently use Postmark for sending transactional email and by default, they rewrite all links to use their tracking servers. We didn't intend to have that enabled, so apologies for the oversight. I've just disabled that option, so links should resolve to their intended destination now. Links that go through multiple tracking redirects are a personal pet-peeve of mine as well!
Pesky email providers thinking everybody wants to track everything all of the time. Sheesh!
Feedback on the site: I read the site and still really don't understand what the product does (I immediately saw it as an Auth0 competitor). Your "In more detail" paragraph would be a good bit of text to include prominently on the site.
Good luck!
Is it possible to use for users without Javascript enabled?
Any plans for a Go API? The HTTP API seems clean enough that it's barely needed, but I guess standardization is good. :)
Your pricing page doesn't say if it's monthly or annually.
Right now the hub is javascript for websites, but we have a React and Node SDK and will be adding more over the coming weeks.
Can you chat a bit more about the Go API vs HTTP API thoughts? We are Go fans, just trying to find the right use-case to jump into it.
Our pricing is monthly, but always happy to chat about it.
I don't think any of my thoughts below are specific to Go. I now see that examples in all languages are simply HTTP requests.
I think having a predefined library with, at least, constants (like HTTP header names) and data structures would help having more standardized client code. Perhaps it could even just be a Protobuf definition (there's a hack to use field default values to define constants). Or similar schema language that can easily generate struct definitions/JSON codecs/clients in various languages.
Languages that use camel-case (like Java) often benefit from someone central defining the snake-case/camel-case translation to avoid inconsistencies in the code base. Actually, your examples use snake-case for Rownd-defined fields ("revoke_after,") and camel-case for client-defined fields ("additionalProp1.") Caveat emptor: I might be the only person on Earth who is irked by that. ;)
A layer on top of that would be a client that sets good defaults. For request building, it could populate headers and sanity-check input. For responses, it could convert HTTP responses to exceptions/errors suitable for the programming environment. For failures, it can help defining which error conditions should be retried and back-off settings.
A bonus feature would be to have a fake client (or server) I can use in my unit tests. Something that makes me feel reasonably sure my code will work when talking to your production. That's something I always find more reassuring if the supplier maintains, rather than me.
From a browser perspective, Javascript needs to be enabled.
We'll definitely release an SDK for Go! We're heads-down building SDKs for all sorts of technologies, and could actually use some engineers with a background doing that sort of thing. If that's you, I'd love to chat about it (mhamann@rownd.io)!
The pricing is monthly, but if you're interested in more of an annual thing, reach out and we can get you numbers with the annual discount applied. We're working on more self-serve options, which will eventually include the ability to subscribe annually right from the website.
For now, you can use our `is_initializing` flag to wait until the authenticated state is fully loaded before completing the render in the browser. I realize that's not an optimal solution for this use case. We'll get there!
> We create an anonymous account around any visitor to your website
Doesn't this single sentence sum it up? Anyone who would think about buying an auth service is going to understand the implications of this. I get that you want to pitch why anyone would care, ie the value prop:
> We make it easy for developers to sign up users through a code snippet that adds account creation and authentication to any website or web app—like Stripe for accounts.
But the auth space is filled with... mostly bs products. If you pitch the value prop first, at least in auth, people will roll their eyes won't they? And the Stripe analogy isn't that great. Your value prop is that you make it easy for your customer's end users. Stripe's core value prop to customers is they make it easy for you. Both are valid, but you are sort of conflating things with the analogy.
You are absolutely correct. Is it very easy to say the same thing 5 times. I really (sincerely) do appreciate the feedback. Seeing what is important and what resonates is really important and one of the best reasons for a Hacker News launch.
You really found the crux of our g2m a/b testing - appeal to the developer (this is really easy) or appeal to the product manager (this will get you more users, faster).
Hit me up sometime if you want to chat more (would love to pick your brain - robert (a-t) rownd (dot) io. ). Thank you!
1 - if you pitch it to devs for ease of use, there is obvious, direct and existing competition which has been around for years. It's hard to show you are easier to use. It's also going to be a harder pitch for them internally.
2 - there is literally hard $$ of revenue to be had from the pitch to PMs etc because it's actually a pitch to the CEO. More users. CEO is talking to investors/friends/husband/wife: "I just saved my devs 10 hrs upfront and 1 hr per week!" v "I just added X new customers".
Pure gold Daniel! Spot on. Makes absolute sense!
Thank you for the feedback.
Similar on the need for a phone call (what is this, a pizza?)--at least let me hide behind email. But then I'm probably not the target customer, so do as you will.
I totally understand the "set up a call" frustration. Since we just launched, we really want to talk to users or potential users and learn more about their use-cases. We manually onboarded our first customers (emailing snippets, etc) and learned so much about their needs and painpoints, we wanted to keep that going for a while as we grow.
Try this: https://rownd.io/hacker-news . We'll add a button to the main site!
We are in the transition from "do things that don't scale" to "scale and grow".
--Rob
I'm a huge fan of self-service as well. Picking up the phone to call someone is like...the last thing I want to do. So 1990s! :-D
We're hard at work making Rownd much more self-service. We'd love to hear more feedback once the process there is a bit smoother!
Edit: Even better, I updated the call to action at the top of the landing page. Thank you again for your feedback!
Thank you for your very focused and tactical feedback. Easy to change!
Agree, it is over-priced for simple use-cases. What would be an appropriate price for the hacker news audience? It is far easier for us to lower prices and raise them.
Let me know and I'll change it!
That goes for anyone else!
--Rob
I like this idea. As a user, I hate that companies force me to make an account in situations where I don't want to make an account. It sounds like companies that use your product will allow me to buy products from someone without having to create a damn account.
Accounts are negative value for most customers who don't regularly return. It's a source of friction: who hasn't forgotten the password for a site their rarely go to then decide it's not worth doing the password reset (even if you use a password manager, it might not stay updated for "junk" sites)?
Plus, junk sites are the ones that tend to get pwned, and leak information.
Buying something from an ecommerse website could be either or. You may want to save some specifics or preferences. Others may need you to create an account to come back, especially if there is critical data being stored. I agree that passwords are dangerous.
We used our own auth to create a "try it out" page on Webflow. We do need an email (but it does not have to be validated) so we can go to our backend and create an App key so you can try the snippet. If you come back, you also do not have to validate, but if you want to go into our app deeper, we have you validate because otherwise, you will not be able to get back after the tokens expire, you use a different browser, etc.
What is really exciting is a world where you can validate without an email or phone number. So you can come back without needing more data.
We want the internet to be kind of like Discord's auth, one where you can see what is going on in a server but there are some actions that require verification/authentication. Like you said, if you just want a sneak peak, no reason to verify your email or create a bad password. But if you want to leave a comment, you have to verify.
Don't most ecommerce websites allow you to checkout as a guest?
Rownd would essentially eliminate that mental question entirely. You provided an email or phone, therefore you're more than just a guest.
To emphasis: During check out, they still have you add your email and phone (for receipt, tracking, etc). It is transactional in nature, but the company still has it and likely saves the session with a cookie.
Rownd is trying to fix this: Why not treat everyone like a guest the first time and if they want, when they come back, they can verify phone/email (or wallet in the future) and then the rest is filled in.
99% of the time I "continue as a guest" because it is easier than going through the hassle of email (verify), password (remember or pw manager), and the 9 other questions they ask before you can actually check out.
The truth is, if your email is compromised right now, most sites will be compromised since "lost password" fall backs are sent over email. 2FA is the way to go into the future.
The heart of this issue is around how to authenticate users quickly and securely.
Sounds good but why don't you apply the same principle on your own website?
What we (now with hindsight incorrectly) wanted to show was that you can enter you email and then NOT have to verify it and interact with the actual code snippet you can put into your app or website. Since we are in webflow and if you used a live snippet with a live App key, we assumed users would want to come back if they wanted access to it again. So, we figured most (and we have had a few hundred) would enter their email and then see a fully working snippet, with an API key, ready to roll in webflow and think that was neat.
Now, having a few hundred people on the site, I do think letting users see the snippet and then "request" an APP key with their email is the right answer. We could not have come to this conclusion without this launch.
Appreciate it! - Rob from Rownd
In the bigger scheme of things, I envision a world where adding auth to your app (or any functionality) is as simple as adding a docker service.
We (at Rownd) are looking into self-hosted, open-source options as well. What are a few features that are MUST haves?
There are some that are more complex (like SMS auth, email auth, etc). We want to 100% get away from passwords, so passwordless is critical since most passwords are security issues.
Every component that gets added to your infrastructure is just "another thing" that you have to worry about in terms of uptime, monitoring, security, staying current, and so on. Personally, I'd rather not worry about any of that for something that isn't part of my core competency. Certainly there is a cost/benefit analysis to be made, mostly for larger companies.
I know we won't likely agree on this point, and that's ok! I just wanted to share an alternative perspective. :-)
Another reason: my app has no reason to send emails except for one thing: password resets. I don't want to set up a whole email flow just for that. By using a provider I can offload that at the same time.
Yeah, for the same reason I don't want to store credit card details, I don't want to store user credentials.
Only downside is the pretty ugly default login UI of cognito, but you can style it to some extend by adding a logo and custom css.
That is a great question. We are new and want to find those folks that are willing to pay 2-10 times more than the competitors. Most all of our competitors are free for 2-12 months hoping to lock you in. It is very counter-intuitive, but our first 20 paying customers have such a real pain point that are not being met, then even knowing that there are cheaper alternatives, they turn to us.
We do offer 50% off of that rate for hacker news ($49 a month). We will decrease our price over time as we really understand more about our customers, their problems, and make onboarding super simple.
Having said all of that, reach out at robert (a-t..) rownd.io and if you are willing to give us feedback I'll find a price to make it work.
'Up to 1 website', is an odd way of saying it. You can't really have less, can you? Also in Pro you've spelt 'Unlimited' incorrectly.
Any plans to add social auth, or just magic link going forward?
Watched the video, hopefully you'll experience the network effect going forward. Best of luck with the product.
Will update right now.
We will likely add Google Authentication since it is a faster way to validate your email (and 65% of internet users have gmail). Facebook auth is on its way out (down from 6M a few years ago to 3M in 2022).
Also, looking towards logging in with crypto wallets in the near future.
I tried watching but didn't go past 90 seconds. Too verbose, TBH...
[1] https://www.youtube.com/watch?v=H7fv17HSYrc
As someone who prefers reading text over watching videos, I can commiserate with you ;-)
We've just been making some updates to our home page to hopefully make it clearer, but we realize we still have plenty of work to do.
If you sign in at the Rownd website, you can experience how the product will work on your own website.
We'll definitely get a shorter demo video posted soon that helps explain this too.
Two big changes: Most players in this space treat authentication as a point in time decision and it is usually static. IE, you are about to enter an webapp, we will now authenticate you. We think authentication should be a gradient. You can be unauthenticated, authenticated but unverified, and you can be fully authenticated. The ideal user experience is that users should be able to try an app or experience prior to having to "login".
Second, we also hold account/profile data for users and make it available to apps and websites to personalize and customize their experience. This is critical as we move into "hyper customization" in the near future. We allow sites to slowly gather data through trust. At the same time, we give the end-user control over this data (they can turn it off, edit it, just like they would a profile).