Onboarding new data sources with sample data

The Challenge

At Hasura, we faced a critical challenge in new user engagement.
Our data revealed a concerning trend: many users had fewer than five tables in their managed, Cloud-hosted projects.

This wasn't particularly surprising because our ideal customer profile (ICP) consisted of larger customers who bring their own data.
However, we couldn't ignore the importance of these independent developers, checking out the platform for their first-time experience.

The bottom-up approach had been crucial for our growth.
Converting these new users into active users was vital for our long-term success.
Demonstrating to them development experience and velocity we could provide could help them become advocates within their organizations.

Exploration

We dove deep into the user experience, determined to uncover the secret sauce that would make Hasura's potential crystal clear to newcomers.

After some brain-storming and data crunching, we identified four key ingredients for our perfect onboarding recipe:

1. A sample dataset to sink their teeth into (for the "blank-slate" problem).
2. A web of relationships between tables and objects, showcasing Hasura's (and GraphQL's) mapping magic.
3. Database functions that could be exposed through the API, demonstrating Hasura's flexibility with ad-hoc logic.
4. A comprehensive permissions system, highlighting Hasura's robust security features (always a first question when interviewing users).

These elements weren't just checkboxes - they were the building blocks of the "aha!" moment we wanted every user to experience.

By combining these components, we aimed to create a powerful first impression that would leave users eager to explore more, or reach for Hasura in their next project.

Solution

Armed with our insights, we crafted a solution: a turbocharged quick-start path the user could take.

Here's how it works:

1. With a simple click or two, users connect their data source.
2. Our system then springs into action, allowing the user to select from a curated set of "features" they'd like to implemebt.
3. We'd then inject a set of metadata - essentially an instruction set for how Hasura should operate.
4. Simultaneously, we'd execute a SQL migration and insert the user's seed data - setting up a rich sample dataset in seconds.

The result? A fully functional Hasura platform, ready to roll with an example "feature" implemented for the user.

This wasn't just a time-saver; it was a quite the leap ahead for user onboarding.
What typically took hours coding for developers to setup without Hasura for was now accomplished in seconds.

Users could instantly experience a working "feature," complete with sample data and the bells and whistles of Hasura's capabilities.

It was like handing users the keys to a fully-furnished house instead of an empty lot.
They could walk in and immediately start exploring the possibilities - no construction required.

You can check out the initial templates we created over on the project's GitHub page.

Expand

Expand

Implementation and Initial Success

Expand

We launched the first version of this feature at HasuraCon.
The reception was positive, with decent traction at launch.
It successfully helped demonstrate Hasura's ecosystem to new users and facilitated the onboarding process.

Looking ahead, we envisioned creating an ecosystem of small, installable applets for new users.
We also saw potential for teams to use this method for sharing snippets or packages within their organizations.

Deprecation & Future Direction

Despite its initial success, the feature faced some hurdles over time:

1. Technical limitations:

   • We only had database migrations and ad-hoc query execution for a couple of data sources.
   • Splicing in metadata required significant maintenance to ensure resilience as we made changes to other systems.

2. ICP misalignment:

   • The feature didn't quite align with our target users who had large existing datasets.
   • Our ICP included customers with several data sources of different types - the limitations around execution made this first-time onboarding flow, while good for independent developers (specifically those using Postgres or MSSQL), not as suitable for customers based in other sources.

Due to these challenges, we eventually decided to deprecate the feature.

The learnings from this project weren't in vain though:

1. We repurposed our insights to our next initiative: Deploy from GitHub.
   • This new project built upon the successes and addressed the challenges we faced with the sample data onboarding features and is still in production today.
2. We also crafted a new onboarding flow to help guide users to start adding their existing data to their API (which was closer to our ICP's happy-path and variable data sources).