Ask HN: I built it, nobody came, now what?

Here's some feedback after I unearthed your homepage:

You say users of the tool aren't on HN (which is a technology audience), yet your landing page is talking about technology and not the problem your solving. My guess is the audience for EXCEL are Business Analysts, admin staff, accountants, executives, etc. And not people in technical roles who'll get excited by the technology.

-------

You start off with some questions, but only one of them means anything to me:

"HAS YOUR BUSINESS AN EXCEL PROBLEM?" What is an excel problem? (Also, "DOES YOUR BUSINESS HAVE AN EXCEL PROBLEM?" reads better to me)

"DO YOU HAVE HUNDREDS OF UNMANAGED SHEETS RUNNING REPORTS?" This is the only question I can really answer.

"DO THEY TELL YOU IT WOULD TAKE TOO MUCH TIME TO REPLACE WITH PROPER APPS?" Who are "they"?

then you have:

"LIKE EXCEL, JIG IS A LIGHTWEIGHT SOLUTION TO CREATE DYNAMIC BUSINESS REPORTS AND APPS IN MINUTES. " This is fine

"UNLIKE EXCEL, JIG FILES ARE AUDITABLE, MAKING JIG APPS INHERENTLY SAFE. " What does safe and auditable in this context mean? What benefit does that give me? Surely the main benefit is the ergonomics and speed of accessing my data and safety and auditability are just side effects?

So, as someone who doesn't use Excel a whole lot, but I've seen businesses which run on very complicated excel spreadsheets without too much hassle, I'm struggling to see the problem.

As above, you talk about electron, and JavaScript, and auditability - which is fine for a technical audience, but if I'm a spreadsheet user I couldn't care less if it's built on Electron, or Flutter, or Qt, I just want to know how it helps me.

Would an excel user really care about a REPL (or even know what it is?) Or Version control, or the fact that something is or isn't on the cloud?

Surely the people who care about developer tooling would just be doing the visualisation in R or Python?

-------

I'm not saying there isn't a problem here, but perhaps you're not framing it the right way for the right audience?

Rather than asking vague questions, why not be pro-active and just give an answer.

Something like (and this is spitballing at 11:00pm on a Friday night so you know what the quality will be):

"Data is the lifeblood of businesses, yet you trust it to a glorified calculator. JIG re-imagines the spreadsheet, exposing data in new ways, ensuring you don't miss a thing."

Or: "30% of sales opportunities are lost because of incorrectly understood data, Jig exposes the trends for you so you'll never miss a deal."

Or: "Spreadsheets are complicated, they're messy and they're hard. Jig makes complicated spreadsheets quick and easy, giving you more time to focus on your business."

Or: "Excel buries data, JIG exposes it."

Or: "Excel was created in 1987, it was built for an simpler, less data-rich, era. JIG re-imagines the spreadsheet, with a focus on 2021 levels of data."

You get the picture.

Frame the problem, sell the solution, and instead of talking about the technology say how the technology helps.

Also, perhaps without customer testimonials find some case studies of times when excel has failed and what that failure cost. One that comes to mind, which is almost certainly too sensitive, is the contact tracing system in the UK that was built on excel. It failed when they ran out of rows causing hundreds of thousands of people to not be contacted about covid exposures. There will be tons of examples that aren't as life threatening that you can use to illustrate the benefits of Jig.

> the problem is that you want to work in your comfort zone, not Excel.

No, you shouldn't assume stuff when you write comments. My comfort zone is Excel. I've been writing Excel-based apps for 13 years, and from what I gathered, I am really good at it. I built this because I reached the limits of it. And I think that many other people have.

You think Javascript is my comfort zone? I loathe javascript. But at this stage, I truly think this is the best option.

> Your actual selling points then seem more like post-hoc rationalizations.

No they're not. Excel is unsafe not because of malicious files, but because people make mistakes all the time in excel. This is a straight consequence of how Excel was designed. There is a history of major financial fuck ups directly linked to excel mistakes.

Whether this tool is the solution remains to be seen. But that the problem exists there is no doubt.

In fact, all of these tool will allow you to download a CSV file for further processing in Excel. This is the part I want to compete with.

If that makes sense.

...and refreshingly so. You're getting rid of a social filter. People lie to your face all the time.

> No, you shouldn't assume stuff when you write comments.

You can't do anything without assumptions. I got an assumption wrong and you got offended? Not a problem for me, you're the one soliciting feedback after all.

> You think Javascript is my comfort zone? I loathe javascript. But at this stage, I truly think this is the best option.

Yes, everyone's out there hating on Javascript and shipping Electron apps at the same time. That doesn't necessarily negate my point. As you say, you built it for yourself first. You had ideas on how you want to do things. Those ideas inevitably conflict with how other programmers want to do things. There's a reason why there's a hundred Javascript frontend frameworks still coming out every month, even though we already have React as the de-facto standard. Getting traction in such a domain is incredibly difficult.

> No they're not. Excel is unsafe not because of malicious files, but because people make mistakes all the time in excel.

If that's what you mean, here's your N=1 statistic saying "people don't get your message".

> This is a straight consequence of how Excel was designed. There is a history of major financial fuck ups directly linked to excel mistakes.

There's a history of major fuck ups in ordinary programming languages as well. It's not obvious how your solution might prevent such mistakes, especially without introducing a whole class of new mistakes.

That's not true at all. It's just a different query language to yours and a different methodology to utilizing it. All the big BI and SIEM tools have post-processing capabilities able to do statistics at the Excel level, typically by creating new columns in the dataset. PowerBI has an excel-like function system for calculated columns. Tableau has a cross between Basic and Excel functions for calculated columns. Splunk and ELK are the standouts for letting you directly modify columns in their query languages, but the same sort of functions exist. In all of these tools, you can extend the query language as well through a plugin system, so for situations where you need a full programming language, there is an escape hatch (though a hard one to use).

> further processing in Excel. This is the part I want to compete with.

If you want to compete with Excel, you're going to have to get on its level. Specifically, the JavaScript must go. The reason big companies use Excel is because they have a couple of people at the company in the reporting jobs that can handle some programming, but most of the data entry and management has to be done by people who wouldn't know where to begin if you sat them down in a programming environment (IT gets called when people accidentally end up in the visual basic environment in Excel).

The majority of users do not want to live in a programming environment, so by having that be the primary interface, you're cutting the already small potential user base by another order of magnitude with the JavaScript environment. The advantage you get for an Excel-like query language is familiarity to the potential user base, less threatening environment, and additional control over the interface with the user (programming languages are generally poor interfaces, and JavaScript is no exception).