Under the hood
Why bother writing about the thinking and work that went into creating the product?
The reasons why I created this series of articles are to:
Of course, I might tell myself the first is why I'm doing it, but the latter plays a big part. Many times I thought some functionality would be good, and may have even started designing it, but then questioned whether it really fitted into the ethos of the product, or just wouldn't fly with the target product audience. Sometimes the reality of the thinking has to be seen to know why an idea doesn't make sense.
Designing products solo has a lot of challenges. The only other person who used the product was fairly non-technical, so could not really challenge me at the technical level. Mainly they helped me by letting me say ideas out load so I could hear whether they made sense to me. They are also autistic, which helped me understand what sort of accessibility measures would be needed to be catered for.
There are many good YouTube channels that describe the details of bringing a product to market, though many of them are about hardware, which has a lot of its own issues, mainly related to how to manufacture and physically distribute it. While the early days of software involved physical distribution, today a product's distribution can be totally in the cloud, cutting out a lot of the costs and risks. Hardware can result in a lot of product sitting in inventory because scale is needed for low costs, but sales never match the expectations, or there was not enough money for marketing.
Software might have the same development timeframes as hardware, just because any development involves much experimentation and many iterations. However, production scales easily as there is not the adaptation needed to accommodate scale. Hardware often uses different sets of manufacturing processes for development, low-runs and mass-runs, just because there are those economies of scale to take advantage of. The only part about software that requires scaling adjustments is in the support staff needed to help those with usage or bug issues.
The development side of software is almost totally dependent upon the business model used, but also on how the model chosen is to be applied. I want to remain a one-person operation and not have a high-level of ongoing involvement with the product, as I expect to want to do create something new. Others might want to keep producing new versions with added functionality because they are wanting an ongoing income stream. I preferred to build a fully-working complete product and only deal with fixing bugs. That played out in who I chose as the target market, and what facilities to provide for them.
I have an adequate income for my very modest lifestyle, so I was prepared to take the eventual 10 years it took to complete the product. From here on in, any sales are a bonus. For those wanting a substantial income stream, the issues are more complex, but that is where the reasons for building a product have to be clear, and thought put to what compromises to make in order for it to happen.
Many want a successful product, so after development, they want some investors to help them. That is a huge compromise, as they will want quick returns and will force many compromises in the design to hasten that along. If integrity of design is a major consideration, don't take in investors that want any measure of control. Rather, be prepared to take it slowly. It is better to treat it as a hobby, and if it happens to generate income, that is a bonus!
However, it pays to realistically think about what the results of substantial sales would be, as there would be taxes to put aside to not be caught out at the end of financial years, and possibly others who want or expect to nuzzle in on the takings, be they relatives or businesses offering help for a substantial price. Always remain level-headed and practical. Products don't usually go viral, so there should be plenty of time to adjust to gradually increasing sales and income.