Nice job! Some feedback:

1. Ditch the two pulsing animations. I tried to click on the pulsing animation top-left and nothing happened.

2. The logo is hard to read. Consider simplifying your logo, but keeping the flashing red record icon on home page.

3. Keep content above the field. I didn't know I could scroll.

4. Don't make me sign up to try it. Why can't it show my webcam feed on the home page? At least defer sign up after you've given me a link that will let me broadcast my feed, then I can sign up on my phone.

5. The flashing recording icon is distracting after the initial "I get it," e.g. on the register page.

6. Be more up-front about T&C on your access to the feed.

7. Nowhere on the site does it say, "Why do I need this?" Said what you said in your post here on your website. "Hey, I'm Geoff. I wanted to keep an eye on my kids & my pets, so I made uView to save money on a camera, now you can save too! Here, give it a try: [Request Webcam Permission]"

8. Hard to read the features with the pulsing thing.

9. The weight of multiple call to actions conflict: Register, Login and "Try Free Now" all feel equally heavy.

10. Hard to read centered text on privacy policy: https://www.uview.io/privacy - also, put Privacy as a main nav link.

11. Consider making it free for 5 minutes, then you have to keep clicking to refresh. Or, an ad-driven business model where you show highly-relevant ads overlaid in the feed, since you know the person using it is interested in security.

Good luck!

edit: @dang, pleeease can we get Markdown-style list formatting? :)

> 4. Don't make me sign up to try it. Why can't it show my webcam feed on the home page?

I would actually recommend against that. If the user gets prompted for camera access the moment they reach your webpage, it will turn most people off immediately. They need to click "yes I want to try this" before they get the security prompt, it needs to be asking for permission to do something THEY initiated.

… additionally, you have the burden of proving to the user that you’re worthy of trust before asking for something like this. Otherwise, this could come across as malicious.

I mean, my first thought when I read the headline was "Directly through the browser? Is that even safe?" … so I would expect the website to tread lightly, anticipating that there are a lot of security concerns when it comes to piping personal video around the world and addressing a lot of that up front.

Great feedback, thanks! Appreciate you taking the time to write all of that up :)

> Keep content above the field. I didn't know I could scroll.

Are you on a iOS device? Asking because your statement sounds weird to me

Me: Firefox on a mac, and it took me some time to realise I could scroll.

same "hidden, microscopic scrollbar" problem as their iOs devices, no?

Where does the data travel? That is, I have an IP camera that still works if my internet goes down because I access it over my local network. Would the same be true here?

No, we rely on an internet connection to stream video. Our application uses WebRTC to make a connection from one client (browser) to another. This is a two-way encrypted connection between the clients which allows them to stream video and audio over the internet.

Here's a suggestion for android. Instead of a PWA...make it a TWA.

It's the same code from your end, but it gets packaged as a mobile app.

To see an example , install "Google Maps Go" on play store

First I've heard of TWA... thanks for the suggestion! We'll definitely be exploring this.

I pay about $5 a month for my Google Nest doorbell, which also just happens to be a security camera.

It's kind of cool that I can repurpose an old laptop or tablet as a security camera; but if I'm really serious about a security camera, I'll go out and buy a dedicated camera that's smaller and comes with a mount, and similar priced monthly fee.

I'm going to be perfectly honest, I was much more excited when I thought this was a free framework that connected a browser client to another browser and only used the accounts for authentication. Many of the low cost IP security cameras on sites like Amazon use the cost of the camera to subsidize unlimited streaming. I have to say that business model appeals to me much more than an ongoing expense to use hardware I already own.

$5/month/camera for Nest, vs $5/month for unlimited cameras. But of course Nest has a lot more features, 24/7 video archiving, tagging, etc.

We launched UView with features that we felt would make it competitive with what is currently out there. We also don't plan to stop adding new and cool features.

Unlimited cameras and being able to view multiple cameras on one screen is definitely something that we felt was a big plus and differentiator.

If any browser can be a camera, why do you require me to register to try it out? I'm not ready to give you my personal details. You say below privacy is your primary concern, but you require us to give up our privacy just to try it out.

I guess they could do without the registration part if the demo only involved streaming your own video back to the same device. But the primary use case seems to be streaming from one private device to another (not broadcasting to the world), and for that they need a way to determine which devices are allowed to access which streams.

In most web frameworks, accepting signups and associating sessions with user accounts is the safest and easiest way to achieve this.

Or start the camera on the current device, show a code, enter that code on another viewing device.

Nitpick: grammar error in your features section.

> Get notified when something movement is detected on your video feed.

Since we are nitpicking, the title is also bad. The device I'm using to write this comment has a browser, but you'll never turn it into a security camera, since it doesn't have a camera.

You guys are using webRTC for the communication between clients and server ?

We sure are! We are using WebRTC in order to make it accessible on a large number of devices, but we are not using a public STUN/TURN server in order to keep our platform as secure as possible.

I am very curious about this approach. What kind of hardware/software. How much of a learning curve for the two of you as already-web developers?

I have only played with webrtc before, but what is the problem with public stun and turn?

I was going to say there aren't any, but here is a list: https://gist.github.com/sagivo/3a4b2f2c7ac6e1b5267c2f1f59ac6...

Thanks for posting this :)

There is no real problem with using a public STUN server. We are using our own STUN/TURN server just to ensure reliability and up time.

What kind of a stack are you running WebRTC on?

We're using React for our client app and bridging the connection using websockets.