1  Picking the philosophy

While everyone would like their product to be perfect, finance and marketing can force some pretty drastic compromises.

Building products can be expensive, and so getting them to market quickly can bring returns on the investment more quickly. The extreme is selling the proof of concept as if it is the complete product, which subjects all purchasers to having to deal with a flaky product with many bugs. To me, a product should be production-ready, in that it should be built to be stable enough for users to rely upon rather than having to find workarounds for its inadequacies.

I was not wanting to spend the rest of my life fixing up bugs, so I decided that the product had to be as fully working and as reliable, usable and consistent as possible. Being a pensioner with low overheads for the last few years has meant that I did not need to rush the product to market, so could take the time to make it the best it could be.

Refactoring is changing the design of a product or component when there is an opportunity to simplify it or make it more useful.

Designing is about making something fit for purpose, but that purpose can change as the users make suggestions, or even as design proceeds. When faced with time constraints, there is the tendency to just do the bare minimum necessary to accommodate the changes. While this may solve the immediate issue, it often adds complexity that hinders the future ability to make such quick changes.

A product undergoes the most changes leading up to the first version, and between the first and second versions. Architecting it so it has the most generic and flexible structure is the first step in, but that does not always deal with future changes. Refactoring is taking the time to do limited redesigning when the need arises. It is both a reactive and pre-emptive process.

I refactored many parts of the product as I went along, especially if they lead to more flexibility and adaptability, which usually enabled more opportunities for refactoring, just because they allowed it to be done more quickly. For example, I did not realise how easily I could create new elements until I centralised many rules into their own XML file. That spurred adding many other rules, and even the proforma skeletons for new elements, resulting in a reduction of PHP code and complexity within it. There are only about 10,000 lines of PHP code used.

While a product may be useful, how easily it can be used makes the difference between whether it is enjoyable to use or not.

When products are rushed to market, it can take lots of customer feedback and several versions to get a truly usable product. While a product that actually does what it is supposed to do should be a given, it is the care taken in design and implementation that gives a user a sense of confidence in the product. It is only time that allows a lot of the little kinks to be ironed out.

Smallsite Design was being used to render several real websites years before any management or editing facilities had been built. It took some more years from building the login page to finishing the product. This provided ample opportunity to shake out bugs and improve its look and usability. That is not to say that it is completely bug-free or never will have any, as any future changes can introduce some, but the long process and real-world use has made it a mature product at release.

The long-term usage enabled me to see how I could tweak functionality to be more user-friendly and consistent, as well as new functionality, such as the sequence element, that could be really useful. It also enabled me to see how a person with autism could handle using the product, improving the usability and what changes to make for accessibility mode.

I wanted to make the product less reliant upon third parties, and that includes in what the product is designed to do.

It would be ridiculous to not use the product for the product documentation, being that it is for building websites, but I extended that to add whatever functionality I would need to support the product, as long as they did not introduce new dependencies. I figured that if I needed them, many others would find them useful. That includes being able to be used for online help and even fancy formatting for buttons for prominent calls to action. The procedure article layout and functionality is something I originally developed for use in Windows help 25 years ago, and used in many contracts since.

I had considered adding appointment booking with PayPal integration, which is what I had already done simply with a previous site. However, PayPal is not really suitable for an international product, as it involves manually setting up and maintaining multiple tax rates. A quick search turned up over 20 online booking sites doing almost exactly the same thing, while also handling payments, so I did not need to reinvent the wheel there. I think when it comes to handling money, people are more trusting in a large centralised payment gateway subject to government scrutiny than a small website.

There are two models in how to sell a product: one-time or recurring.

In terms of this product it came down to whether it's a one-time perpetual license, or requiring the license to be periodically renewed to be able to continue using it. The latter has the advantage of a possibly better ongoing income stream, but that has a lot of overheads as the relationship with the customer must be maintained. That can only be done by maintaining a medium to high level of customer information and a significant servicing workforce that has to scale with the number of units sold.

This is an elder one-person operation, so I do not expect to be around forever. This has necessitated designing a product that is intended for a specific audience that does not expect constant added functionality, and that means that the product has to fully work properly and completely from the start. While there will inevitably be bugs to fix, not continually adding new functionality will mean their number will reduce over time. Reducing the number of software dependencies and conservative use of their facilities improves long-term operability of the product.

The other aspect is that I have a philosophical objection to having a livelihood that depends upon addiction, and recurring fees for the same product is creating an artificial addiction. Others justify that by promising upgrades that improve the product or add new functionality, however that often is a result of not including many of those in earlier versions. Of course, products that are based on offering cutting-edge facilities may justify that, but this product is largely based upon presenting text, and that has basically not changed in centuries.

Many large companies with products that are expensive for perpetual licenses now offer them for an annual fee that is a lot less. For such software, this can represent worthwhile savings in upfront costs, while also always having the latest versions. For this product, the upfront cost is not anywhere near these others, and making it available on subscription does not make sense, as overheads would swamp the received income.

I am not going to try to be a friend of every customer, and for my sanity I am maintaining the least amount of information about customers, and as little contact with them, as I can. That improves their privacy, simplifies my back-end storage requirements, eliminates the need for any other staff, and reduces my legal liabilities to just the product itself. Some people want extreme busyness to feel alive, but I do not! I enjoyed making the product, and enjoy using it to write about how we can make a better world. I would rather people have that for themselves than an ongoing reliance upon me.

I want people to have tools that help them to be creative and independent. Too many want to have people effectively, if not actually, addicted to their products and services. That is not harmlessness, but selfishness. While many emphasise having a business model that ensures an ongoing income, I see that there are so many people in the world that could effectively use my product that I do not need to manipulate my customers in that way, especially by undercutting functionality so that there is a future enticement. I do not need to maximise my income at any cost.