The website is just a blog that I put up in a hurry so I have a place to do some blogging. I didn't spend a lot of time on it yet. It's definitely not the 'final' website (and obviously, it's a bit unfocused).
So, solving a problem for a customer of “self” is certainly a way of going about things, but one that I worry myself carries immense risk if you ever wish to sell the solution.
I have found that it is important not to be afraid of doing market research, surveys, conducting interviews or observations of existing people in action with existing solutions.
If you want to scratch your own itch, that’s cool. And it can work to produce a nice tight product, maybe could in this case.
But if I wanted to sell my product, I’d try to figure out if there is enough statistical significance in the market response before building it. Even just putting out and marketing an RSVP landing page for the tool, to see how many people might want it - you might get a load of potential customers who sign up and can give you feedback.
Since you’ve already decided to build this anyway, you aren’t concerned about competition - so what do you have to lose from seeing if other people want it? [1]
[1] Note - I do know that sometimes you don’t want to deal with other people’s opinions while building a product, and the author’s approach certainly is one way to go about it. Also, I guess accounting is a pretty well-known niche so a lot of the knowledge is already out there, maybe you don’t need much new input. But I felt a hypothesis here that could be tested and would be reinforcing if proven true.
EDIT: I see from the website the author is taking early access adopters, so maybe they are doing this. Actually I like the approach of doing this in the open and blogging about it, it was more the original blog post that triggered my reaction.
> I have found that it is important not to be afraid of doing market research, surveys, conducting interviews or observations of existing people in action with existing solutions.
Don't disagree, but I wanted to build something first, even if it's just proof-of-concept.
But now that I have a prototype, yes, I'm reaching out to get opinions. Blogging is part of that effort.
(Personally, I don't really like the idea of putting up a landing page to collect email addresses for 'vapourware'. When I say 'personally', I'm not passing judgement on people who do it. Just that ... I sort-of don't like doing it myself.)
> Since you’ve already decided to build this anyway, you aren’t concerned about competition - so what do you have to lose from seeing if other people want it? [1]
Agree. This is part of the effort of putting it out there and seeing what sticks.
> I see from the website the author is taking early access adopters, so maybe they are doing this. Actually I like the approach of doing this in the open and blogging about it, it was more the original blog post that triggered my reaction.
I like that approach (probably because I decided to use a similar one for my potential future SW, hehe).
Just to confirm, the concept is basically...
"I'll create the software X to fit my own specific requirements/needs, then I'll see if anybody else wants to use it as well (which would mean that that niche of people have the same needs/requirements), and if that's the case then I can decide if to put more energe/effort/$ into it otherwise it will just be something useful for myself"
..., right?
I think that for that to work the important detail about the concept&implementation is that the SW must be complete (~no critical bugs, all needed functionality is available) + not reliant on any external dependencies (e.g. hosting, downloads of data like Tax rates from anywhere, etc) + must use proven and stable technologies.
A stupid example would be "Tiddlywiki" (https://tiddlywiki.com): I downloaded the html/js-file (proven & stable & compatible with all browsers) and it works with 0 external dependencies => I can be sure that I won't loose my notes whatever happens and that the full functionality will be always available, even if in the worst case I don't have an Internet-connection.
Btw., the GigoBooks app does not currently allow to save data, or did I overlook some menu-entry?
> "I'll create the software X to fit my own specific requirements/needs, then I'll see if anybody else wants to use it as well (which would mean that that niche of people have the same needs/requirements), and if that's the case then I can decide if to put more energe/effort/$ into it otherwise it will just be something useful for myself"
>
> ..., right?
At a high level, yes.
(At a lower level, well, there will be variations on the same basic idea. The devil is in the detail.)
> I think that for that to work the important detail about the concept&implementation is that the SW must be complete
> ...
> and that the full functionality will be always available, even if in the worst case I don't have an Internet-connection.
Yes, GigoBooks is intended to be desktop linux/mac/windows software that runs entirely offline. If the OS doesn't change, it can keep operating forever.
> Btw., the GigoBooks app does not currently allow to save data, or did I overlook some menu-entry?
You're looking at the online demo which is necessarily functionality-limited because web browsers don't allow access to local files.
The 'REAL' thing is a desktop app which does allow saving data to local (sqlite) files (and yes, there are additional entries in the menu for this).
I suppose "GIGO" could be an edgy and cynically funny name for accounting software (or other kinds of data capture and analysis tools), especially if targeted at non-accountants.
But I don't know whether a real accountant, who might someday have to review/correct records captured by this software, would approve of a cavalier-looking name in a professional context.
> "Gigo" also is an acronym for "garbage in, garbage out." So you may want to rethink your name.
Ack.
I acknowledge that the name could lead to misunderstanding.
Actually, the name is supposed to be a play on 'gig' (as in, a synonym for side project). I'm planning on rebranding it so it's more 'gig-o books' than 'gigo books'.
To the author, I'd be wary of the fact that not even you felt you needed what you're try to make. It doesn't sound like you'd have payed money for something over your existing, albeit old and hard for anyone else to get ahold of today, solution. If you're making it for yourself, for the experience if nothing else, and it would be a bonus other people might pay for it, then great.
I'm fairly certain this process will be entirely automated by QB in the next 5 - 10 years, QB Cloud almost already is, paying a nominal fee for that software is well worth not having to do it oneself. I think you will find there's a limited market for such technology in a mature market.
17 comments
[ 3.2 ms ] story [ 48.9 ms ] threadThe website is just a blog that I put up in a hurry so I have a place to do some blogging. I didn't spend a lot of time on it yet. It's definitely not the 'final' website (and obviously, it's a bit unfocused).
But I'll look into it. Thanks for reporting this!
I have found that it is important not to be afraid of doing market research, surveys, conducting interviews or observations of existing people in action with existing solutions.
If you want to scratch your own itch, that’s cool. And it can work to produce a nice tight product, maybe could in this case.
But if I wanted to sell my product, I’d try to figure out if there is enough statistical significance in the market response before building it. Even just putting out and marketing an RSVP landing page for the tool, to see how many people might want it - you might get a load of potential customers who sign up and can give you feedback.
Since you’ve already decided to build this anyway, you aren’t concerned about competition - so what do you have to lose from seeing if other people want it? [1]
[1] Note - I do know that sometimes you don’t want to deal with other people’s opinions while building a product, and the author’s approach certainly is one way to go about it. Also, I guess accounting is a pretty well-known niche so a lot of the knowledge is already out there, maybe you don’t need much new input. But I felt a hypothesis here that could be tested and would be reinforcing if proven true.
EDIT: I see from the website the author is taking early access adopters, so maybe they are doing this. Actually I like the approach of doing this in the open and blogging about it, it was more the original blog post that triggered my reaction.
Mostly agree! Specific comments below.
> I have found that it is important not to be afraid of doing market research, surveys, conducting interviews or observations of existing people in action with existing solutions.
Don't disagree, but I wanted to build something first, even if it's just proof-of-concept.
But now that I have a prototype, yes, I'm reaching out to get opinions. Blogging is part of that effort.
(Personally, I don't really like the idea of putting up a landing page to collect email addresses for 'vapourware'. When I say 'personally', I'm not passing judgement on people who do it. Just that ... I sort-of don't like doing it myself.)
> Since you’ve already decided to build this anyway, you aren’t concerned about competition - so what do you have to lose from seeing if other people want it? [1]
Agree. This is part of the effort of putting it out there and seeing what sticks.
> I see from the website the author is taking early access adopters, so maybe they are doing this. Actually I like the approach of doing this in the open and blogging about it, it was more the original blog post that triggered my reaction.
Ack. Ack. Understood.
Just to confirm, the concept is basically...
"I'll create the software X to fit my own specific requirements/needs, then I'll see if anybody else wants to use it as well (which would mean that that niche of people have the same needs/requirements), and if that's the case then I can decide if to put more energe/effort/$ into it otherwise it will just be something useful for myself"
..., right?
I think that for that to work the important detail about the concept&implementation is that the SW must be complete (~no critical bugs, all needed functionality is available) + not reliant on any external dependencies (e.g. hosting, downloads of data like Tax rates from anywhere, etc) + must use proven and stable technologies. A stupid example would be "Tiddlywiki" (https://tiddlywiki.com): I downloaded the html/js-file (proven & stable & compatible with all browsers) and it works with 0 external dependencies => I can be sure that I won't loose my notes whatever happens and that the full functionality will be always available, even if in the worst case I don't have an Internet-connection.
Btw., the GigoBooks app does not currently allow to save data, or did I overlook some menu-entry?
> "I'll create the software X to fit my own specific requirements/needs, then I'll see if anybody else wants to use it as well (which would mean that that niche of people have the same needs/requirements), and if that's the case then I can decide if to put more energe/effort/$ into it otherwise it will just be something useful for myself" > > ..., right?
At a high level, yes.
(At a lower level, well, there will be variations on the same basic idea. The devil is in the detail.)
> I think that for that to work the important detail about the concept&implementation is that the SW must be complete > ... > and that the full functionality will be always available, even if in the worst case I don't have an Internet-connection.
Yes, GigoBooks is intended to be desktop linux/mac/windows software that runs entirely offline. If the OS doesn't change, it can keep operating forever.
> Btw., the GigoBooks app does not currently allow to save data, or did I overlook some menu-entry?
You're looking at the online demo which is necessarily functionality-limited because web browsers don't allow access to local files.
The 'REAL' thing is a desktop app which does allow saving data to local (sqlite) files (and yes, there are additional entries in the menu for this).
But I don't know whether a real accountant, who might someday have to review/correct records captured by this software, would approve of a cavalier-looking name in a professional context.
Ack.
I acknowledge that the name could lead to misunderstanding.
Actually, the name is supposed to be a play on 'gig' (as in, a synonym for side project). I'm planning on rebranding it so it's more 'gig-o books' than 'gigo books'.
Thanks for the heads up, though.
I don't quite understand.
> I'm fairly certain this process will be entirely automated by QB in the next 5 - 10 years, QB Cloud almost already is
QuickBooks, Xero, FreshBooks etc. already have entry-level online SaaS solutions. I'm aware of that.
So I don't quite understand by 'will be entirely automated by QB in the next 5 - 10 years'. 'What' will be automated?
If you care to elaborate, I'd be interested in hearing more.