Reminds me a lot of a final year group software project at uni. Instead of building a solution for our client we built a kind of meta solution, then ran out of time to actually solve his problem in it.

From time to time I send this article at my job. Just as a distress call about our system.

Perhaps a corollary to Greenspun's Tenth rule?

"Any sufficiently complicated database program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of COBOL."

I've seen these custom fields tables in a number of database schemas I've worked with in the past. It adds dynamism to a fixed table structure. I wonder how CRMs do it these days without having poor performance at scale?

I've made the mistake of creating this kind of problem many moons ago. The dream was to have non-technical domain experts implement the product. I did not know at the time that this was a cursed problem. Probably one of the most cursed, in fact.

Putting it my sql based scripting engine took 2 weeks. Backing it out is going on 4 years now. Perhaps the biggest technical misstep I've ever made. It's kind of like Pandora's box because once the non technical people feel the speed/control, they'll never let it go. You could place a literal money printer on their desk as an alternative and they'd reject it if you took their new power away.

It's 2025 why are you gluing SQL strings? Don't even use it as an example!