[HN Gopher] Decommissioning my first commercial product
___________________________________________________________________
Decommissioning my first commercial product
Author : elawler24
Score : 43 points
Date : 2024-09-04 17:34 UTC (3 days ago)
(HTM) web link (binarysolo.blog)
(TXT) w3m dump (binarysolo.blog)
| codazoda wrote:
| > It was also targetted at non-technical people and as an indie
| developer, it's very difficult to reach that market.
|
| 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.
| hermitcrab wrote:
| 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.
| Buttons840 wrote:
| Or:
|
| c) They don't trust that the tool will be around for a long
| time
| ianlevesque wrote:
| 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.
| hermitcrab wrote:
| 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.
| marcosdumay wrote:
| 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.
| senkora wrote:
| 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.
| hermitcrab wrote:
| 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)
| mistrial9 wrote:
| 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.
| randomlurking wrote:
| 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
| Modified3019 wrote:
| 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".
| sethhochberg wrote:
| 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
| bruce511 wrote:
| >> 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.
| mrbluecoat wrote:
| Did you open source it after calling it quits? You never know
| when someone might feel inspired to breathe new life into the
| project.
___________________________________________________________________
(page generated 2024-09-07 23:02 UTC)