App Store Connect has a required field for the privacy URL

Per app. And if you offer your app not only in Germany, you also need the page behind it in the languages in which it is sold.

With DevPreview, this was still done manually: one page, German and English version stacked, enter the link in App Store Connect, done. Then the second app came along, and the one page turned into a multiplication table – apps times languages times documents. In an Astro project, each cell in this table is its own file in the repository. If I change a retention period, I have to update it everywhere. The third time, I forget one, and then the English version has a deadline that in the German version already reads differently.

Odoo attaches translations to the same record as the original. I maintain a text, switch the language and translate the paragraphs that have changed. No second directory tree, no file that gets out of sync.

The side effect I had underestimated

A typo on the homepage previously meant: open editor, find file, change, commit, push, wait for build, deploy. For one word.

Astro is not to blame for this, the generator works cleanly. But every change goes through the same chain, whether I swap a single letter or build an entire page. Now I log in, click on the text, save, done.

I still write longer posts in Markdown – in a WYSIWYG editor I wouldn't voluntarily type 1,200 words. My module handles the path to the database eq_website_markdown_import: Title, lead, tags, publication date and the SEO fields are in the YAML header of the file, images are in a ZIP next to it, the module wires both together into a finished post.

If the title is missing, it immediately bites you: Without title: in the frontmatter, the importer pulls the filename as the post title – and then you have a construct of date and dashes above the article. Two minutes saved, ten minutes of rework.

The little extras came along

On the page there are a few small JavaScript games and gimmicks that I have built over time. These were exactly what I considered the critical part of the migration, because I had expected Odoo to get in my way when embedding my own scripts.

Doesn't have that. The games aren't tied to any framework, they're pure vanilla JS and thus a matter of files in the asset directory plus a page with an HTML block. Effort: an afternoon, and most of that went to cleaning up paths I had hardcoded years ago.

The reach measurement stays in-house

No Google Analytics, no third-party service. The measurement runs through my own Odoo module on my own server at Hetzner, and I set the retention periods myself instead of accepting defaults:

• Server logs: 7 days
• Reach measurement: 12 months
• Contact form requests: 24 months

Since the move, this data and the content it was collected from are in the same database. I answer a request under Art. 15 GDPR through a single contact record instead of two systems and a good memory.

What I've gotten myself into

A statically served HTML file is faster than a page backed by a Python process and database query. The initial page load is slower as of today, and no amount of fine-tuning changes that fundamental fact.

What helps is unspectacular: enable asset bundles, set caching headers properly, serve images at the size they're displayed, and don't stack snippets nobody needs. This brings the page into a range that's perfectly adequate for a developer business card with two apps in the App Store. Anyone running a news site with six-figure traffic makes this decision differently.

And anyone who maintains a pure content page, without forms, without customer data, without legally binding documents in five languages, has the better tool at hand with Astro. For me, the switch was worth it because I touch Odoo daily anyway and write missing modules myself. Without this prerequisite, the move would not have been a gain, but a second project alongside the apps.