I wish Mighty had succeeded for a different audience. The core value prop "make figma faster" was not very compelling--people who need to use Figma can buy a mac.
You know who does struggle with slow computers and memory issues? Call center employees who have to run Front, Slack, Chrome, and probably one or two other electron-based apps.
At our startup (not in USA), these issues are so bad we've ended up getting people who earn $700usd/mo M1 macbook airs anyway because otherwise an electron-based workflow is unamnageable.
I would have loved to buy them cheaper computers instead that ran entirely in the cloud...plus extra permission management, no local storage, and other "really, really, really nice to haves" for remote workers dealing with PII.
If Mighty's value prop had been "never worry about remote wiping an employee's computer ever again, oh, and it's faster too, and it's all OPEX, and we charge you by minute instead of by the computer" I would have signed up immediately.
They should have been competing with Citrix and others in the B2B space rather than in the B2C space with MacBook users. I am not sure why they didn't, even with something like Citrix they could outcompete it on UX alone, like Zoom did with Webex, ie lower latency, it "just works" etc.
Probably due to time constraints. B2B takes a long time to get moving, B2C allows fast feedback for rapid iteration early on. B2B requires integrations, lots of tangential work that doesn't build the core product.
They may actually have made the right decision - it got them to "time to pivot" without running out of cash.
The browser focus was peculiar since there seems to be little room to generate enough value to justify the cloud costs.
I'm surprised they didn't try to pivot to another initial market en route to building a general cloud PC.
My company (https://softdrive.co) is in the same space - our initial focus is on empowering companies running high end graphical workloads (BIM, CAD, etc) using cloud PCs.
Curious why per minute billing appeals to you. Usually we've heard preference for predictable monthly pricing.
I agree with your core point that Mighty could have succeeded, but specific to your use-case: Mighty is “just” a nice layer on top of well-established remote-desktop technology, what pushed you towards M1 MacBooks instead of remote desktops? There’s lots of great options out there, comparable to Mighty on price (a little more management overhead, for sure, which is why Mighty was the ideal option — but still much more cost effective than buying MacBooks).
It would never actually have been cheaper. The problem basically is that time of access isn't actually distributed, and a lot of the time leaving stuff set up and running is important.
I'm not a fan of depreciation schedules and whatnot, but I don't think Everything as a Service is going to be the answer.
Reasonably priced PC laptops that can run Chrome and Electron do exist. Just don’t buy bottom of the barrel Celerons, instead target an i5 or a Ryzen 5 (or maybe a higher-end i3).
From my experience slow laptops are slow not because of the cpu (I mean, we’re not running a chess engine here…) but slow disks and slow/not enough RAM, which compounds the disk issue as soon as you start actively swapping… which in some of these is about as soon as the OS boots.
Like, I just loaded up the Best Buy app and 3 of their top 10 selling laptops only have 4GB of RAM. I haven’t used a computer with that little RAM in over a decade.
There was another company called S2 Systems doing something similar to Mighty a bit earlier, they ended up selling to Cloudflare and I think the technology became the browser isolation product:
Streaming Chrome with some value adds must have been a short-term product right? It could only have existed until PCs caught up on processing speed (Apple's M1?).
I wonder what vision did Suhail pitch to PG to deserve high praise. Because this can't be it.
Maybe four years ago it was seen as a strong counter to ad/tracker blocking. But now, with increased regulation and consumer resistance they couldn't make that play?
Doesn't have to be personal data. You'd know the performance of every website's funnel, most used features of every app etc. Somebody would have paid a lot for it.
In my opinion, this is the right goal, but I don't think this can be done by running existing apps in the cloud (and remoting their UI). Instead, I think we need a new cloud-native platform so that any app can be written as a cloud app. (Obligatory self-promotion: that's what we're trying to do with https://gridwhale.com)
> The ultimate vision is/was to have everything run in the cloud. Imagine if you could run any app on the most powerful machine in the world.
IMO the core paradigm shift that needs to happen is for the software and infrastructure to become commoditized. The only way for cloud-everything to not be a nightmarish abuse of the end-users is for the mode of operation to change, from the current "data comes to the app", into "app comes to the data". That is, I believe the data, the application and the compute running it need to be independent to the extent possible.
In particular, the choice of an app and where it runs should be entirely up to user. The user should be able to easily switch from e.g. a cloud run by Amazon to e.g. a "cloud" run by their HOA in the basement of their block of flats. And then possibly switch to a cloud run by a company local to their city, or one of their employer, etc.
The primary point behind my view is to prevent application vendors from being able to take their users hostage by keeping users' data under lock on their own infrastructure, accessible only through their own software. The second point is to increase efficiency and boost local markets worldwide.
There needs to be some reason for users to chose to run their code. Maybe if self hosted software was somehow even cheaper than cloud software? Or maybe they hear about their friend/cousin getting their data stolen by hosting it in the cloud? Or maybe its so much faster hosted at home that the cloud can't compete. Or especially if its easier to store it yourself than it is to store it in the cloud somehow. I wonder if self hosted software can compete on any of these metrics? - safety, cost, speed, convenience?
Unless apps could migrate between high and low performance instances, at the end of the day you are back to either over-provisioning ($$$$$$) or over-subscribing (shitty performance). This is exactly the problem space that makes everyone always hate the VDI experience.
Yes, that's exactly it. Local UI (initially in the browser, but could be on a rich-client or mobile app) but all compute is in the cloud.
The difference from existing thin-client models is that it's a single stack: When you write a program, you write the UI code as if on a local computer. E.g., you just call MessageBox("Hi, there") and the platform is responsible for remoting that as appropriate.
"A super massive global mainframe" is the correct analogy, but instead of a text-mode VT100 terminal, you get a full remote GUI (more like X Windows).
> I wonder what vision did Suhail pitch to PG to deserve high praise. Because this can't be it
From what I've read, sounds like a thin client machine based on the web. Chromebooks but even thinner, relying on SSR. I think that's a plausible vision that could have driven the upfront costs of hardware down in return for a subscription.
Pithy vision - "a new type of web-centric computer"
Edit: I really liked following Mighty, and it's exactly the kind of speculative startup that you can respect and admire even when it doesn't work out. They didn't do anything wrong, they tried to make a useful valuable product but failed. A worthy endeavour.
What annoyed me about Mighty was that it represented giving up on having fast, efficient software on our own machines. We COULD live in a world where 400+ tabs (typical for me) didn't require 32gb of RAM, but browser authors have chosen otherwise, and that sucks. The idea of pushing the entire browser to some other computer, and over-speccing that one, instead of actually making better software, just seemed like a cop-out.
This person's claim that Mighty customers didn't open huge numbers of tabs and use a ton of RAM makes no sense. What OTHER purpose could a $35/m cloud browser possibly serve??
While I never really believed in Mighty as a concept, I think the technology has enormous potential in some industries. A robust, performant and versatile VNC like toolkit to enable traditionally desktop software to be made available in the cloud could be be very successful.
There are many CAD, Visualisation, Rendering, Editing, and Simulation tools that are incredible CPU, GPU or Memory intensive that could be made available in a collaborative environment for the first time using some of the Mighty tech. I hope someone picks it up and explores other ways it could be used.
There are tons of these solutions in production for well over 10 years. Big media customers has run virtualized edit bays in AWS for at least 4 years at this point.
Reasons people don't use these solutions are the same reason Mighty ended up not working. Even in CAD applications, latency matters when trying to move objects in 3D space with precise mouse input or using a 3dconnexion spacemouse. Sure, you can overcome latency by doing what Google essentially invested in with Stadia, run GPU's closer to the edge but at that point the cost of just buying workstations for your employees is not that different from acquiring a stable connection (for 8+ hours a day) with the fee of renting the hardware.
We’ve been working on a way for browser-based apps to run a rendering thread on the server and streaming back to the client, possibly composited into client-sode-rendered UI. So far the results are promising: you get the power of a server-side GPU with no additional latency for the normal UI interactions that can be drawn without a server round-trip.
Here’s a demo of a full-blown Blender “running in the browser” (I don’t have a demo with local compositing yet, so this is all server-side)
Having used both Citrix and Mighty, it’s clear Mighty cared about latency in a way that Citrix doesn’t (or, more generously, is out of control of Citrix since they don’t own the end-to-end system)
I think it's more of a hybrid approach, the web renderer was running in the cloud, the ui was native and local.
I beleve Citrix is mostly a standard VNC type product where everything is rendered on a server and streamed. I was envisaging a toolkit to enable you to build an app where parts of it run in cloud, parts of it locally.
Think of a 3D cad tool, the ui could be all local, but the rendering and compute is in the cloud. Or a 3d physics based ray tracing app, you could do the 3d wire frame locally, but have the real-time ray tracing happening on a very large server.
On top of that, by have a cloud based state, it's only one step away from marking that state shared with other users to enable collaboration.
You're misinformed. Citrix has plugins for managing aspects of GUI rendering, video/audio playback and GPU pipelines local on the client, which are a key part of the "secret sauce" behind their success in industry.[1] This is a product which is being used today for remote CAD/CAM workflows in the largest firms, whereas afaict applications of Mighty's product to this problem sphere is nothing but idle fantasy by HN posters?
There is no technical challenge here. You can rent GPU instances from any cloud provider. Each of those has a built-in hardware video encoder. Then you can proceed to stream your CAD app/game/desktop/website over the browser with WebRTC. It's almost all OTC software. Stadia does it. Geforce Cloud does it.
There is no technological innovation left in this space. You can package it with a nice GUI and convenient user experience, but I feel like that's hardly a billion dollar startup idea.
> RAM: Mighty allowed users to open hundreds of tabs without being worried that their RAM would be consumed. But my sense is this was not a killer feature. The benefit simply isn’t massive: the alternative is to close tabs and “clean things up”. Many people probably do this anyway because it’s visually hard to have hundreds of tabs open, so users end up closing tabs even with infinite RAM. This is evident in the data: when we gave users 32gb of RAM, 90+% of them didn’t go beyond 16. We did have the opportunity to provide users with a whole new interface of tab management – one in which tabs never have to be closed and hundreds of tabs are visually manageable. Maybe this would have been a smash hit, it’s hard to be sure.
What I want is for the address bar to give me a really quick way to jump to existing tabs, if I start to type in the address of one I already have open. The entire reason my tabs get out of control is that at some point I get enough open that I start to lose track of what's there, and repeat myself. End up with like 5 AWS tabs, only one of which I'm actually using, stuff like that. So finally I just bookmark the whole set ("just in case"—I've not once looked back at these, in almost a decade of working this way, though I bet there's some great shit in there) and start over.
Apple's "tab groups" approach being a solution, but the trouble is I forget to switch to the correct group for a given site and end up using a single jumbled-up session anyway. It needs better (more automatic, probably) UI.
Others mentioned Chrome doing this, but it never really seemed to work reliably for me.
This actually came up in a thread the other day, so feels weird to be talking about it again, but I've been playing with Arc[1] lately. Took me a while to get used to how they treat tabs (almost more like bookmarks) but I've enjoyed it. Squirrel the ones I want to truly keep around into folders ("To Review", "Some Project"), but all the randomly opened tabs automatically get closed after a specified time period (default 24 hours, I have mine set to a week). When I hit cmd+t I can _reasonably_ often get to the right tab I've already got open.
I have a feeling the honeymoon will end when they start trying to figure out a monetization strategy, but so far I'm rooting for them.
Just manual settings I could use to say "always open this site in tab group X" or "prompt to move this site to tab groups Y or Z if I open it somewhere else (but with the option not to)" would probably make it usable-enough for me.
> What I want is for the address bar to give me a really quick way to jump to existing tabs, if I start to type in the address of one I already have open.
Chrome's been doing this recently and I absolutely love it
The offered value was simply not worth what they were charging. I would venture to say that it would be difficult to sustainably charge anything at all for this. For most people, the alleged slowness of Chrome is good enough. Why would the normal person go through the hassle of paying for an experience that was only marginally better than something that was available for free? Their best bet was an ad-based model but that comes with its own set of drawbacks.
In general all alternative browser products that charge money face the same issue. Netscape already tested this business model in the 90s.
For this reason and for many people this app was DOA from the inception. The founder should have carefully considered this criticism instead of disregarding it and using it as "fuel" https://twitter.com/Suhail/status/1196458286347776001
Sadly it seems his new startup is jumping on the trend of generative AI. This is another product category that is doomed to failure yet has tons of tech industry fanfare (similar to web3, which is on its deathbed). For most professional artists, it's not hard to do the actual drawing, the difficulty is coming up with the subject matter / concept for the drawing. Generative AI may have a market for low quality yet high volume content creators that auto-generate content on YouTube or other social media for a modest living.
I wonder if they ever got around to implementing accessibility, e.g. for screen readers, in their remote browser. That's an interesting problem. Do you send serialized accessibility trees (and hopefully incremental updates) down to the local machine so it can implement the platform accessibility API and work with a user's existing assistive technology (e.g. screen reader)? Or do you run the AT remotely as well? I believe the former is feasible with Chromium (though I haven't yet proven it), but Cloudflare went with the latter in their Browser Isolation product, probably because converting the Chromium accessibility tree back to HTML in the local browser would compromise the security benefit of Cloudflare's product. But Mighty didn't have that concern AFAIK.
The group of people for which a browser is truly horrendously slow would be on something like a low-end Windows laptop. From mid-end and upwards it's fine (or good enough) and for Mac users pretty much never an issue.
The people with such crappy hardware are exactly the group to not be able to afford 35$ a month. That's like the price of 3 or 4 streaming services combined. Just to browse!?
You can lease a laptop for that kind of money that can actually run a browser well. I was actually looking at some offers for a macbook air on grover.com. They have an m1 / 8gb one for 48/month if you reserve it for a year. Great laptop for browsing. You can get cheaper laptops there.
Basically this product was a solution looking for a problem. The pricing is ridiculous of course. But I don't see how a lower price would have solved that problem. And the pricing was tied to them basically using very expensive VMs (16 cores, lots of RAM, GPU). And since they struggled with quality of service issues (i.e. it did not actually work that well), the whole thing was doomed. But even if it had worked, it would basically still be a solution looking for a problem.
I had a similar impression of it, the best I can come up with is I think it was a bet based on a prediction of the future that is kinda true, but just doesn't matter as much as they thought.
1. Personal computers are dead and just a means to access a browser via dumb terminals
2. Applications will be Figma style - web based entirely.
3. Intel/AMD chips are bad and not getting that much better (this one is true, but missed the mark entirely because of Apple silicon throwing a curve ball)
4. Given that your personal computer is basically a dumb terminal to a web browser you could imagine a world where it doesn't matter and it's worth paying $35/mo for a super computer to run your web apps streamed to whatever local hardware you're using, since your local machine is basically useless as a machine and only serves to load a web browser (which is where your actual applications are). This super computer will also remember state so any devices you access mighty on is exactly as you left it. Long term, this could end with a Chromebook like devices of some sort that just connects to mighty and are really nice low power hardware.
--
Personal bias aside (I hate this future and I'm actively working on software trying to bring personal computing back in a from first principles networked way) - it was a bet on trends and fits squarely into the PG concept of a good startup being a bad sounding idea that might have recently became good because of changes in the environment that have not yet been really recognized. I think Apple made it less relevant. I also agree there's a weird issue of who is the actual target market at that price point (the exact people that would maybe need it can also afford good hardware).
That and there is obviously fertile ground in AI right now and the founder sees a bigger opportunity there with a lot of low hanging fruit.
> Intel/AMD chips are bad and not getting that much better (this one is true, but missed the mark entirely because of Apple silicon throwing a curve ball)
Define "bad". I'm on a 2019 MB Pro with an i9 with 32G of ram. I pretty much never have browser performance issues that bother me. I have Chrome open with 2 windows and a total of 39 tabs, plus some other apps that people always like to bitch about resource-wise (Slack, VSCode). Granted I'm not a designer so I don't have what would be some of the most resource-hungry apps like Figma, but if there is one group of people who I've always seen spend a shitload on their desktops/laptops it's designers.
I think Mighty was always a weird project that pretty much only solved a problem for people that would never be willing to pay for it.
Expensive, but basically obsolete now, thanks to the M1. I had a 2019 MB Pro (i9, 32 gigs RAM) as a dev machine. It was terrible: fans running constantly, throttling. My M1 Pro machine is soooo much better.
Yes, I know it was a high end laptop at the time, but you can get refurbished ones now for about 800-900 dollars, putting it squarely in a mid-range laptop market. Would be even cheaper with, say, 16G of RAM, and still be totally capable as long as I just closed some unused browser tabs a bit more frequently.
You are overblowing the Intel/AMD/Apple Silicon thing. Intel/AMD CPUs that aren’t complete cheapo garbage have more than enough performance to run all those fancy apps.
I appreciated this commentary. When the news from Suhail came out as quite sudden, realistically there's a team under a struggling company working tirelessly to fulfill their vision.
It sounds like M1 was the nail in the coffin - though you'd think this is a normal question for an investor to ask re defensibility when deciding to invest in the company (a version of the classic "What if Google entered your market?"), and thus something they would have had rebuttals for?
I'd argue that this isn't a retrospective in it's truest form. I would like to have a piece that's more about the metrics, like what sort of churn they got, how was their launch perceived, what sort of market research they did/ didn't do etc. These sorts of pieces would help make the lonely startup world more transparent and accessible (it's easier to do this after the fact, rather than when keeping up appearances when trying everything to keep a company alive). Perhaps Suhail will bless us with this at some point.
Q: It was a great product I was a paying customer. I used it like crazy on my old MacBook but as soon as I upgraded to an M1 Pro it didn’t feel as a must have for me and wondering if you found that with others
A (Suhail): We did but the mac market isn't as big as the PC market so it wasn't a critical factor in the decision but certainly had an impact as mac users.
Mighty would have been huge imo if they just waited a bit longer and pivoted to powering browsers inside of mobile VR/AR all day wear devices, like the upcoming Apple visor, where there are basically no resources available to be used for things like figma yet having a fast, scalable browser anywhere would be amazing.
I agree. I guess there's nothing wrong with going in a different direction for a few years until there's actually display glasses that this would feel good with.
> Mighty’s short term goal was to make people more productive with their browser.
I believe the biggest reason for their failure and lack of traction is because they misidentified their value proposition from day 1.
No, loading web pages marginally faster is not going to make you more productive. It will save you a few minutes per day in the best case scenario, nothing else.
Productivity does not come from loading speed, it comes from how quickly you can identify the information that matters on a page and absorb it.
This HackerNews page took 320ms to load, but I've been on the page for 5 minutes already. They really think saving even 90% of the load time is going to make any difference to my _productivity_?
I have some experience building infrastructure for on-demand cloud hosted desktops (HDx3DPro) for scientific users and their apps. Often wondered if there was a consumer play there too. Better someone tried and failed than never tried at all.
I appreciate the swing and I pointed this out early-on, but I wouldn't bet against Moore's Law - the hardware gets faster and cheaper. Back when they started 16GB was pretty high end, now it's more mainstream with 32GB being the high end...
And I think it's a very niche use case to have hundreds of tabs open - like, that's hoarding, like, just close some, you'll never get to all of that.
Mighty was great. If they had a Windows/Linux port it would be killer as it would have allowed you to run all kind of apps without carrying a $1.5k computer around. That was the dream.
I'd also expect their pricing to go down given economies of scale.
I lowkey wanted them to be super ambitious and one day roll out their own chips and become a full stack computer company.
I was one of the people not only perplexed by the positioning, but that they managed to raise money. Props to Suhail for selling it - it does make me wonder how many great ideas are slipping through purely from VC's requiring flashy sales skills. But I guess that could be said about almost anything.
I use Arc and it deals with the memory issue differently. Only your pinned tabs are kept, the rest disappear over time. I like that functionality. Overall, I'm enjoying using it.
>CPU: We gave users a 16 core machine just for their browser, but it turns out that the web is largely limited by single core performance (think JS, layout, html parsing, etc).
I'm pretty sure that javascript being largely single-threaded was well known knowledge since day 1. Did they not know this? Did they think that mulit-threaded javascript was just around the corner?
If each of the 100 open tabs are all run in separate threads, then there are a 100 active threads. I think what TFA means to convey is, the user is interacting with only a single tab at any given point in time; hence any percieved gains are bounded by single core perf. And that there weren't that many web-native apps using service workers to make any material difference to the UX to justify the cost of running just Chrome on a 16-core i9 machine.
Java uses multiple threads even for single threaded code, the JIT compiler has threads, the garbage collector has its own separate threads. I don't see why a JS implementation wouldn't be multi-threaded even if it is presenting a single threaded environment.
Seems crazy to not know your application's performance profile before picking out the hardware to run it.
JS is single threaded, but does a browser use that same thread for rendering, animations, web workers, network etc.? How much front end JS code is intensely computational vs. simply spending most of its time waiting on a callback?
Genuine question - I might see if I can find out next time I have to do a performance profiling in Chrome!
The design of web APIs means that a lot of stuff has to happen as if it were on the main UI thread, so while you can do fork/join stuff to optimize it - for example, doing layout in parallel, etc - you're still bottlenecked by how fast the main thread is able to do all the stuff it needs to do. This is why many APIs disallow synchronous use or have serious constraints on synchronous use now.
AFAIK, rendering and animations are on the same thread as JS.
web workers have their own thread, but I think adoption is low.
Network requests are async (JS doesn't have to wait for the network request for it to do other things), but JS can still only start one network request at a time.
The place where they really could have won is iOS, where browsers aren't allowed to use their own rendering engine, and system specs still lagged behind the M1.
I'm sure Apple would have rejected the app from the store, unfortunately. Lots of vendors have failed to get streaming apps of this sort onto the store and had to (heh) distribute them via Safari as web pages instead.
Author here, I just noticed this was on HN! There’s lots of great points raised here that I didn’t cover. I published this with very little feedback, so I’m not surprised I missed things. I’ll go through some of the additional points, though:
* Pivoting towards enterprise. Not with speed in mind, but instead security/control/compliance.
We didn’t spend too much time here, so I can’t definitively say this wouldn’t have worked. Cloudflare had (has?) just this vision when they bought S2: https://blog.cloudflare.com/cloudflare-and-remote-browser-is.... There is at least one critical roadblock that I see: wifi and networks can be spotty. If only 80% of a company’s employees have good enough internet, what do you do as an administrator? Force them to figure out notoriously difficult wifi problems? If you don’t, those that don’t like the browser will simply not use it because they’re not required to. Given this, I always thought of this as a secondary market. First, make something great, independent of being required to use the product. Then start building out other tools that make businesses more enticed. We did sell to companies in multi-seat deals, and were eager to keep pushing in this direction. Note the tag line: “A new browser to work faster”.
* CAD/Rendering/Simulation/etc instead of a Browser
The trend is that all of these are moving to the browser. However, maybe not fast enough and Mighty was too early. It’s also a more crowded market (Citrix, Teradici, now Parsec, etc) and yet smaller than the browser market (well, by users at least).
* Powering browsers inside of mobile VR/AR
We never tried this. My sense is we’d be too early (at least 2+ years?).
* Accessibility, e.g. for screen readers
This was never a big enough priority but yeah, it seems solvable. It’s more or less another API to implement.
* Loading web pages faster is not going to make you more productive
As I see it, there are two buckets of speed. The first is to make fast things faster. The second is to make slow things faster. The two can work together. The real value prop is the second, but the first is where you can bring lots of delight. But I think there is some truth to this. Of the loyal paying users that we had, they felt substantially more productive. But could this benefit offset the price + downsides? Knowing what I know now, I don’t think so. But there’s a lot of context about what’s actually possible, what a wide spectrum of people value, etc that gets me to that conclusion.
* Who really, really, has a slow browser that’s willing to pay $35/month due to it?
This was my first thought when we starting working on a Browser. One thing I learned was to hold back my gut instinct and prove the answer, instead of guessing it. The empirical answer: thousands of people that we could find through minimal marketing (just Twitter, basically). Does that mean there are a million+ people out there that also have it? Maybe.. it’s hard to tell. But my personal hope was that this quantity generalized somewhat to the 2B users of Chrome so that we could at least make a profitable business. If we got there, we could move into areas where we were solving more problems.
So to directly answer the question: I’m pretty confident this market exists. But not if Mighty also has the downsides it did (doesn’t work well in cafes, a variety of bugs, etc.)
Yeah, I think the whole thing is weird. Why just give up so fast and easily? They made the thing work, hell I was a paying customer.
Seems like the founder just moved on to the next shiny new toy instead of fighting it out until the end. I have a sneaking suspicion PG won't be talking about him anymore.
You know who does struggle with slow computers and memory issues? Call center employees who have to run Front, Slack, Chrome, and probably one or two other electron-based apps.
At our startup (not in USA), these issues are so bad we've ended up getting people who earn $700usd/mo M1 macbook airs anyway because otherwise an electron-based workflow is unamnageable.
I would have loved to buy them cheaper computers instead that ran entirely in the cloud...plus extra permission management, no local storage, and other "really, really, really nice to haves" for remote workers dealing with PII.
If Mighty's value prop had been "never worry about remote wiping an employee's computer ever again, oh, and it's faster too, and it's all OPEX, and we charge you by minute instead of by the computer" I would have signed up immediately.