5 ms·

Launch HN: Navattic (YC W21) – Shareable demos for selling your SaaS product

64 points by nrmclean 6y ago

Hi HN! Neil, Chris, and Randy here, co-founders of Navattic (https://navattic.com/ https://navattic.com/). We help you create better product demos to sell your SaaS application. With our software, you can create a shareable copy of your application, add guided tours, and send it out via a distinct link. 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/ 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!

frazmand 6y ago
[Nickelled](https://www.nickelled.com https://www.nickelled.com) have been doing this for years :)
seism 6y ago
Cool! Bit out of my budget, but I can see this solving a pain point. I wonder what happens once the demo'ed app invokes canvas, WebGL or its own extensions?
- choyle 6y ago
  We've taken different approaches to this in the past. Through serializing all network requests (from js bundles to api requests), you can reassemble an application on the client in the same way that it would typically appear. This allows you to use any browser tech like canvas / WebGL as normal. From a DOM serializing perspective, although less interactive, you can convert canvas elements into static images (.toDataURL()). This has proved to be good enough for most use cases so far, but we're continuing to experiment with new methods!
raunak 6y ago
Why have teams create a replication of their app, rather than have your product work off of a dummy data version or even a static version of the team's app? I'm not sure I understand the 2 reasons provided - "overwriting data in the environment" and "juggling access credentials"? I love the website design, btw!
- choyle 6y ago
  Good questions. Chris here. Before learning about the space through user interviews (and from Neil and Randy), I had the same thoughts! 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.

64 points by nrmclean 6y ago

frazmand 6y ago

[Nickelled](https://www.nickelled.com https://www.nickelled.com) have been doing this for years :)

seism 6y ago

Cool! Bit out of my budget, but I can see this solving a pain point. I wonder what happens once the demo'ed app invokes canvas, WebGL or its own extensions?

choyle 6y ago
We've taken different approaches to this in the past. Through serializing all network requests (from js bundles to api requests), you can reassemble an application on the client in the same way that it would typically appear. This allows you to use any browser tech like canvas / WebGL as normal. From a DOM serializing perspective, although less interactive, you can convert canvas elements into static images (.toDataURL()). This has proved to be good enough for most use cases so far, but we're continuing to experiment with new methods!

raunak 6y ago

Why have teams create a replication of their app, rather than have your product work off of a dummy data version or even a static version of the team's app? I'm not sure I understand the 2 reasons provided - "overwriting data in the environment" and "juggling access credentials"? I love the website design, btw!

choyle 6y ago
Good questions. Chris here. Before learning about the space through user interviews (and from Neil and Randy), I had the same thoughts! 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.