01Question
For a corpus of a few hundred rows, weighted LIKE matching across a handful of columns will produce good enough ranking without the trigger machinery FTS5 requires.
02Method
Built the search endpoint for this site as a UNION across projects, articles, notes, experience and skills. Each branch assigns a score: exact title match highest, title prefix next, then title substring, then body substring, with a small bonus for recency. Compared result ordering against what I would have ranked by hand for twenty representative queries.
03Outcome
Confirmed for this size. Ranking matched my manual ordering on seventeen of twenty queries, and the three misses were all cases where a body match in a long article outranked a weaker title match in a short note, which is arguably correct anyway.
The cost is that scoring lives in SQL and is verbose. The benefit is no triggers, no shadow tables, and no possibility of the index drifting from the source rows.
Where this breaks: stemming and typo tolerance. There is none. Searching "kubernetes" does not find "k8s" unless you write that synonym in. At a few hundred rows I can enumerate the synonyms I care about. At ten thousand I would want FTS5.