Cloud-based User Management for Web Apps(userapp.io) |
Cloud-based User Management for Web Apps(userapp.io) |
and distributing a web-app would equal to just open source it.. I know, it's a dilemna
edit: I seem to have been voted down. It was a serious suggestion though - did I misunderstand the question?
Am I wrong? Curious.
It feels like whoever is writing the copy is somehow belittling me. It's an overreaction, but I read it as, "you're a goddamn yuppie who would spend $4 on a cup of coffee. Why won't you buy your product, since your money seems to be burning a hole in your pocket?"
I hate to be negative, especially for something done in a lighthearted manner and probably as a parody of this trope in applications[1], but calling $649 a lot of pizza not only doesn't convince me, it makes me feel bad about myself—never a good idea to sell a product. Even cosmetics or fitness products are sold with a message of empowerment (you could look great!), not of belittlement (you look horrible, do something about it!).
[1]: Poe's law?
I think there might be a use case for this for simple projects, but the privacy implications of this in light of NSA and other government spying makes this unusable for most potential applications.
I understand that it makes sense to not write these types of user functions and management things over and over again. The solution however, is not a SaaS, but a library or a little framework. And from what I remember, major Web development frameworks offer exactly these types of functionality.
I don't want to be a downer and you guys probably spend a lot of time on the product, but from my perspective, any business owner using a third party to handle user data acts irresponsibly. You OWE it to your users to keep their data as tight and as centralized in one spot as possible – a spot only you and employees have access to and servers only you rented and have access to and not a third party.
I'd even rather use Wordpress as a basic user management platform than use a third party service. This way, it is at least fully under my control and I'm the only one responsible if things get broken or data gets stolen.
If the app becomes successful you can always implement these things in house later.
Or you could, well, let's say, use a library or framework and spare you the work of integration too!
At this point you are supposed to be working on the coreThere is a reason Gigya just raised 25mm more dollars. Granted, they do more than just user login as a service.
Knowing my audience and being able to monetize that is not the same as managing billing.
That said, it does sound kind of interesting, but from my own experience, I'd probably choose to build payments and billing myself.
Exactly because of this reason, you should use us. We have built a low-latency HA platform. And it's our core business. This means that we will do it the best way possible.
I can understand your concerns, but you could try us out on a smaller project to begin with. Or wait until we launch our licensed version which will allow you to install the system in your own environment. I.e. keeping the data safe with you and under your control :)
But it might cost a little bit more than $9 :)
What kinds of IDS solution do you currently have in place for starters? Are you using a software or hardware IDS? How are you doing monitoring of the IDS logs and reporting?
Have you done penetration tests beyond some sort of SaaS utility and hired a third party company to run them with a skilled analyst? How are you sanitizing input from external applications as you have to assume the incoming requests are suspect, etc.
I would like to run Javascript on the client that gets a user's private key from you, and decrypts their data on the client.
Do you have thoughts for something like this?
The library approach that I have tried with things like django etc. tend to need plugins for a lot of use cases, and I do not understand what pieces of code are intereactig with each other which is a big red flag. More complex SSO systems seem massively overcomplicated and difficult to configure.
I want something with the simplicity and definitiveness of an apache htpasswd file with a freindly user interface and assurances about security/hashing etc.
If it's apart of my service, I want it on my servers.
I launched a very similar service named Accthub about 18 months ago and unfortunately it didn't fare well. Now, there's Mozilla Persona, Stormpath, Userapp, and probably several other in the same space.
Hope you can turn it into a legit business, but the general issue developers had was:
1) This is not a legit issue I have, my framework can handle this in the matter of a few minutes, maybe an hour or two if I want something really complex. 2) Privacy concerns. 3) High availability issues.
Best of luck, I will be monitoring your service closely because I want it to do well.
This is something that we are very aware of. We only have good intentions and want our users to feel 100% secure with us. If you don't, please let us know how we can change that! :) We don't have it now, but we will make it possible to export all of the data in UserApp at any time.
Regarding security and privacy we have written a section about it here: https://help.userapp.io/customer/portal/topics/550128-securi...
Additionally, everything is SSL and passwords are stored using bcrypt. And we will make it possible to login using 3rd party providers later (OAuth). From a personal perspective, we will run this ship to the end of the world if we have to. Since we're developing quite a few other services (www.amail.io to mention one) we are also basing all our services on UserApp.
The dependency between my system and this one would be way too great to consider the option.
We do not (currently) manage pricing and plans for you, so that's a plus for UserApp.
We are more focused on user management, oauth simplification (FB, Twitter), auth, and user analytics.
We're also VC backed (Google Ventures) and are storing millions of accounts. Because we have a few larger clients bringing in real revenue, we're not going anywhere anytime soon.
Some unsolicited advice for UserApp:
* You need to address lock-in. It's the first thing everyone asks us. We designed our platform for zero lock-in and account portability for this very reason.
* This space can be a hard sale. People are reticent to store their user data in the cloud. (As they should be!) Compare that to the next social/mobile app that people will try on a whim. That's the bad news, but the good news is once you've "wowed" a customer, they will likely be a customer for a very long time -- even if you make export easy.
* Lastly: good luck!
Meaning give developers the nice UI and added features but connect to the database of the developer's choice to actually store User data. That might address security and what if you close shop issues.
A SaaS app that does something similar conceptually is CushyCMS -- you give them your FTP information and they provide an interface without storing or hosting your content.
Few suggestions:
1. Implement multiple ways to login (and charge accordingly) e.g Keyfile based, Color combination based, Biometric based, etc.
2. Do cross-platform API. I know you might think that BB is a sinking ship but to be ubiquitous you service needs to have an API on EVERY platform.
3. (This is more technical) Shard your db based on the location of your customers and accordingly replicate your data. e.g. If I launch a webapp hosted in India, I obviously don't want my customers to hit sweden or US every time they login (with the undersea cable breaking every now and then). If the India mirror of your service goes down then there will be graceful degradation (users will login slowly by hitting the other replicas) but not a full downtime. Basically for a customer X running webapp W, the primary replica should reside in the vicinity of where W is hosted but backed up by replicas in other locations.
4. Introduce a free development tier for upto 4-10 users.
Now, I know it's on your roadmap, but I would really like to see sample code integrating with one or more payment providers or recurring billing management services. Stripe and Recurly would be top of my list. Would love it if you could get that up soon.
Would also like more docs about the differences between permissions and features. I mean, I think I get it, but more specific text would make me feel more sure.
Minor bug: in my own account information, when I went to go edit it, you have separate fields for given/first name and surname, but you refer to both in the info/help text as a surname or last name.
Anyway, nice job!
If i were to use it, I'd want some easy way to export the users though. I know i could iterate through them all and get the data (maybe not password hashes??), but at one point a web app would probably need something custom enough that i'd just want to have all the data myself.
I think things like stopping invalid signups, good spam protection etc could push people to use this. Also integrating login via facebook/google/twitter and making it work seamlessly out of the box would be a big plus. For those small website projects it would be much easier/quicker to plug this in, and focus on the core of the app, rather than all the user backend crap.
I agree with the lion share of what WA said.
The MVP/prototype argument is a valid one, but remembering that nothing lasts forever, it's probably wise to think of these services as temporary tools and not permanent solutions.
I believe that user management is such an important (and basic) thing, that you should own it. For the hackers out there, feel free to checkout my Drywall project, which is a website user system build for node. https://news.ycombinator.com/item?id=4951605
Good luck.
If I want ownership of code, I'll use existing frameworks.
However, I feel like it needs a bit more until I try it out. Right now it would be a compromise between saving some hours in a few areas, and use those hours to learn Userapp and integrate it.
Anyhow, hope it moves along well – will check back on the progress in a few months and see if it have improved with more features, demos and examples.
This would eliminate most of the potential privacy issues that might inhibit usage of this.
I'd love to see something like this take off because its time wasted that prevents you from working on a core product idea.
I found this: https://news.ycombinator.com/item?id=4394114
I totally agree. Don't know how we could miss putting it up there. I will see to it that this gets the attention it needs on the front page. Thanks! :)
Very few startup start with their own server rooms, because part of the "failing fast" is failing cheap. And if you are making infrastructure investments before you find product market fit - well you aren't failing cheap.
I do think there is inherent value in controlling your whole stack, and running all things on your own servers, but I think this is a bit of a luxury most young companies can't afford.
Is this product designed specifically for startups? Is it intended to be removed later when you have 'found product market fit'? Isn't it more expensive to be locked in to this platform, which you don't have the source to, and can't modify if it doesn't 100% meet your needs?
That's what meant by failing fast. Find a quick way to validate your product in the market, then fail. Don't spend ages working on a product that will never work.
On digitalocean you can get 4G RAM for 40/month, 8G for 80. Running nginx and your favorite backend of choice, you will be able to handle any traffic your startup is getting. If you can't, you are already so successful that paying more won't matter....
I don't think that you own a digital ocean or ec2 instance - you rent them the same way you are renting the service this thread talking about. Given that chrismonsanto, is taking an even more hard line approach to controlling his stack than I do, I'm assuming he agrees (I know - dangerous).
When I talk about my servers I'm talking about things sitting in my racks (possibly in my server room), that I can rip components out of and upgrade. I'm talking about very expensive things, if not in terms of purchase price, certainly in terms of care and maintenance.
--
And to tie it back up to my other comment, I think there is value in owning your own servers, and in coding your stack from top to bottom, and having no external dependencies. But I think these are both very expensive choices - and the kinds of choices, most startups don't have the time/money for.
I'm actually OK with using something like EC2, because I control what runs on it. If I feel I can't trust EC2, or that it is too expensive, I can purchase my own hardware and move my stack to that. However, if I outsource my user management, I imagine the interfaces will be proprietary, and I will have to tear up my stack quite a bit to switch. I don't like that risk.
> I think there is value ... in coding your stack from top to bottom, and having no external dependencies
I'm also OK with having dependencies on other people's work, I just want the source code available so I can fix up things if necessary. I don't even require that the software is 'open source' or 'free software', since I don't plan to redistribute my changes. I do currently have one component in my stack that is proprietary (with source) and I have very much appreciated the ability to fix up things that didn't fully integrate with the rest of my service.
Of course, there are levels of dependence, and I think hosting on amazon or DO represents a much, much smaller risk than outsourcing your user management to a startup (or even a well-established company, for that matter).