Sending myself emails as notes is the stickiest note taking app I've had in 20+ years of internetting.

If that feels unlikely, it's because it is. But we have very little way of knowing how this would play out in any other situation.

My point is we should all be less certain of the stories we tell.

Couple questions, if you don't mind taking the time:

1) What makes you want to use Redash, instead of a spreadsheet?

2) If you had a service that (securely) sync'd data into your spreadsheet, would that provide all of the value of Redashing it?

my experience: I felt like I was a Responsible Adult when I used it, but didn't actually budget any better.

I see a lot of times, people export to Excel to do their own analysis. I think there is something about doing it "my way" that helps me connect with the data, whether it's budgeting or (my current project) fantasy sports.

Specifically, what value do you get from exporting and creating your own graphs? How much time do you spend / how frustrating is it to have to export and build the graphs?

For $1k in spend and a day's work, they had a nice data point that tested TAM assumptions.

* Landing page is a template, figure 4-8 hours to put together the couple hundred words of content and configuring assets

* FB Spend = $509.23

* Estimate Google spend around the same (numbers not specified)

Namely, if you were to state to a higher level manager that you "don't trust Microsoft", you will come across as a crank. Or a developer who doesn't see the bigger picture.

To improve perception, folks should try to reframe their personal preferences ("I don't trust MS") as risks to the business - "I worry that MS will lock us in to their platform and jack up prices". The former is reputation-harming; the latter is being a savvy 2nd order thinker, who looks beyond just what the MS salesman says.

Specific models might be an interesting addon. Address parsing, normalization, and deduplication (with potential covariates like phone number, email address, etc.) is a massive pain in the ass for any data engineer who works with sales or marketing folks. Their databases (CRMs) are awful -- it was always a chore to clean these up, but measurably saved money (imagine you mail physical cards, and only want 1 per customer... but you have 5 different contacts at that company for 3 unique individuals).

I would have paid for a deduplication service -- say, quarterly batches at somewhere >$500/quarter for e.g. 20-50k contacts.

The 1-size-fits-all isn't really a value add for me, that wasn't so much my issue. For other target users, I can see that use -- for them, the interface is the value add. Especially if you can read/write Excel files directly.

Stop words aren't something I used in my deduplication efforts. How many of your users request or use this? What kind of stop words do you want to exclude from comparing two entries? I would be worried that stopwords still carry information: "The Store" versus "Store" might be significant.

What Microsoft sells is a "good enough" solution that speaks the right language for the decision makers. In turn, this makes their decision less risky while still satisficing the requirements.

My use case is a bit different -- I was doing a lot of database cleanups, particularly CRMs. I rewrote/reused code to build a duplicate detector a number of times; always wish there were a service that I could send data to, and it would flag my dupes. Even was using human labelers to train domain specific models.

Also reconsider your pricing model. Charging per user per month will place a limit on how many people use the service, limiting what you can learn. Get them focusing on the value you're adding more than optimizing price. What you learn from them will be hugely valuable.

At least, that's what it would take for me to join a startup as first engineer versus starting my own business.

My actual point is this type of discussion doesn't really add anything. It's difficult to prove, and prone to an extreme amount of bias combined with generalizing from a small sample.

Then work on refining, editing, deleting, modifying.

Separate the creation from the editing/communication.