Launch HN: Explo (YC W20) – Customer-facing dashboards and reports
explo.co
explo.co
Our product currently isn’t self-serve, but https://www.loom.com/share/fd63361f850d44f68cd395a552f5548d is a quick video walking through how to build dashboards. Feel free to take a look at a few examples of our embedded dashboards here as well: https://www.explo.co/gallery.
We applied to YC with an idea in the restaurant space (we knew nothing about restaurants), but quickly pivoted to build a tool that allowed you to analyze data directly in your database or data warehouse without knowing SQL. As former data analysts and engineers, we spent hours diving into databases to understand data and conduct analyses, so we wanted to speed up this process. Our early customers used Explo to analyze data by creating charts and graphs. They then wanted to share their visualizations, so we built dashboards, and then they wanted to share these dashboards with their customers. In fact, we first discounted the request as we wanted to focus on internal analytics. But as we continued to work with our customers, we learned that B2B companies were getting more and more requests to share data with their clients. For example, a construction tech platform we were working with wanted an easy way to surface customer data on purchase orders and contracting costs directly from their database securely and directly within their product. A virtual events platform needed to share stats on registrations, attendance, engagement times, for event admins after each event they hosted.
These companies want a snazzy dashboard in their application, but that usually requires a dedicated engineer weeks or months to build along with ongoing maintenance costs. They also don’t use BI tools such as Looker, Tableau, or Metabase because they are either not great for embedded applications, or too heavy for this use case. Instead, they settle for sending CSVs over email, taking screenshots of internal analytics tools, and uploading pictures to shared drives.
After learning about the various pains in sharing data with customers, we decided to pivot and build Explo. We saw that sharing data with customers was becoming increasingly important, and the external analytics space was much more greenfield than the internal space. Our goal is to be the easiest and cheapest way for companies to create dashboards that can be embedded directly into their application.
Our current platform connects directly to SQL databases and warehouses. We don't copy, cache, or manage any data. This makes security much easier to negotiate and allows us to offer a plug-and-play solution that's easy to stand up. We provide a SQL editor and dynamic parameters that you can inject into your SQL queries so that our users can transform and manipulate data before it renders into charts and tables. We've seen our customers use these temporary transforms as a template for future data pipelines so that the heavy lifting is done ahead of time. We work with companies with a variety of data infra setups from startups who create a read replica of their production database that we connect to directly, to companies that have a dedicated Snowflake warehouse with multiple data pipelines and clean data model built out.
As part of building out our product, we’ve had to tackle some pretty interesting and essential technical challenges. We created a SQL builder that can generate SQL across every major database and data warehouse. We implemented a git-like version control system for our no-code tool so that the embedded solutions could be versioned just like code. We’ve had to put our networking hats on to programmatically connect to very secure databases through firewalls and SSH servers.
We have a lot of ideas as to where Explo will go beyond a dashboard platform to enable our clients to share data better and we’re excited to hear your thoughts on the topic. How do you currently share data with customers, have you built out dashboards for customers before, or used embedded analytics solutions such as GoodData, Looker, or Tableau? We’d love your feedback and to learn more about your own experiences sharing data!
That's my two cents.
To your point, we have already had a few customers that display their dashboards on mobile web apps and have had a few native applications want to use us.
Just to add another recommendation to the mix. I'm an extremely happy echarts user. I recently had somebody comment about the graph that was in my product as they were surprised by how it was done, which goes to show how flexible and powerful echarts is.
If you go to https://public-001.gitsense.com/insights/github/repos?r=gith... and look at the timeline chart, you can see that it is pretty flexible. I was able to convert a scatter chart into the timeline chart which supports scrolling left and right fairly easily.
---
What would be cool is dynamic dashboards that are launched via QR codes. I am specifically thinking about the cannabis industry:
A few years ago, I was making cannabis labels - which are regulated as to what information you must have on the label, and what I did was a QR code that went to a bit.ly link that then directed to the lab results for the cannabis as it was tested.
This allowed for me to scan a QR on a package, be taken to the lab results and also have interest tracked to the product by just counting who and what was scanned - where and when...
The point is, that it would be interesting to have a QR generated for every dashboard such that if I put a product dashboard up, and printed the QR on whatever product, I could then be taken to that board with a scan of said QR.
This would allow for IRL metrics to physical products and track how many scans happen... and a QR could refer to a custom board based on a variety of inputs...
Every part of what you described other than the actual QR code generation is possible today! For each user input in the dashboard, URL parameters can be defined to default the input to a specific value on page load.
Your point around using the Explo dashboard to show more information is super relevant to one of the longer term ways that we are thinking about our product. Rather than just typical "dashboards", what we've built with Explo is a way to create user interfaces that share and communicate data. And we want to take it a step further since we've realized that a lot of web development and user interfaces is really just visualizing and communicating data.
We sort of do the same thing with QR codes in a factory at the moment where we trace production batches, stock management and R&D test data to link the label factory items back to the MRP data and dashboards. This was implemented using Lowdefy [0] - interestingly we also started Lowdefy out of the need for customer facing dashboards and have since widened the scope into a range of other things aswell.
This is a really cool use case! Especially with for environmental and ethical conscious brands.
We sort of do the same thing with QR codes in a factory at the moment where we trace production batches, stock management and R&D test data to link the label factory items back to the MRP data and dashboards. This was implemented using Lowdefy [0] - interestingly we also started Lowdefy out of the need for customer facing dashboards and have since widened the scope into a range of other things aswell.
Explo looks really cool! Congrats on the launch. I would love to see some videos on creating dashboards especially filters etc.
And is your data pulled directly from your MRP system or loaded into another database first?
And we'll definitely be adding more examples and videos creating and embedding dashboards in Explo.
We usually deal with less than 100k records, scaling has mostly not been an issue for us, and in such cases we can run the analytic aggregations directly on the MRP read replica [0]
We built Lowdefy so that we can build better, more flexible, quality apps faster for customers. Then decided to OS it.
Lowdefy is designed to work any number of connections, so we'll be adding as we grow. Also, we prefer to not add a "thin" connection, but rather build out a well scoped and tested connection - this can be tricky, not sure of this is the best approach ito marketing as we have an extensive list of connection requests we would like to get to [1]. We'll start to prioritise these more in the near future. We'll also finalise module federation for connections, which will enable custom connections.
[0] - https://docs.mongodb.com/manual/core/read-preference/#std-la...
In general we don't charge for # of dashboards or even traffic to the dashboards. We charge based on the # of end customer groups you are presenting dashboards to. This has been the most aligned with our customers since you can use the full power of the tool and only pay more as your own business scales up.
We work with our clients on how the pricing scales up since some customers have very few end customer groups with tons of usage, whereas some customers have tens of thousands of end customer groups by virtue of being more consumer facing.
Let me know if you have more specific questions about pricing!
would make an excellent entry in a FAQ on the site. Likely would help qualify leads as well.
(I don't have any issue with the pricing, but would also not reach out given no pricing typically means "really expensive".)
There was a great thread recently on developer marketing here: https://twitter.com/nickwritesit/status/1402318187299934212?...
You should post again here and on producthunt when there’s self-serve signup and live demos.
The videos look good!
We are definitely hoping to launch self serve in the near future but have decided not to while we iterate on the core features and ensure things work with a qualified and controlled set of customers. However, it is helpful to understand how important self serve is to developers.
We are definitely hoping to launch self serve in the near future but have decided not to while we iterate on the core features and ensure things work with a qualified and controlled set of customers. However, it is helpful to understand how important self serve is to developers.
Adding in monitoring and alerts is something we are working on and has been requested previously. With regards to monitoring your system status specifically, we would likely need to investigate a means to connect Explo to where this data is generated or being collected. Explo would need to query this source on a certain cadence (probably pretty frequently) to have high fidelity monitoring. Currently we pull the data via queries and data isn't pushed to us (doesn't make sense in the current model, but is something we've chatted internally about).
Would love to chat more about the push model to better understand how Explo can plug into your system status. Is there a way that we could connect to the system status and pull the necessary information? Or can you push the system status data somewhere that we can then process?
Well that may be convenient for you but since these dashboards are external, does scalability become the responsibility of your customers? I can’t imagine thousands of users all hammering expensive analytical queries on a single unoptimized replica will scale very well.
We also refer customers to services or contractors who help them set up a their data infra to fit their needs as it's not the core focus of our product.
We have also thought about implementing a caching layer to improve performance, although that adds a few hurdles regarding data privacy and pulling live data.
Please kill those progress spinners, the app is only rendering little bits of 2d art. Count each one as an individual statement of "you asked me for something but I haven't done my job yet, and now I'll make you pay for my laziness, and I promise if you click anything I'm just going to show you a million more progress spinners because I hate you and don't value your time"
Also please don't shoot the messenger, spinners were briefly an acceptable UI cue sometime around 2 decades ago, nobody honestly likes seeing them any more. If you explicitly design an app UI around the expectation of delays, it gives endless room to cut corners and add more delays. In other words it is optimizing the whole user experience for intentional mediocrity.
I am curious your thoughts on a better way to approach this. My initial thought is for a single loading state which ends when all the data is ready to display on the page. It feels inevitable that there is some loading moment when we are fetching the data. It sounds like, based on your comment, that you would prefer there to be no loading state thought?
Precompute whatever you can I guess, but I'm guessing the app has parameterized queries and stuff like that which are hard to precompute. In that case even a cache or LRU list is fine, say precomputing the handful of most common views people will encounter most often.
Imagine even if only Jira's new ticket page and 'open tickets' search result were pre-rendered so loading them took <200ms. The amount of hate would probably drop by 90%
Separately if you can reduce the workflow for a page from being a task in its own right (most of which is waiting around) to something as simple as a click, it can increase user confidence a lot. If something that took 5 seconds (+4 of which is just waiting) suddenly completes in 200/300ms, folk learn new tricks for your tool, like middle-clicking open a bunch of screens, or noticing they can open and close it much more easily. It makes the whole experience feel more agile, which definitely has an effect on loyalty
In the example dashboards, I'm guessing something like 100% of requests make exactly the same queries. Maybe in a typical corporate dashboard, 70% of users will pull up the default view before leaving. These cases easy to optimize for and definitely worth optimizing for
If I owned the database they were getting data from, I'd be mighty upset at the insane amount of useless queries they'd have to make guessing what the user wants.
We only did this because of the extreme value Google brings via traffic. But most crawlers and other things that made speculative queries like that were just banned.
Got an automatic email to (1) fill out typeform, (2) book via Calendly.
I did (1) and (2).
Did not get any Calendly notifications / invitations. Nothing in junk either.
Six hours later got another (same) email as email 1.
Did book via Calendly again. Still no notifications of the booking.
Gave up.
1. I see that startups pay $500/month. How do you compare that to Metabase which is $85/month (or $385 if you remove the Metabase attribution)?
2. Do you, or do you plan to, offer the ability to embed individual charts instead of whole dashboards?
3. Do you support custom chart creation via python/R?
4. Do you think Explo is a fit for our use case or a different tool: we're experts at SQL, good with Python, and looking to rapidly create and embed customer facing charts?
1. We have a few customers who have switched over from Metabase for a few different reasons. The main ones are that we offer much more extensive UI components, more chart capabilities, better security guarantees, and highly customizable styles. While $500 is more than Metabase's price point, we believe that an embedded first solution is worth the price since it will save you 10-20x the cost per month on development and maintenance costs.
2. Yes! A dashboard is just a collection of one or more charts/UI elements and so if you make a "dashboard" which is just a single chart, you can easily embed that. We have many customers who have this use case to embed analytics granularly throughout their app.
3. Not currently, though I'd love to understand more about how/why you would want that. We've heard this a few times as a "nice to have" but would love to build it out with a customer that really needs it.
4. It sounds like you'd be a great customer for Explo! It takes all of the hard work of building out user interfaces out of the equation and makes it so that you just need to specify data queries with SQL and then use our drag and drop interface for UI building.
It is impressive the number of databases you support, especially enterprise ones. I still can't use it without more clarity about pricing and usage.
We work with our clients on how the pricing scales up since some customers have very few end customer groups with tons of usage, whereas some customers have tens of thousands of end customer groups by virtue of being more consumer facing.
Let me know if you have more specific questions about pricing!
Having said that, I look forward seeing what you will do in next year or two.
says every developer until burning 100x cost/resources/time building a lesser version of the same thing that has to be now documented, supported and maintained.
From what I know (especially for big corps) $6k annual contract value ($500p/m) can usually be put on a credit card without triggering any lengthy enterprise 6-18 months sales cycles.
One feature that's important to us is the ability to download tables as CSV. Sometimes those tables will be really large, so we'd want to paginate them but still allow the customer to download all the data in their csv. Is that something you can/will support?
We already support CSV downloads from tables, so no worries there. We're excited to chat with your engineer and give them an in depth tour of Explo. Please have them reach out to founders@ or sign up for a demo on our landing page!
Very off topic, but feels like there's an interesting story here! Can you elaborate?
For consumers, this would be a curated recipe platform with recipes from the best chefs as oppose to random users. For chefs and restaurant owners, this would give them an outlet to publish recipes and promote their work without the need to sign book deals and contracts that are often very unfavorable (unless you're already a celebrity chef).
We tried pitching various iterations of this idea to get restaurants onboard, but unfortunately we weren't able to sell them a platform that didn't immediately boost sales.
Also curious to know how you would differentiate your offering from say retool or other low-code builders which also support multiple databases and have chart components?
I am assuming that with screen rights, a company can expose a dashboard built using retool to their customers as well.
Retool is a great example of a tool that we feel is adjacent to us but different specifically because it is not built to be customer facing. You can expose a retool dashboard but it isn't built to be embedded natively into your web app and there is no way to customize the styles to fit your app.
Additionally, our charts, visualizations, and data representations are much more catered to application dashboards - whereas retool has generic charting components in a more raw form.
What setup are you using that makes quicksight work well when embedded?
Quicksight’s embedding story is worse than tableau’s. And tableau isn’t that great with embedding either.
We allow users to customize the design of their dashboards using CSS and Markdown, and have design elements such as containers to group analyses together. We found that users were hesitant to embed Tableau, Quicksight, or other BI dashboards because they didn't fit into their application.
Also, Quicksight and a number of other tools require you to define a data model, create analyses, and then add them to dashboards. Our platform is oriented around the dashboard, so you write SQL, create visualizations, and design dashboards all in the same view. This gives users a lot of flexibility when creating dashboards and also speed up the time to implementation.
There are SDKs and major framework support.
For me that’s already great. :)