Launch HN: Navattic (YC W21) – Shareable demos for selling your SaaS product
Regardless of how you feel about Oracle, they're masters of the enterprise sales process, yet we were sales engineers there and even we were struggling to demo SaaS products to customers effectively. Day in and out we delivered product demos to prospects, but we didn’t have a great response when the prospect wanted to get hands on with the product. We then hit the phones and spoke to 200+ SaaS companies and learned that this is a widespread problem. Typically, SaaS companies are limited to the following options: share an unguided sandbox that requires setup and training, provide a trial (which isn’t feasible for many integration-heavy products), or send over a video or slide deck.
We looped in a college friend, Chris, as our third co-founder and while we were co-quarantined in Colorado, hacked together an MVP of our sharable demo platform. Our objective was to turn anything that runs in the browser into a deterministic, replayable web app that performs as close to the real experience as possible. We explored this from multiple technical fronts, including: A) serializing network requests by developing basically a cache.match() with fuzzy matching on the edge, B) serializing the DOM state by hacking CSS, patching Web APIs, inlining values, etc. We were lucky enough to get some amazing early customers who were patient with us during this early experimental phase. In the end, we are happy with our approach that balances ease of creation, broad application support, and maintains the integrity of the application’s experience. We allow any non-technical person to create these shareable demos in a matter of minutes through a Chrome extension and our web app.
With this method, teams can create a replication of their app that looks and feels like the real thing, but can easily be shared with prospects without worrying about overwriting data in the environment or juggling access credentials. Because our solution relies on serializing the DOM state, it is framework and language agnostic and can be implemented without involving engineering teams.
We also added tools like guides and user analytics to allow teams to create step-by-step walkthroughs within the app and track user engagement with the tour. So far we’re seeing these interactive product demos shared as a followup after a live product demo, embedded on their marketing site or sent in outbound messaging. We’ve seen some promising early results with customers reporting a 4x increase in booked meetings when including interactive demos in their outbound emails.
If you want to see how it looks for a generic product, check out https://demo.navattic.com/, and if you want to try it out on your own product, start here: www.navattic.com/onboard/plan.
We would like your feedback on all of the above, are happy to answer questions, and look forward to hearing about your experiences and ideas. We’ll be hanging around in the comments - fire away HN!
37 comments
[ 4.4 ms ] story [ 86.0 ms ] threadI love the website design, btw!
For companies that want to build this internally, there's a couple of things to think of from an engineering perspective. A) Restore state: If users can manipulate data in the app, is there a "restore state" so that they don't modify the same data for other visitors. B) Privileges: you probably want special, more-restrictive privileges for users just experiencing a demo and not setting up a typical user account.
So you are correct, that setting up a static version of a team's app could solve these problems and that's exactly what we help facilitate! It's a trickier problem to implement internally than you might initially think (imagine calling "indeterministic" web APIs like Date.now() for a time-series chart or Math.random() for uuids.) Through our customer interviews, we found that it's difficult to win the engineering team's time for such a task.
Our no-code editor also allows you to update the overlays dynamically and easily update the (now) static demo to keep it up-to-date with your application.
In addition to the benefits you mentioned, this also makes your interactive demos accessible with screen readers and other assistive technologies, or at least as accessible as the apps themselves. That makes them better than demo videos.
I also got a good laugh out of the fact that "Improve site accessibility" is one of the sample tasks in your meta-demo. Indeed, the popup dialog, which prompted me for my email and name, should be marked up as an ARIA dialog. I haven't checked out the actual Navattic app, so I don't know yet what accessibility improvements might be needed there.
1. Have you considered making the guided-tour functionality available for developers to integrate into the live app? That way applications can guide the user through the process of getting started with real data in their real account.
2. What about applications that have different UI entry points for different kinds of users? Can you do a guided tour where the user starts at entry point A, goes through a couple of screens, then switches to entry point B and sees what that side of the app is like? Maybe we can get into more specifics privately; I don't want to make this thread about _my_ product.
3. Do you support dynamic, server-initiated page updates, e.g. sent via a WebSocket in the real app?
2. Yes. You can accomplish this by triggering guides to appear on pages matching certain patterns (such as url). You can also use guides to link between each other.
3. If that update results in an update to the UI, then it can be captured with DOM serialization.
This is sorely needed. Based on the problem alone, of all the companies I've seen in the W21 batch, this is where I'd place my bets.
Good luck!
I'm curious about your pricing. $700/month looks like the right balance between weeding out the tiny/expensive to support customers and not constraining your market too much.
How'd you land on a seat-based model? This feels to me like the kind of thing that, even in a company with a 100+ person engineering team, might be worked on by just one or two people, probably in Sales Engineering. Maybe one other person to handle the analytics side. Are you thinking that in larger companies, people from multiple product teams would do the demo for their portion of the product?
I don't have a better answer, but this is the kind of thing whose pricing should track relative to customer revenue. The more deals they close (bc of Navattic, presumably), the more you should charge.
I'm sure you've thought about this quite a bit. Interested to learn what your thinking is, if you care to share.
I'm using FireFox 86.0 on MacOS 11.2 (Apple M1 chip).
FYI, I would pay for this, but $8,400/yr. is a killer for a startup. You're leaving what might be a lot money on the table at the bottom that you could scoop up with graduated pricing. This might also protect you from competitors, because if you leave the low end open, you may get eaten by a copycat offering cheap/freemium. For example, Github vs. Gitlab and Mailchimp(freemium) vs. Constant Contact.
You've made something very cool that I think people will want, and this price point won't be crazy for enterprise folks. Great work!
I did immediately think to myself that this was a needed product when I saw.
We are actually working on a SaaS launch right now of a pretty bog-standard app. I was actually sold and ready to use Navattic from the landing page, but I was expecting a pricing model like Cypress.io, so I got some serious sticker shock. I feel your product is 80% of what we need, but we can get to 70% of what we need by just saving a few HTML pages and then using an off-the-shelf open source tour JS script (which is what we did in one case last week, and it took all of like 10 minutes). If we want a 100% interactive experience, it would again be just slightly more dev effort to create a new tenant in our demo database and sending the prospect an onboarding link, then just watching our existing analytics for usage. I guess this is all to say, I'd be okay with paying "pocket change" for a convenient platform with analytics for the same reason I like Cypress -- sure, I can set up an E2E dashboard with off-the-shelf FOSS libraries, but Cypress is more convenient at a reasonable cost -- but not $8k per year.
That said, I could see products with very broken multi-tenancy AND no automated provisioning finding this useful (and with deep pockets). I just wonder if are enough of these to be sustainable, since not only would they have to be broken in this way, but also the "fix" to multi-tenancy or automated provisioning would have to be a worse ROI, since these are typically already on "product roadmaps" anyway. Just my two cents, and I understand you might still be iterating on pricing. Regardless, a really cool product, congrats on the launch!
Off-topic: did you use a framework for the demo app? It's very nice looking!
We used Windmill Dashboard React (https://github.com/estevanmaito/windmill-dashboard-react) to create the sample app!