Chart.io was too expensive and we bailed on it, but not before we tried to negotiate a discount to no avail. Chart.io pricing model would benefit from more flexibility and options.

As someone who sells a product in a similar price range, your point is understandable but quite difficult to cater to from a vendor's perspective. Both Chartio and our product involve spending some time with the customer up front in order to really make it work for them. A lower price point plus monthly contracts plus churn as a result of finicky customers is the mark of death for SaaS startups.

The problem is one size company fits all pricing. Small business who can benefit the most from SAAS (and have the least regulatory/bureaucratic resistance) can't justify enterprise or middle-market pricing. And the valuation/exit strategy for most SAAS offerings is quantity of users, not profitability - like it or not. I predict either Chart.io changes pricing or its market share is eroded by FOSS and cheaper alternatives like: http://idl.cs.washington.edu/projects/lyra/

> And the valuation/exit strategy for most SAAS offerings is quantity of users, not profitability - like it or not.

That's not true at all.

SaaS companies are valued on recurring revenue, lifetime value, retention and future cash flow. Number of users is almost irrelevant as long as those metrics are moving up and to the right to a healthy degree.

Chart.io has already changed their pricing once and I share your prediction that they will change it again: to charge even more. And grow further as a result.

SMBs are a tough market for SaaS companies with a product that has any complexity whatsoever, both in terms of usage and distribution.

Lets meet again in a year. SAAS is a falling knife. I bet 20 Satoshi on it.

Been at it for 4 years already and SaaS wasn't always this hot.

Edit: what exactly are you wagering on?

Does Chartkick (highcharts) and other open source libraries not support your use cases?!

That's because it's targeted at the Enterprise, where it's not uncommon to pay $100-$200k in yearly licensing for comparable software.

The point is, there's obviously demand for this from companies that won't pay thousands/month for it, so it's a question of who will build it for them.

That doesn't make it right.

How does that make it wrong? Obviously people are willing to pay that much for those solutions, otherwise they would lower their prices.

If you're in the GNU/free software camp, it's wrong to charge for closed-source software. Perhaps that's what your OP ment?

I am working on a similar product Viur http://www.viur.pt with a very flexible pricing targeted to startups, small and mid-size businesses. Our private beta is going live for our subscribers in the next few weeks.

I'm currently working on a similar (hopefully more simple and cheaper) product MetricBoard (direct demo: https://metricboard.io/webui/demo)

Although this currently only let's you push metrics via the API or upload a CSV. I personally would not be comfortable having a 3th party connecting directly to my database.

The product is still in development but I would love to get some first feedback / user testing.

Upon second look I believe I misunderstood the purpose of the project.

I initially thought the project was a subtitute for chart.io. However, it seems like the project is about "collect and visualize data".

It is not to visual data by connecting to your own database. Rather it allows you to import data from an mysql database

In case this is helpful: I interned at a company, Polychart, where we built a product similar to chart.io that is now open source and can be self-hosted: https://www.polychart.com/

Looks neat. However it appears to actually only support MySQL, despite it's website's claims

Maybe we need to help them get wider support then.

Looks really interesting. Have you got any idea why they open sourced it?

Thanks. Just what I needed.

You didn't mistunderstand the purpose (However it's not an explicit goal of FnordMetric to substitute chart.io)

Here is an example that connects to a MySQL database on localhost: https://github.com/paulasmuth/fnordmetric/blob/master/fnordm...

Note that the IMPORT statement might be a bit misleading. The IMPORT statement only creates a "virtual table", it doesn't actually copy any data. As much of the query as possible is pushed down into MySQL/the external data source and the charts will be generated from the query result that is returned by the external data source.

A "deploy to GCE" button is something I am planning to add in the next weeks.

It's generally not very difficult to get SQL query results in JSON rather than tabular format and then feed that to your favorite charting tools.

However that means you have to write a heap of reptitive glue code (or sed incantations if that's your thing) to mangle your SQL Results into the JSON format your charting tool wants. If you run a lot of ad-hoc queries you have to waste a significant amount of time on this boring legwork that could much better be spent on interesting tasks.

FnordMetric aims to fix that by extending standard SQL; it allows you to express the data query and the chart specification in a coherent fashion (SQL).