Decommissioning my first commercial product(binarysolo.blog)
binarysolo.blog
Decommissioning my first commercial product
https://binarysolo.blog/decommissioning-my-first-commercial-product/
18 comments
Programmers are famously hard to sell software to. Because:
a) They think they could do it themself in a weekend. Even though it took you 5 person years of work.
b) They are used to using lot of free and opensource software and don't expect to pay for software.
Other technical users (chemical engineers, civil engineers etc) are probably easier to sell to. But I don't have any data to back that up.
a) They think they could do it themself in a weekend. Even though it took you 5 person years of work.
b) They are used to using lot of free and opensource software and don't expect to pay for software.
Other technical users (chemical engineers, civil engineers etc) are probably easier to sell to. But I don't have any data to back that up.
There’s sometimes some truth to the “I could do it in a weekend” thing (hear me out!).
I think it is often true that 1) a talented programmer 2) can solve their own specific use case 3) in a janky way that is only usable to them, in a weekend.
That’s very far off from a product, but is enough for the programmer to not become a customer.
I think it is often true that 1) a talented programmer 2) can solve their own specific use case 3) in a janky way that is only usable to them, in a weekend.
That’s very far off from a product, but is enough for the programmer to not become a customer.
there was a famous psych test from the early 90s when some social scientists were studying the new breeds of coders. They did a few of them including one where a programming task of ordinary complexity was assigned.. the programmer was asked for an estimate of the time to solve it, then they solved it. IIR a preponderance of results were an estimate of "30 minutes or so" and then the actual wall clock time to a solution was closer to two hours.. many times.
Analysis was that the engrossing and engaging activity of coding directly warped the time-sense of the coder, as a regular phenomenon.
As an aside another test at that time was comparing the production results of someone using a mouse-driven interface versus someone using a keyboard only. The keyboard-only users repeatedly claimed to be faster than any mouse-user, but the timed tests were the opposite, by a large margin.
Analysis was that the engrossing and engaging activity of coding directly warped the time-sense of the coder, as a regular phenomenon.
As an aside another test at that time was comparing the production results of someone using a mouse-driven interface versus someone using a keyboard only. The keyboard-only users repeatedly claimed to be faster than any mouse-user, but the timed tests were the opposite, by a large margin.
Really interesting. I always put bad estimates down to individual biases, not something more systematic. I’d be really curious to see if this also is true for bigger tasks and whether it changed over time (at least for me I can honestly say it didn’t), small insights like there might reduce friction when working within a team or with narrow deadlines
As a child, I quickly learned to multiply any of my father’s task time estimates by at least 3.
Unfortunately he had anger issues at the time, so it was a constant cycle of “do this thing, your taking too long, I’m adult throwing a rage tantrum at kids, repeat”.
Unfortunately he had anger issues at the time, so it was a constant cycle of “do this thing, your taking too long, I’m adult throwing a rage tantrum at kids, repeat”.
Yes. But the janky solution they thought they could do in an hour takes 10 hours, and, in retrospect, they would probably still have been better buying the software. ;0)
Civil engineers won't buy from small companies because they don't think you'll be around for long. And then when you sell to Autodesk because nobody is really buying, they will buy and complain forever about the Autodesk price gouging.
Or:
c) They don't trust that the tool will be around for a long time
c) They don't trust that the tool will be around for a long time
That is definitely an issue for web software. Less so for desktop software. The software I wrote in 2005 still runs (the licence is perpetual), if you can find an old enough version of Windows.
This is absolutely a thing in 2024. Or less drastically the many examples of a development team being cut, further development being sporadic and bug prone, and a detached and patronizing ticket system for support instituted.
I read that more as saying the technical author had trouble selling to a nontechnical audience because they found them hard to relate to, rather than the traditional wisdom that technical people in general are a tough audience for anybody
The market I was referring to here are the kind of people who use a computer and the internet, but are not technical beyond those basics. They won't have even heard of ProductHunt, they don't follow tech twitter etc.
When they need software for something, they would google it and use the top results. Those folks are very very difficult to reach as an indie developer.
In my case, if someone google's "how to create a blog", there's literally no chance anything I do as an indie will put me in the top 5 results. Just one example of course, usual caveats and exceptions etc etc ...
When they need software for something, they would google it and use the top results. Those folks are very very difficult to reach as an indie developer.
In my case, if someone google's "how to create a blog", there's literally no chance anything I do as an indie will put me in the top 5 results. Just one example of course, usual caveats and exceptions etc etc ...
>> I find that focusing on the process instead of the outcome not only removes the pressure of chasing success, it also just makes it more fun. Whether this translates to any commercial success remains to be seen, but hey, fun is good!
This is important. All businesses should understand what their goals are, and should make decisions that serve their goals.
And it's very important to understand that there are different goals, and hence that there are different companies doing things in different ways.
One person's experience in one kind of company can lead to the conclusion that all companies behave like that. Which is untrue.
If the goal is to have fun, then make decisions that lead to fun.
However if the goal is to make a living, then make decisions that lead to income. Unfortunately most of those decisions will lead to not-fun.
Developing a software business, with paying customers, able to pay salaries, becoming sustainable, means mostly doing business things not software things. And in most cases building software does not lead to success. It is necessary, but not sufficient.
Most business (financial) success comes through the other bits. Marketing. Sales. Support. Documentation. Invoicing. Accounting. Etc.
Having fun is good. But it's ideal if that's not your day job and you can afford not to rely on it for income.
This is important. All businesses should understand what their goals are, and should make decisions that serve their goals.
And it's very important to understand that there are different goals, and hence that there are different companies doing things in different ways.
One person's experience in one kind of company can lead to the conclusion that all companies behave like that. Which is untrue.
If the goal is to have fun, then make decisions that lead to fun.
However if the goal is to make a living, then make decisions that lead to income. Unfortunately most of those decisions will lead to not-fun.
Developing a software business, with paying customers, able to pay salaries, becoming sustainable, means mostly doing business things not software things. And in most cases building software does not lead to success. It is necessary, but not sufficient.
Most business (financial) success comes through the other bits. Marketing. Sales. Support. Documentation. Invoicing. Accounting. Etc.
Having fun is good. But it's ideal if that's not your day job and you can afford not to rely on it for income.
Did you open source it after calling it quits? You never know when someone might feel inspired to breathe new life into the project.
Nope, I'm far too embarrassed of the code .... might clean it up and open source in the future but I can't see myself having the time or motivation any time soon haha.
> Inevitably, with an audience that size, a loud minority made their negative feelings known. Instead of letting these comments deflate them, they turned the tables on them.
“Primus sucks!”
“Primus sucks!”
I found this comment interesting. I haven’t had any success, not for lack of trying, but it seems like most advice I’ve heard is that technical users are hard to sell to.