One of the earliest decisions to make is what tools to use, as that is dependent upon not only availability and skillset, but also what must be used.
What I wasn't very skilled at was backend technologies. The only PHP I had done was a couple of dozen lines of code for a utility on our NAS box to keep only the last three system backups of each computer we had on our network. When I started in early 2014, PHP was the web language, so it was a no-brainer. However, the next question was whether to use ancillary tools with it, such as one of the libraries available that have taken care of a lot of the common tasks serious websites need for their functionality.
This was the where my first real decision was made. That is, do I use a third-party library or invent what I need from scratch? I decided on the latter because my envisioned target audience was people who would not be technically savvy enough to keep things up to date. We know that every third-party library is a source of possible threats, but even from just plain bugs. A library is always overkill for any particular purpose, but even what is not used of them is a source of possible threats.
I decided to bypass all third-party software, except for PHP itself. That is not hard, as while there are many programming languages, PHP as delivered is actually a conglomeration of a lot of third-party software. Its advantage is that all those have been tested and updated before delivery, and PHP is always updated by the hosting provider, absolving my customers of having to look after any software updates themselves, except for my product itself.
Smallsite Design only has about 10,000 actual lines of PHP code, which is a lot less than any major library I could have chosen to work with it at the time, or since. However, the PHP is mainly doing the checking and organising work, while XSL handles the significant presentational aspects and much of the business rules.
While I was familiar with XML and XSL, I originally looked at abandoning my tendency to use the facilities within the presentation technology to store and render content, such as using MS Word or Excel if the result was going to be in one of those. Instead, I was looking at a database and programmatically constructing the HTML. While there is always a bit of building a mini-library to do the legwork required for any combination of tools, this arrangement was just plain clunky.
All the tools used for XML and XSL naturally manage their data in a state that transparently is suitable for HTML, just because they are essentially built on the same technology. I soon switched back to using XML for data storage, and XSL for rendering so that the data was always preconditioned for web page use.
This fit well with another early decision that sites need to be relatively easy to transfer to another hoster, which sort of ruled out MySQL with its need to have real technical smarts to manage moves. Smallsite Design's data requirements are very modest, so while SQLite could easily be put to use for it, there was still the clunkiness of the data conversion between the relational database and what is required for HTML.
Normalisation is the converting of what might be created as multiple codepoints in an IME (Input Method Editor) into a single codepoint, which to this day can only be done at the server end. This meant that input fields have to allow excess codes but the backend had to determine how many actual characters there were and inform the user afterwards.
The normal way that sites handle round-tripping is to use AJAX calls and update that part of the page with the updated HTML. However, I have provided most management pages with a lot of context information that would all have had to undergo the same update process. So, full-page round-tripping is the norm. I have tried to minimise the page jumping around with each update by using CSS scroll-padding and judicious use of the # location to keep the relevant part of the page in the viewport, though on really complex pages, that CSS command seems to lose itself in Edge.