[HN Gopher] Launch HN: Rownd (YC W22) - Add authentication and a...
___________________________________________________________________
Launch HN: Rownd (YC W22) - Add authentication and accounts to any
website
Hi HN! We're Matt, Rachel, and Rob, the founders of Rownd
(https://rownd.io/). 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.
We made a page for you to try it out: https://rownd.io/hacker-news,
and a video to walk you through the flow:
https://www.youtube.com/watch?v=H7fv17HSYrc. 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 perhaps crypto wallets too!). You can
also use our "instant account links" in your own email and SMS
campaigns to re-engage with users and bring them back to your app
or website, fully authenticated when they arrive. We are a team of
former IBMers that have worked together for years tackling
authentication, API management, and data protection. The
predecessor to Rownd was a company helping startups comply with
data privacy laws. We started to notice some pain around sign-up
and onboarding for our own product and were frustrated that our
funnel had so many holes in it. Then we realized that other
companies were facing similar problems converting their site
visitors to users. So, one day during a team discussion, we said
"okay, let's solve that problem!" Since we'd already built a
backend for secure data storage, the account layer was essentially
there. We've therefore focused on building the layer that
streamlines user authentication, connecting data directly to the
user's browser session as well as the custom backends that most
products have. In the future, we aim to allow even more seamless,
opt-in authentication across different websites as our network
grows. We've got a ton of new features in mind from mobile app
support to a broader array of SDKs to enabling "sign in with
crypto." We're excited to make this crucial part of the internet
easier, more scalable, and more distributed than ever before. If
you're a developer, please let us know what you think! We'd love to
hear your questions, feedback, ideas, and experiences around this
space. You can also try Rownd for free at https://rownd.io/hacker-
news. We look forward to hearing how we might help developers
accelerate building products, and companies speed up growing their
user base.
Author : mhamann
Score : 61 points
Date : 2022-03-09 15:18 UTC (7 hours ago)
| runako wrote:
| Congratulations on your launch!
|
| 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!
| mhamann wrote:
| Thanks for the feedback! Sorry that things weren't clear! We'll
| work on that...
| orliesaurus wrote:
| Wait, it's not an auth0 competitor? Ok I am lost.
| rgthelen wrote:
| Rob here from Rownd. I consider us an Auth0 competitor. They
| focus 100% on authenticating prior to entering an app. We can
| carry authentication across websites and apps and want to
| "kill the login screen" by allowing users to try out apps and
| content without "signing up".
| runako wrote:
| "kill the login screen" is an interesting message, and IMHO
| warrants a much more prominent placement on the site. Walk
| a visitor through what that means, since it's a pretty
| radical departure from what everyone is used to doing.
| Remember the Salesforce No Software logo? Perhaps you could
| do something similar.
| rachelradulo wrote:
| Great point, we'll work on getting that into a more
| prominent spot and explaining it better. thanks!
| rgthelen wrote:
| Really like this! Thank you!
| mhamann wrote:
| I love that thought!
| chrisfrantz wrote:
| Love what the folks at Rownd are building. They have a data
| privacy background with a goal to kill the login page.
|
| It's a huge and ambitious goal and I'm looking forward to using
| them in the future as we expand our stack.
| mhamann wrote:
| Thanks for the support, Chris!
| rachelradulo wrote:
| Thanks, Chris!
| rgthelen wrote:
| Appreciate it Chris!
| mywittyname wrote:
| > We create an anonymous account around any visitor to your
| website.
|
| 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.
| rgthelen wrote:
| > 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)?
|
| 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.
| rgthelen wrote:
| That is our goal. There are a few different use-cases where no
| account is great and a few where you may want to create an
| account.
|
| 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.
| XCSme wrote:
| > Accounts are negative value for most customers who don't
| regularly return
|
| Don't most ecommerce websites allow you to checkout as a guest?
| mhamann wrote:
| I think they often do, yes. But I feel like there's often a
| decision point there for the user. The thought "if I don't
| create an account, but need to come back later for something
| (status, returns, questions), can I still get what I need?"
|
| Rownd would essentially eliminate that mental question
| entirely. You provided an email or phone, therefore you're
| more than just a guest.
| rgthelen wrote:
| Matt makes a great point.
|
| 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.
| jph wrote:
| Great idea. I'm your target customer. My feedback: you've got a
| stellar opportunity for your home page, to add a big "Try It Now"
| button. And you already have the functionality in your "Log In"
| link-- just make it much more obvious.
| rgthelen wrote:
| Thanks! That is an awesome idea. Always looking for more ways
| to show off our tech! Appreciate it!
| rachelradulo wrote:
| Totally agreed on this!
| mhamann wrote:
| Great feedback! We'll definitely work on improving that.
| bobbyradford wrote:
| Hey, that's great feedback @jph! We do want to highlight the
| usefulness in an obvious way.
| [deleted]
| rgthelen wrote:
| Done! Try it now is up and running!
|
| 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.
| jph wrote:
| Sign up goes well. But your email confirmation link seems to be
| broken or on a reject list: when I click the link, then it fails
| from domain "pstmrk.it" and doesn't seem to reach rownd.io. IMHO
| email confirmation links should go directly to the expected
| domain and company, not anywhere else.
| mhamann wrote:
| Sorry it didn't work for you! Do you happen to be using a
| service like Pihole, etc to block specific domains on your
| network?
|
| 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!
| codegeek wrote:
| Don't beat yourself for this mistake. We had a similar
| problem with emails where the provider was adding tracking
| URL by default. We had no idea until a client complained that
| it was blocked by their firewall/network. We then had to turn
| that off option which is enabled by default. Sneaky.
| rgthelen wrote:
| Really appreciate this! Thank you!
| mhamann wrote:
| xD
|
| Pesky email providers thinking everybody wants to track
| everything all of the time. Sheesh!
| jph wrote:
| Thanks for checking... I use Fastmail and Firefox with EFF
| Privacy Badger and uBlock Origin. If you want to send a new
| email, I can try it for you. Email is
| joel@joelparkerhenderson.com.
| mhamann wrote:
| Sent! Thanks for helping out!
| jph wrote:
| Success! Thanks for the fix.
| rgthelen wrote:
| Thank you for taking the time!
| tommiegannert wrote:
| Nice one. I love the SOLID project, separating apps from storage,
| and moving the users in charge of their data. This fits really
| well in that space.
|
| 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.
| rgthelen wrote:
| We love the SOLID project as well. We use similar principles
| and beliefs, would love to adopt their network as it grows as
| well.
|
| 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.
| tommiegannert wrote:
| > Can you chat a bit more about the Go API vs HTTP API
| thoughts?
|
| 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.
| mhamann wrote:
| We're fans of SOLID too! I think there's a ton of interesting
| work to be done in that space to make it scalable, secure, and
| really user friendly. We've definitely had some discussions
| around how Rownd and SOLID might fit together, so stay tuned.
|
| 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.
| rgthelen wrote:
| Hey HN! I am a co-founder at Rownd. Let us know what you think!
| We started down this path about 8 weeks ago and are very excited
| about the possibilities of what authentication SHOULD be not just
| what it is.
| vincentmarle wrote:
| > Sign-in pages add friction and lose users in your product
| funnel.
|
| Sounds good but why don't you apply the same principle on your
| own website?
| rgthelen wrote:
| Great point.
|
| 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
| abuehrle wrote:
| FYI your API docs page (https://docs.rownd.io/apiandsdks/#/rest)
| linked from the footer is throwing 500s.
| mhamann wrote:
| Thanks for the heads up! We've fixed the link!
| abuehrle wrote:
| Nice launch. How does this compare to clerk.dev?
| mhamann wrote:
| We envision a future without passwords and where you can take
| your identity around with you and plug it in wherever you want,
| while also maintaining control of that personal info.
| Interestingly, the first thing clerk.dev asks for when you sign
| up is a password...
|
| Additionally, 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).
| rgthelen wrote:
| I honestly think we are tackling two different problems -
| Clerk.dev protects an app or website. We create accounts that
| span apps and websites - and we happen protect them.
|
| 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.
| colinclerk wrote:
| Hello - I'm the cofounder of Clerk.dev. Congrats on your
| launch!
|
| 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).
| rgthelen wrote:
| Hey Colin!
|
| Thanks for the feedback and kind words! Really looking
| forward to making authentication and account management
| easier for developers and end-users with you!
| abuehrle wrote:
| Hey Colin
|
| > 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?
| yodon wrote:
| How does GDPR, etc. factor into this?
| rgthelen wrote:
| It is the very foundation of what we are building. We started
| as a data privacy company. When you authenticate with Rownd,
| the Rownd hub (on every website screen that uses Rownd), shows
| all of the personal data that has been collected by that
| app/site and you can turn it off with a button click. You can
| also go to mydata.rownd.io and self opt out of ANY data on any
| app that Rownd partners with.
|
| We fundamentally believe that the end-user should control their
| data, we turn it into a feature.
|
| Thanks for the question!
| harrisonjackson wrote:
| So the user/visitor (browser?) has a single identity within
| Rownd and the data is aggregated across any Rownd partners...
| and then the user can request a magic link to finalize the
| verification step per partner site? Domain?
|
| 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.
| rgthelen wrote:
| >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?
|
| 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!
| rgthelen wrote:
| >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.
|
| 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...
| mhamann wrote:
| Yes, once you've added information to one Rownd partner, it
| _can_ become available to a second partner, but _only_ if
| the user consents to sharing it and only when the
| fields/data types match between the two apps. Typically,
| that occurs during the sign-in process.
|
| 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!
| siphor wrote:
| Is this essentially a "Sign in with Rownd"? Similar to
| how "Sign in with Google" works? albeit with some
| anonymous user-tracking helpers at the front.
| rgthelen wrote:
| Google is kind of like "email verification" brought
| forward since they own 65% of the email market and even
| more of the browser market.
|
| 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.
| bobbyradford wrote:
| Hey folk, I'm an engineer here at Rownd and super excited to hear
| all of your feedback. I hope you get as excited about
| frictionless auth anywhere and everywhere as we are!
| [deleted]
| [deleted]
| adamqureshi wrote:
| ok i am a 1 man shop and outsource Auth to Auth0 but i am paying
| $25/month to them without offending you how can i justify paying
| $99/month for this ( I am building another app ) and doing it in
| webflow as MVP and want todo Auth with a stupid simple JS
| integration to at least test the MVP. But i like your dead ass
| simplicity.
| westoque wrote:
| I am mostly a one man shop myself but I would encourage
| everybody to self host their authentication. With so many open
| source libraries, there's no good reason why you should use an
| external provider. In most cases, if the app is relatively
| successful you will very likely add functionality to your app,
| and this means you need control of your data and everything
| else that comes with it.
|
| 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.
| Kiro wrote:
| That's exactly what I don't want. I don't trust the security
| of my app to store user credentials.
|
| 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.
| davewasthere wrote:
| Firebase, Cognito, Azure B2C?
|
| Yeah, for the same reason I don't want to store credit card
| details, I don't want to store user credentials.
| rgthelen wrote:
| This is a great point.
|
| 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.
| mhamann wrote:
| Thanks for bringing up this point! I think there are
| definitely times where self-hosting authentication might make
| sense, but I'll respectfully disagree that most people should
| do this.
|
| 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. :-)
| rgthelen wrote:
| Hey Adam!
|
| 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.
| getcrunk wrote:
| Shocked no one complained about the fact that you have to give
| them your email or phone number to get any more information from
| the hn specific landing page. Pathetic for a company that claims
| to "transition seamlessly" from marketing to product. I'm already
| never going to use it.
| rgthelen wrote:
| Sorry about that experience. You can also check out
| https://rownd.io for more info. We wanted to show off a new
| feature called "unverified", but if you are having this
| reaction, others probably are as well.
|
| Thank you for the feedback.
| mNovak wrote:
| It is an odd decision for a site emphasizing the ease of
| onboarding visitors. Also unclear to me also what that
| particular snippet does? The marketing seems to imply you can
| skip some or all of the classic new account/login page via
| 'magic', so why isn't that being demonstrated here?
|
| 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.
| rgthelen wrote:
| Thanks for the feedback here.
|
| 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.
| rachelradulo wrote:
| Hey, great feedback. The ease of onboarding comes from
| simply clicking a link in your email (or from a text
| message) to become a user of a product--striping away the
| need for passwords and loaded forms that typically hinder
| entry to a new experience. Sorry the use of the snippet on
| the page wasn't clear, we'll work on highlighting that
| better. The snippet is being demonstrated on the page via
| the hub in the left corner and is connected to the "submit"
| button to capture email and authenticate users. By putting
| the snippet on your site, you can skip building a full on
| sign in/sign up flow and authenticate your users with our
| hub. Hope this helps! We're grateful for your feedback!
| danielmarkbruce wrote:
| This looks cool. Please get a great product marketing manager. It
| took me 5-6 mins to understand what it is. I'm not a PMM, but for
| example this could have made things much clearer from the get go:
|
| > 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.
| rgthelen wrote:
| Thank you for this!
|
| 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!
| danielmarkbruce wrote:
| Two things in the dev v pm pitch:
|
| 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".
| rgthelen wrote:
| > "I just added X new customers".
|
| Pure gold Daniel! Spot on. Makes absolute sense!
| moonlighter wrote:
| Congrats, looks very promising. I find the pricing page confusing
| though. First, the "Startup" option is $99. $99 for what? A
| month? A year? The unit of time is missing. Second, the "Set up a
| call" button is a turn-off. I don't want to call anyone. I want
| to simply sign up for the service to try it out, as frictionless
| as possible. Having to CALL someone in 2022 is exactly the
| opposite of that.
| rgthelen wrote:
| Hey! I fixed the pricing (added the per month) and added a
| button to the landing page to "Try it now".
|
| Thank you for your very focused and tactical feedback. Easy to
| change!
| rgthelen wrote:
| Thank you for your feedback and sorry about that.
|
| 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
| mhamann wrote:
| Apologies for the confusion. The pricing is monthly, but we're
| lowering it to $49/mo for anyone coming from Hacker News.
|
| 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!
| moonlighter wrote:
| Well, it seems to me that you're missing out on a potential
| huge number of signups RIGHT NOW because of this friction.
| You're in the spotlight, with thousands of guys looking at
| your offering right now.... and you want them to CALL you?
| Seriously?
| rgthelen wrote:
| Rob here from Rownd. I just updated it, your feedback was
| spot on and I added a "try it now" button to the landing
| page.
|
| Edit: Even better, I updated the call to action at the top
| of the landing page. Thank you again for your feedback!
| [deleted]
| lajr wrote:
| Quick question: the NextJS demo seems to be doing auth on the
| client side which would result in a flicker on page load while it
| waits to see if the user is authenticated. Do you have a server
| friendly component in the react library? Other libraries (ex:
| auth0) have a special function which is deployed as a
| getServerSideProps function on each page, as well as an API route
| that handles auth requests.
| mhamann wrote:
| Great point! Thanks for the observation. Unfortunately, at the
| moment, we only have the client-side handlers built, but we do
| plan to add support for server-side rendering in the
| authenticated state.
|
| 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!
| rachelradulo wrote:
| Hi Hacker News! I'm a co founder and heading up design at Rownd.
| Looking forward to feedback and questions about your experiences
| trying out our product!
| jn31415 wrote:
| Do you happen to be hiring for customer support / support
| engineer roles?
| mhamann wrote:
| Thanks for reaching out! We have a couple of positions that
| we'll be opening up soon. DM me over on LinkedIn
| (https://www.linkedin.com/in/matthamann/) or drop me an email
| (mhamann@rownd.io) and we can chat further. :-)
| rgthelen wrote:
| Hey! Not right now, but I have do doubt we will in the future.
| Shoot me your info at robert (at) rownd.io .
| slig wrote:
| Congrats on shipping! How does this differs from Userfront?
| mhamann wrote:
| Hey, thanks! There are a number of companies working in this
| problem space, and certainly Userfront is one. But one of the
| most obvious differences is that the first thing Userfront does
| is ask you for a password. We'll never do that because we
| firmly believe that passwords are essentially a Web 1.0
| construct that needs to disappear forever.
|
| 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.
| rgthelen wrote:
| We look at authentication through a wider lens. Userfront and
| most options focus on authentication in front of an app. But
| what if you want to allow a user to continue without "signing
| up"? We offer the "unverified" option to let users try an app
| and move around in it. We also store account data and make it
| available to the browser to customize and personalize pages
| outside of the app itself. You can use the same Rownd code-
| snippet across your landing page, docs, and app and your users
| will stay "logged in". So if you know their preferences or name
| in an app, you can personalize the landing page or docs.
|
| What other features are you interested in?
___________________________________________________________________
(page generated 2022-03-09 23:00 UTC)