PrepBenchmark

PrepBenchmark reviews and ranks the prep providers that finance candidates buy before sitting the CFA, FRM, CAIA and CPA exams. The business runs on affiliate revenue, and that sets the whole engineering brief: the site has to earn a reader's trust with genuinely useful, well organised content long before it asks anyone to click through to a provider. A site that reads like a funnel never gets the click.

It began as a WordPress prototype. I rebuilt it as a Laravel application so the exam domain could be modelled properly instead of bent into posts and categories, and so the editorial team could work inside an admin shaped around their content rather than around a generic page builder.

One Laravel application serving two audiences: an editorial team inside Filament, and readers on a fast, crawlable public site.

The public front end carries no SPA framework, and that is a decision rather than an omission. This is a content site whose whole job is ranking in search and loading fast on a candidate's phone between study sessions, so every page is server rendered and crawlable, with small progressive enhancements layered on top: filters that submit on change, a load more control that fetches and appends the next page of results, and nothing that falls over with JavaScript off.

Everything the editorial team touches lives in Filament: providers, scored reviews, articles, taxonomies and media, with the article editor built on Filament's Tiptap based rich editor. Deployment is a scripted tarball over SSH to shared cPanel hosting, which is the honest fit for a content site at this stage rather than infrastructure that bills for headroom nobody is using yet.

The hard part was not a feature. It was that four things which sound like one thing are not.

A reader is studying for a certification, say CFA. That certification has its own levels, and they are not universal: CFA has Level I through III, FRM has Part I and Part II, CAIA has levels again with a different meaning. Separately there is the prep provider, Kaplan Schweser or UWorld, and the provider's own course levels, which do not line up with the exam's levels at all.

Early on those were modelled as one idea, and it worked, right until the archive needed to filter by exam level as a first class concept instead of as a proxy for a provider's course. Fixing it meant splitting "which exam are you studying for" from "which provider's course are you asking about" into two independent relationships on every article and review, with globally unique slugs so that Level I means one specific thing across CFA, FRM and CAIA at once rather than colliding between them.

That correction is cheap while the content is thin and expensive once live filters and a real archive depend on it. Modelling mistakes do not announce themselves. They wait for the first feature that actually needs the distinction, then charge interest.

The archive filters by certification and by exam level together, and the level dropdown is narrowed on the server to only the levels that belong to the selected certification. Choose FRM and the Level and Part options become FRM Part I and FRM Part II, nothing else. A reader cannot assemble FRM plus CFA Level I, land on a silently empty page, and wonder what they did wrong. The impossible state is removed from the interface instead of explained after the fact.

Search runs across title, excerpt and body, ranked by which field matched: a title hit outranks an excerpt hit, which outranks a body hit. That ranking is a weighted SQL CASE expression, not a FULLTEXT index and not an external search service. At this content volume it is the right trade, correct ranking behaviour with no extra infrastructure to run, pay for and keep in sync, and a clear upgrade path the day the archive grows into one.

On a review site the date is a trust signal, so a single ambiguous "last modified" wastes one. Articles carry three dates that mean genuinely different things: when the piece first went live, when it was last fact checked without a rewrite, and when it was last materially changed.

The article page surfaces whichever of reviewed or updated happened most recently and labels it to match, so "Last reviewed" means somebody checked the facts and "Last updated" means the piece actually changed. A candidate deciding whether to trust a study plan written months ago can tell those two apart at a glance.

An affiliate content site lives or dies on organic search, so the SEO work is structural. Filtered archive URLs canonicalise back to their base page, so a filtered view like the CFA slice of the article archive points its canonical at the archive itself rather than letting every filter combination self canonicalise into a wall of near duplicate pages. Archives carry BreadcrumbList and ItemList structured data, articles carry Article and BreadcrumbList, and the sitemap enumerates real content rather than the filter space.

The email side is the same idea applied to deliverability: SES for both transactional and marketing mail, bounce handling so a bad address does not quietly poison the sending reputation, a confirmed unsubscribe flow, and reCAPTCHA v3 in front of every public form so the contact inbox and the newsletter list stay clean.

Asked to scope rich content support in the article editor, tables, blockquotes and inline code, the fast answer is to read the editor's feature list and estimate from that. I built a throwaway article instead and inspected what the editor actually produced.

Three of the four requested features already worked end to end. The real gap was that the public article template had no styling for any of them, so content that saved perfectly rendered as unstyled soup. The corrected estimate came in at roughly half the original one, and most of the remaining work turned out to be front end CSS rather than editor work at all.

Estimating from documentation would have put a price on work that was already done. Testing it took under an hour. That is the habit the whole engagement ran on: surface the tradeoff or the inconsistency before building against it, rather than guessing and invoicing the guess.

The platform is live at prepbenchmark.com. The client had no working article platform, no search, and no way to filter content by certification or exam level before this work. All of it now exists end to end and runs in production, along with review, ranking and comparison surfaces per certification and an email system that went from nonexistent to automated.

The remaining work is editorial rather than technical. Deeper written verdicts, the published methodology, and the head to head comparisons sit on surfaces that are already built and waiting on the client's content pipeline, which is exactly the right order: the machine first, then the words that fill it.