Nice looking website, pleasant color theme and clean use of illustrations. GJ!

One thing that really strikes me as off target is that the pricing is solely focused on disk space. For many web applications, that's the least of your worries (although speedy SSD is arguably nice). I'm much more interested in CPU and RAM - care to share?

Beautiful aesthetics, but "best" new music? What constitutes best, highest play count or billboard ratings?

Meanwhile, until then, throw a direct link to an example project in here so we can give you some feedback :)

Was just going to post about Firebase. It's not ideal for all type of projects, but most can easily fit into the backend-less model quite elegantly.

Major benefit is that it takes care of so much of the plumbing: authentication, server setup and maintenance, scaling, storage, analytics/reporting etc. and it comes with an excellent SDK. In short, it allows you to stay in the frontend and focus on what you do best.

Really Apple? Really??

What?

Android accounts for 85% market share and Android development has become just as streamlined as iOS, if not more. I'm a designer, I have an Android phone, I appreciate great UX just as much as you and will gladly pay for great apps.

The time for pretentious Apple tunnelvision is way overdue dude

I realize that this is really in the nitpicking department, but I think a few minor tweaks might make it a bit more pleasant: - A tad lighter than the current dark blue - 5px more right margin to the logo - A bit lighter search bar placeholder text

Side-by-side preview

Otherwise, I do really like it, it just takes some time getting used to :)

Custom domains with https not supported :'-(

Coward would be a more appropriate name - only the weak can't afford to lose $159 ear-plops because you get sweaty ears when going for a run

"Lazy" is a tricky word I'd be careful using.

Product teams have A LOT of stuff to do and balancing priorities is a tough game. With early stage startups, MVPs usually includes must-haves and a thin slice of nice-to-haves where benefits outweighs cost. And unless you're doing document editing or a similar Office-like product, an undo feature is considered glossing on the top.

That's not to say that it's unimportant - quite the contrary - but it's 1 in a million of features, bells and whistles that's on your UX wishlist.

The biggest issue in my opinion is still implementation. Flux architecture does indeed help on the client-side, but state often needs to be synchronized with a backend API. So for each [POST] /model you make, an undo should make a [DELETE] /model/:id and that quickly escalates like a wildfire when you need to consider relational entities, validation, error handling and so forth.

If we could lower implementation cost by developing/chosing tech stacks that have undo capabilities baked in from the get go (both frontend and backend), I'm certain you'd start see it everywhere. One can only dream, eh :)