The founder's bilingual author site serves its text and one structured data graph before any script runs

The problem

The founder needed one public place for his books, his writing, his speaking calendar, his research and the two education platforms, in English and in Portuguese. Editors, event organisers, schools and companies look him up before they write or invite. Search engines and answer engines index the same pages. Every reader had to find the same facts, and the machines had to read them without running the application.

A single page application alone does not meet that need. Its HTML arrives empty, and the content exists only after the script has run. The build therefore had to put the text and the structured data in the HTML itself, and still behave as an application once it loads.

What was built

A bilingual author and speaker site at https://mrnascimento.com/ with nine public routes: home, writing, speaking, research, books, platforms, about, sobre and contact. Each route answered HTTP 200 on 24 September 2026.

• The books page presents the two editions with their ISBNs and purchase links, and points to the companion site.
• The writing index lists 13 press essays in English, Portuguese and Spanish, 4 preprints, 2 books and 1 podcast interview, newest first, with filters by type and by language.
• The speaking page carries the 2026 calendar, six talks on offer, the formats, a speaker kit with headshots, bios and a fact sheet, and notes on how to book.
• The research page groups the systems, the preprints, the fine-tuned models, the peer review service and the identifiers.
• The platforms page describes the two products, one for teachers and one for students, with Portuguese summaries.
• About and sobre give the biography in English and in Portuguese; contact gives the routes and answers the questions people ask first.
• Two printable press kit pages, about.html and speaking.html, are served as plain files with their own structured data.

How it works

The deployed site includes one HTML file. Before any script runs, that file already holds three things. First, the page metadata: title, description, canonical link, Open Graph tags and rel="me" identity links. Second, one JSON-LD graph with 17 entities: the person, the two books, the three events, the eight articles, the two blog postings and the podcast episode, with the credentials nested in the person entity. Third, a pre-rendered block of body text with the positioning line, the biography, the books, the speaking calendar, selected writing and the identity links.

The hosting rewrites every path to that same file, so the response for the books page is byte for byte the response for the home page. When the file reaches a browser, the application starts, replaces the pre-rendered block with the full page and routes on the client, loading one JavaScript chunk per page. A crawler that runs no JavaScript stops at the first step and still gets the text and the graph.

The Portuguese profile at sobre declares pt-BR; every English route declares en-GB. The build uses hashed asset names. The hosting rules cache scripts, stylesheets and images as immutable for a year.

Evidence

Every number here was read from the live site or from its published files on 24 September 2026. The HTML served for the home page carries one JSON-LD graph with 17 entities, and the count is the same with and without JavaScript (live HTML of https://mrnascimento.com/, fact author-platform-06). The pre-rendered block holds four headed sections under the biography: Books; Speaking, 2026; Selected writing; Elsewhere (raw HTML of the same page, fact author-platform-05).

The sitemap lists nine public routes and two press kit files, and each of the eleven answered HTTP 200 (https://mrnascimento.com/sitemap.xml and curl of each route, facts author-platform-02, 03 and 11). The writing index states 20 items: 13 press essays, 4 preprints, 2 books and 1 podcast interview (https://mrnascimento.com/writing, fact author-platform-09). The current release, deployed on 3 September 2026 with the Firebase CLI, holds 36 files (release record in the published files, fact author-platform-13).

Stack

Verified from the published files and the live HTML (fact author-platform-12):

• React, with React Router on the client and one JavaScript chunk per page.
• Vite build with hashed asset names.
• Tailwind CSS.
• Motion for the animation.
• One JSON-LD graph and a pre-rendered body block in the HTML shell.
• Google Fonts: Instrument Serif, Instrument Sans and JetBrains Mono.
• Firebase Hosting, with a rewrite of every path to the shell and immutable caching for scripts, stylesheets and images.

What it demonstrates

Define. The site addresses editors, organisers, schools, companies, and the crawlers and answer engines that never run a script. The measure of success is concrete: the facts must be in the HTML, not only in the application.

Instrument. Every claim in this case study is a check anyone can repeat. Fetch the page without JavaScript and the biography is there. Count the entities in the graph and there are 17. Compare the response for two routes and the bytes match. The site was written up from those checks, not from memory.

Integrate. The result is one static shell, a hosting rewrite and a cache rule. Static hosting serves the site without a separate application server.

Hand over. The site is a folder of plain files. The author deploys it alone with one command, and the release record shows exactly what shipped and when. That is the standard NASCIA applies to larger systems as well: the part that has to work is the part that can be checked.