It’s an online tool that will convert your web app into a desktop app. It’s super-straightforward and, hopefully, it just works.
I’ll be doing a broader release next week but looking for some feedback first from bootstrapped first.
Everything should work. You can build an app for Mac and Windows at the moment (Linux coming soon). If anybody wants to try it out then just let me know and I will refund 70% of whatever you paid. Of course, if you’re not happy or it isn’t what you expected then I will refund 100%.
Would love some feedback on the landing page, pricing and product. Any feedback that I’ve received so far suggests that pricing is too low, so particularly interested in that.
The site looks slick, but it’s not clear to me how this works, and I’d need the technical details before paying anything. Does it just open up a chromeless browser window (which browser?) on my site? Does it try to bundle all the files in with the installer? If so how do I deal with updates? etc.
The preview on the Window Dimensions page shows the base HTML of my app (https://reviewable.io), with no images or styling. This doesn’t inspire confidence that things will actually work.
Some of the features promised on the home page don’t appear to actually exist in the build flow. “You can edit […] the window frame UI style/colours. You can even edit how the installer looks and how it installs your app (e.g. would you like your app added to desktop by default?)”
Don’t make me pick between platforms. If I wrote a web app, it’s clearly because I want it to work everywhere. Raise the price ($100 seems reasonable to me) but include all the installers.
Just my 2 cents. I actually had a couple users request a desktop version of Reviewable, so if I better understood how ToDesktop works it’s quite plausible I’d pay up and get it done.
First up, this is excellent feedback and it’s exactly what I was looking for. Thank you so much.
It uses Electron under the hood. So it basically bundles its own standalone web browser based on Chrome. This adds a little bit to the application weight (The installer file will be ~40-50MB) but it gives consistency of experience. It doesn’t bundle files for your app, it fetches them remotely, it basically works exactly like it would in a web browser.
I’m really sorry about this, I’ll get it fixed. Technical Details (click to expand)
Your site contains the response header x-frame-options: DENY, this is actually very common and it’s a good practice. What this means is that the <iframe> used to preview site is blocked. This is usually fine because ToDesktop has a fallback mode where it will proxy the request for your site on the backend. This requires doing some jiggery-pokery to the <base href="x"> tag, your site already has a <base> tag, again this would usually be ok because I have some code to deal with this situation but it is not set up to deal with domain relative paths like you have. It’s an easy fix, thank you for reporting.
You’re right. I should have made it clear that these features weren’t implemented yet when I posted this. If you have any specific requests then I’d be happy to do a custom build for you.
Yes, I think I agree with you. I’ve got similar feedback a number of times.
If I better understood how ToDesktop works it’s quite plausible I’d pay up and get it done.
There are some CORS restrictions with the CSS font files on your server so it won’t look exactly correct but it should mostly work ok. I’m going to fallback to taking a screenshot on the backend for cases like this but it hasn’t been implemented yet.
I tested building your website by the way to make sure it was ok. Here’s what it looks like on Mac.
Thanks for the response Dave! Here’s some more feedback:
You need to offer some means of contacting you on the site, preferably via email. If I had landed on your home page cold I would’ve bounced hard because I had all these questions and no obvious way to answer them.
You need to provide way more technical detail on how this works and any limitations. Basically, the price you’re charging is a rounding error for an established business, but what I can’t afford is time to troubleshoot and deal with customer issues. At least half the value (if not more) of your offering is that you’re packaging your expertise in deploying a web app to the desktop: provide evidence that you’ve thought things through and I don’t need to worry about it.
What if I do run into issues – what kind of support do you offer? For how long after the initial purchase? Again, there appears to be no point of contact for this, which is a red flag for me.
What if I need to update the icon or URL in the future for the same app – do I need to buy again?
More technical questions: If Chromium is bundled with the installer, which version and how does it get updated? What happens if the app tries to open a new tab? Does Electron support workers (service, web, shared)? For shared workers, what’s the sharing scope – i.e., will new tabs share the workers? How about localStorage and IndexedDB?
In general, what are the technical questions that I don’t even know to ask? Every technology has limitations and as the expert it’s up to you to warn me about them ahead of time. If I don’t see any limitations listed I get suspicious.
Basically, to get me to buy you’d need to 1) ease my mind that offering the desktop installers won’t create more debugging / maintenance work for me, and 2) get the Linux installer done (since my customers are developers I have way more than average Linux users).
This is an absolutely fantastic list of issues @piotrk. Some of them I have in my pre-launch todo list already but not all, particularly around explaining the technical side of how this works. I will do better!
To answer some specific questions that I haven’t documented on the site yet:
I offer email support for 12 months from purchcase. There will be a subscription version eventually which offers support for the duration of the subscription. Existing once-off customers will receive a discount on the subscription version if they decide to switch (details are TBD). Of course, the app will work forever whether you are on once-off or subscription version.
Currently, the solution is to send me an email and I’ll sort you out. It’s on my todo list to have a technical solution that doesn’t require anything manual but this won’t be ready for launch. I will document the “email me” policy in FAQs and terms though.
Chrome/69.0.3497.106. Currently, it doesn’t update. You would need to build a new version (and pay for it). Subscription version will auto-update in the background (just like Chrome).
By default, new tabs will open in a new window within your app instance if the domain is considered “internal”. If the domain is “external” then it will open in your default browser. “Internal” domains are any domains which are on the same second-level domain as your app’s URL. This will be configurable but configurability is not available right now.
Yes, all workers, localStorage and IndexedDB are supported. Sharing scope is exactly the same as Chrome in all cases but not shared with Chrome (i.e… Chrome and your desktop app are completely isolated instances and you have no access to workers running in the Chrome browser).
At the moment, the main one is the auto-update functionality for the underlying Chromium/Electron instance but you have flagged this already and I have a solution in the works.
Another caveat is that browser autofill isn’t implemented yet. Cookies persist between sessions though (just like every other browser), so depending on how you handle login this is probably not much of an issue.
This is very clear. I will get to work and I’ll tag you in a post on this thread when I feel like the product meets your needs.
Finally, your feedback has been invaluable. THANK YOU!
Thanks Dave, happy to help and sounds good! However, please add auto-updating of Chromium to the must-have list; I can’t afford to have non-updating instances out there, since my app pretty much assumes evergreen browsers.
Also, one extra random idea for you: how about offering ToDesktop as a desktop app itself, so prospective customers can try things out hands-on?
I should explain this a bit more just in case it makes any difference to you. The client-side auto-update functionality is already there and working but the backend server infrastructure is not (yet). What this means is that the app will look for an update but the server is currently telling it that there is no update available. When subscriptions and the auto-update backend are available/implemented then it will be as simple as switching over to the subscription plan and all users of the existing app will auto-update seamlessly.
Yes, already on the todo list, it will come after subscriptions/auto-update.
As you can probably tell, I’m hugely focused on getting this to market and getting feedback + validation ASAP. Perhaps a little too eager. I’ve been burned by my previous startup where I took too long making things perfect and not getting validation that people actually wanted it.
Gotcha. I think that makes it reasonable to adopt ToDesktop before the auto-update server is ready, but there’s still some risk (how much will the subscription be? what if you never get around to building the server?) that would need to be balanced against the earlier benefit. In my case I think the trade-off falls on the side of “wait”, but I’m totally in favor of launching early and iterating. The first version of Reviewable was seriously embarrassing.
Thank you for the feedback. I wonder what you think a good price would be for a monthly subscription when I introduce auto-update (of the underlying browser engine) functionality? I think that auto-update is a requirement for a lot of the more valuable users of ToDesktop.
Yes (it uses Electron which is based on Chromium/Chrome). Views are cached in the same way that chrome has caching. If you want more aggressive caching and more “native-like” responsiveness then you can use something like service workers.
Thanks again for your invaluable feedback @piotrk, it helped hugely in informing where to take the product. I’ve gone through several iterations, added auto-update and a few extra features. Would you be up for taking a look at ToDesktop again and giving me some feedback? Here’s a link: https://www.todesktop.com/beta
You can enter a URL in the call-to-action and take it from there.
I think pricing is directed more by what you desire than what people will be willing to pay.
This should be a one-time, $99 (or $199 or $299) fee for creating a desktop app + allow for creating a demo version for free (that has a huge watermark or expires after 2 weeks) so that people can test-drive it.
Maybe you can swing $49/month as additional feature (i.e. $99 to create the app in the first place + optional $49/mo for auto-updates).
I would punt on auto-updates until you have had at least 100 customers and many of them are asking you to provide auto-updates. The browsers technologies are not improving at such a fast rate that updating browser core will make a visible difference to most of your customers.
You should also think about differentiating pricing on volume.
I’m gonna bet that your users follow a bi-modal distribution.
One tranche is low-volume individuals who will have a hard time justifying $50/month.
Second tranche is companies for whom $50/month is a spit in the bucket and you should find a way to charge them $299 - $999 a month.
One way to do it is by having 2 tiers based on a metric like “daily active users” and have small price (or even free) for a low number of daily active users and a very large price for large number.
Thanks Dave! A question I should’ve asked in the first place, though: why is this better than just setting up my app as a PWA, given Chrome’s support for Desktop PWAs? (Assume the vast majority of my users are using Chrome, and the remainder could be convinced to use Chrome to install the desktop app if they really want it.)
Maybe you can swing $49/month as additional feature (i.e. $99 to create the app in the first place + optional $49/mo for auto-updates).
Yes, I’ve received this feedback a number of times and it’s definitely something I’m thinking about. I want to keep pricing simple but there’s a bit of a disconnect with the ongoing value that users think they’re getting.
The browsers technologies are not improving at such a fast rate that updating browser core will make a visible difference to most of your customers.
Possibly not a huge visible change but any legitimate business will want security vulnerabilities patched and updated pretty quickly. Also, you don’t want to be left supporting Chrome 72 (or some other arbitrary Chrome version) in three years time when literally 0% of your web users are using that version.
You should also think about differentiating pricing on volume.
Yes. Coming very soon. Like, a couple of weeks. Currently working on the backend for this.
why is this better than just setting up my app as a PWA
Yes, honestly that might make sense if you have service workers + web manifest set up correctly + your users are running Chrome and you meet the engagement metrics to be able to prompt for desktop PWA install. There are some specific customisations that ToDesktop has around app settings and window UI (min/max/default dimensions, start in fullscreen mode) but most users may not want to use these.
To be honest, it’s something I struggle with, if you have service workers + manifest in place then desktop PWAs might make sense.
One sub-product I’ve been thinking about is a desktop PWA polyfill. So, it would mean that you can just put a download button on your website and when it’s pressed it will try to install the PWA but if you don’t meet the engagement metrics or if your user isn’t using Chrome then it will fallback to a download of the Electron app.
Honestly, I do worry about Desktop PWAs as an alternative and I haven’t quite figured out how to frame ToDesktop in relation to them.
Yeah, I haven’t yet added a manifest and service worker to my app, but it honestly doesn’t look too hard and has the additional advantage of better RAM usage if Chrome is also running. Certainly worth giving a shot before committing to $49/month forever.
TBH I’m not sure how you could more strongly differentiate ToDesktop given where PWAs are right now. The zero engineering time is your best feature, but if an engineer can implement a PWA in an hour or two that pays for itself very quickly. Perhaps a change in your pricing structure to an up-front fee followed by much lower monthly charges linked to the number of active users?
I think you might as well throw it in with the main product, doesn’t hurt, but not sure how much value it has. Especially if/when the other browsers start supporting desktop PWAs as well, since the engagement bar seems pretty low.
