DEV Community: AC0Hero

I Built an EU Law Tracker in 24 Languages. Then I Cut It Back to Four.

AC0Hero — Thu, 13 Aug 2026 10:03:32 +0000

The first version of EU Inc Monitor had a simple internationalisation strategy: if a page existed in English, create it in every European language we supported.

That gave us 24 language routes, a satisfyingly large sitemap, and a serious technical problem.

Legal and regulatory content is not a normal localisation workload. A product landing page can survive a slightly stale translation. A page that explains a live legislative proposal cannot. The source document changes, committee positions diverge, dates move, and one misleading verb can turn a proposal into something that sounds like current law.

The system now has four active locales, only two of which are indexed. That retreat made the site smaller, more accurate, and easier for search engines to understand.

This is what changed in the Next.js architecture and why.

The original mistake: route count looked like coverage

The application uses Next.js 16 and next-intl. Every locale was a valid route prefix, so adding a language looked almost free:

export const routing = defineRouting({
  locales: activeLocales,
  defaultLocale: "en",
  localePrefix: "always",
});

But route availability is not content quality.

With 24 locales, every new analysis created 24 public URLs. Search engines saw thousands of pages. Editors saw one English source and a translation backlog. When the European Commission published a correction or Parliament released a new amendment set, the English page could be updated immediately while the other 23 variants became progressively less reliable.

The most dangerous failure mode was not a broken page. It was a polished, indexable page that still described yesterday's legal position.

So we separated three concepts that had been incorrectly treated as one:

A route can exist.
A translation can be available to readers.
A page can be approved for search indexing.

Those are different states.

The smaller locale policy

Today the policy is explicit in code:

export const indexedLocales = ["en", "de"] as const;
export const previewLocales = ["fr", "es"] as const;
export const activeLocales = [...indexedLocales, ...previewLocales] as const;

English and German are the search core. French and Spanish remain available as reader previews, but they are noindex until they have passed native editorial review. The other 20 locales were retired instead of being left online as an unmaintained promise.

This is a business rule expressed as a small data structure. It drives routing, robots directives, canonical tags, hreflang output, and sitemap generation.

The key lesson was to avoid burying editorial policy inside page components. If five different files decide whether French should be indexed, they will eventually disagree.

Content availability is existence-driven

Not every insight exists in every active locale. Older articles may have more translations, while a new analysis may initially have only English and German.

The content loader therefore treats files on disk as the source of truth:

export function getAvailableInsightLocales(slug: string): string[] {
  const dir = resolve(contentRoot, slug);
  const present = new Set(
    readdirSync(dir)
      .filter((file) => file.endsWith(".md"))
      .map((file) => file.replace(/\.md$/, ""))
  );

  return routing.locales.filter((locale) => present.has(locale));
}

That list is reused everywhere a language variant is exposed. A translation file is not merely copy. It is the capability that makes the corresponding route eligible to appear in navigation, metadata, and the insight sitemap.

We still allow a reader-facing fallback to English in a few contexts. But a fallback URL must never be advertised to search engines as a real translated page. A URL that renders English under a Spanish path is useful as a convenience for a person and harmful as an SEO signal.

Hreflang should describe reality, not ambition

Our largest technical cleanup came from hreflang.

The first implementation generated alternatives for every configured locale. Some of those URLs redirected. Others returned English fallback content. The framework also emitted an HTTP Link header using unprefixed URLs, while our HTML metadata pointed to prefixed routes such as /en/guide.

The result was two conflicting language clusters and hreflang entries that led to redirects.

We disabled automatic alternate links and made Next.js metadata the single owner:

export const routing = defineRouting({
  locales: activeLocales,
  defaultLocale: "en",
  localePrefix: "always",
  alternateLinks: false,
});

Then we only emit alternatives that are both present and indexable:

const searchLocales = availableLocales.filter(isIndexedLocale);

const languages = Object.fromEntries(
  searchLocales.map((locale) => [
    locale,
    getLocalizedPath(locale, path),
  ])
);

return {
  canonical: getLocalizedPath(currentLocale, path),
  languages: {
    ...languages,
    "x-default": getLocalizedPath("en", path),
  },
};

The rule is strict: an hreflang target should return 200, be indexable, contain the matching content, and link back into the same cluster. If any of those conditions is false, the target does not belong in the cluster.

This sounds obvious. It is also easy to violate when the list of languages comes from framework configuration rather than actual content.

Self-canonicals, including on preview pages

We considered pointing French and Spanish preview pages to the English canonical. That would have been wrong.

A translated page is not a duplicate of the English page merely because both express the same facts. Cross-language canonicals can cause the translated URL to disappear from the signals search engines use to understand language variants.

Our preview pages keep a self-canonical but use noindex, follow. They do not emit an incomplete hreflang cluster. When a locale passes editorial review, indexing and hreflang can be enabled without changing the URL.

That gives every page one clear state:

indexed and part of a reciprocal language cluster;
available as a self-canonical preview with noindex;
or retired and redirected to the final English destination.

We split the sitemap by intent

The site has stable reference pages, live legislative trackers, and editorial analyses. They do not change at the same rate and should not be treated as one undifferentiated URL dump.

We now generate a small core sitemap for hubs, methodology, sources, facts, and the live legislative timeline. Insights live in a separate sitemap built from an allowlist of articles that have met sourcing and editorial requirements.

The insight sitemap also reuses the locale policy:

for (const slug of indexableInsightSlugs) {
  const languages = Object.fromEntries(
    indexedLocales.map((locale) => [
      locale,
      getLocalizedUrl(locale, `/insights/${slug}`),
    ])
  );

  for (const locale of indexedLocales) {
    entries.push({
      url: getLocalizedUrl(locale, `/insights/${slug}`),
      alternates: {
        languages: {
          ...languages,
          "x-default": getLocalizedUrl("en", `/insights/${slug}`),
        },
      },
    });
  }
}

An article being published is no longer enough to put it in the search sitemap. Publication and index eligibility are separate decisions.

The content model had to understand legal status

Internationalisation was only half of the problem. A regulation tracker needs a shared status model so every page agrees on what has happened.

We keep current status, recent developments, and upcoming legislative events in structured data. Pages read from that shared model instead of hand-writing the current position in every locale. Long-form analyses still live in Markdown, but volatile facts such as procedure stage and review date are centralised.

That reduces the number of sentences an editor must hunt down after a new Council document appears.

The public site also exposes its methodology, primary-source register, and correction process. For legal information, those are product features, not footer decoration.

What I would do from day one

If I were rebuilding the tracker, I would start with these constraints:

Index one language first.
Add a locale only when someone owns its ongoing editorial review.
Represent route availability, translation availability, and index eligibility as separate states.
Generate hreflang from real files and policy, never from the full framework locale list.
Keep one metadata owner. Do not let middleware headers and page HTML describe different clusters.
Test every hreflang target for 200, self-canonical, indexability, and reciprocity.
Centralise volatile legal status instead of repeating it in prose.
Retire weak locales cleanly rather than preserving them for vanity metrics.

The uncomfortable lesson is that international reach does not come from multiplying routes. It comes from maintaining trustworthy pages.

The site became more useful when it shrank from 24 active languages to four, and more honest when only two of those were allowed into search. That is not a failure of internationalisation. It is internationalisation finally respecting the cost of the content it carries.

I Turned One Next.js Buying Guide Into 12 Sites. Here Is What Broke.

AC0Hero — Wed, 12 Aug 2026 17:55:49 +0000

A few months ago I wrote here about building a 209-page sauna site without knowing how to code.

That experiment did not stay one site.

It became 12 independent buying guides for saunas, cold plunges, hot tubs, heat pumps, home batteries, generators, EV charging, water filters, greenhouses, backyard offices, air conditioning, and longevity.

You can see the network at The Guide Guy.

I am still not a developer. I use AI tools to help me implement things. But I am responsible for the decisions, the operating model, and all the mistakes below.

The surprising part was not generating another site. That became easy quickly.

The hard part was keeping 12 small sites honest, deployable, measurable, and different enough to deserve their own existence.

Why I did not make it one monorepo

Each guide is its own repository and its own Vercel project.

That was partly accidental. Sauna Guide came first, and the other sites were cloned from it. But the separation has been useful:

one broken build does not block every site
each site can have its own brand, content rules, and deployment history
a weak niche can be frozen without changing the stronger sites
I can sell or hand off one property later without untangling a shared application

The cost is drift.

Every shared fix has to be applied deliberately. Environment variables diverge. One clone keeps an old CTA. Another has the wrong analytics key. A third looks healthy locally but deploys from the wrong commit.

So I stopped treating the code template as the product.

The operating system became the product.

Problem 1: pnpm tried to be too helpful

All projects live under one parent workspace on my machine. That made dependency installation look simple, until a site started resolving modules against the parent workspace instead of its own repository.

The result was a build that worked in one context and failed in another.

The boring fix was the right one: install inside each guide with pnpm install --ignore-workspace when an install is actually needed.

No abstraction. Just one explicit rule in the runbook.

Problem 2: a successful deploy was not always the production deploy

Vercel could report a deployment as Ready while the production domain still pointed at a different deployment.

I also hit an author-identity problem. A commit could be technically valid but fail the production workflow because the Git author did not match the expected account.

Now every deployment check asks two different questions:

Did a deployment finish successfully?
Does the production target point to the exact commit I intended to ship?

Those are not the same fact.

This distinction sounds obvious after you learn it. It was not obvious while I was looking at a green status badge.

Problem 3: one invisible newline broke shared configuration

Some environment values were added with a shell command that included a trailing newline.

The value looked right in a dashboard. It was not right in the application.

The network rule is now to pass exact values with printf, not echo, and verify what production actually uses before changing local files.

This is a tiny lesson, but tiny lessons become expensive when copied across 12 sites.

Problem 4: shared analytics created shared confusion

The network uses a small number of analytics projects because the free plan has limits. Several domains therefore report into the same project.

That only works if every report filters by hostname.

At one point a local environment file pointed a site at the wrong analytics project while production was already correct. Editing production based only on the local file would have made the real system worse.

The fix was procedural again:

verify the production environment
inspect real incoming events
filter every report by domain
treat local configuration and deployed configuration as separate evidence

Problem 5: internal linking became a quality problem

Twelve related sites make it tempting to build an all-to-all link mesh.

That would be easy to automate and mostly useless to readers.

Instead, links need to answer the next decision in the same project.

A heat pump article may naturally link to a guide about home electrical capacity. A greenhouse article may link to water quality for a well. A random sauna article does not need links to eleven sister sites.

I added an audit that checks whether approved links resolve, whether destinations repeat too often, and whether a site has become isolated. The audit can find structural gaps, but it cannot decide whether a link helps a human. That still needs judgment.

The daily health report matters more than the template

The most useful shared code is not a page component.

It is a daily report that checks the boring things:

production domains
search visibility
analytics events
AI referrals
leads
content-rule violations
broken or suspicious cross-site links

I used to think scaling meant making it faster to create another site.

Now I think scaling means making it harder for an existing site to lie about being healthy.

What I would do differently

I would build the operating checks earlier and clone later.

I would also spend less time thinking about the number of pages. Generic content is not a moat. The useful assets are current decisions, real quote data, honest verdicts, and relationships with people in each market.

The technical system should make those things easier to maintain. It should not become an excuse to build more infrastructure.

That is the biggest lesson from turning Sauna Guide into a network that also includes projects like Heat Pump Guide:

The clone script creates supply.

Trust, distribution, and operational discipline create the business.

I am still learning all three.

EU Inc: What Developers and Founders Need to Know About Europe's New Company Form

AC0Hero — Sat, 04 Apr 2026 10:41:14 +0000

The European Commission dropped something big on March 18, 2026 - and many EU-developers missed it.

They proposed EU Inc: a single company form that lets you register once and operate across all 27 EU member states. No subsidiaries. No local notaries. No navigating 27 different legal systems.

If you've ever tried to expand a business from one EU country to another, you know the pain. EU Inc is designed to kill that pain entirely.

The numbers

Registration time: 48 hours, fully online
Cost: Under 100 EUR total
Minimum capital: 1 EUR (yes, one euro)
Countries covered: All 27 EU member states
Notary required: No
Physical presence required: No

Compare that to today: setting up a GmbH in Germany requires a notary, 25,000 EUR minimum capital, and weeks of paperwork. A Swedish AB needs 25,000 SEK. A French SAS needs complicated statutes drafted by a lawyer.

EU Inc replaces all of that with one digital process.

Why developers should care

If you're an indie developer selling SaaS across Europe, you currently face this:

Today: You register a company in your home country. You sell to customers in 15 EU countries. Tax compliance, VAT, and legal obligations vary per country. Want to hire someone in Germany? You probably need a local entity. Want to raise money from a French VC? They might want a local structure.

With EU Inc: One company. One set of rules. You're already set up to operate everywhere.

This matters especially for:

Solo developers selling digital products across the EU
Remote-first startups with team members in multiple countries
Open source maintainers looking to set up a commercial entity
Indie hackers who want to keep things simple while selling internationally

What EU Inc actually is (technically)

EU Inc is formally called the "28th regime" - it doesn't replace any existing national company forms. It adds a new one on top. The legal name is S.EU (Societas Europaea Unius).

Key governance features:

Digital-first: Registration, share transfers, and shareholder meetings can all happen online
Modern cap table: Built-in support for share classes, vesting, convertible instruments - things that currently require expensive legal workarounds in most EU countries
English as standard: Documentation can be in English regardless of which country you register in
Single register: One EU-wide company register connected via BRIS (Business Registers Interconnection System)

The full proposal is COM(2026) 321 if you want to read the source.

What about taxes?

This is the question everyone asks. The answer: EU Inc follows local tax rules in the country where you register. Tax harmonization is not part of this proposal.

My hope is that if you register your EU Inc in ex. Estonia (0% corporate tax on undistributed profits), you pay Estonian tax rules. Register in Ireland, you get Irish rates.

This means jurisdiction shopping is still a factor - but at least you only need one entity instead of multiple.

Timeline

January 2026: European Parliament voted 492-144 in favor of EU Inc recommendations
March 2026: Commission published the formal proposal
End of 2026: Target for Parliament and Council agreement
2027+: First registrations expected (depends on adoption speed)

There's strong political will to push this through fast. The European Council explicitly called for it in their March 2026 conclusions.

Should you wait for EU Inc?

Probably not. If you need a company now, register one now. But you should:

Track the timeline - know when EU Inc becomes available
Design for conversion - EU Inc will likely allow conversion from existing national forms
Understand the trade-offs - EU Inc is great for cross-border, but if you only operate in one country, your national form might still be simpler

Resources

I've been tracking this regulation closely and built a comprehensive resource site:

Full EU Inc Guide -- everything you need to know in one place
Interactive Timeline -- tracks every legislative milestone
Company Form Comparison -- EU Inc vs Delaware LLC, Swedish AB, German GmbH, Dutch BV side by side
Readiness Assessment -- 2-minute assessment to see if EU Inc fits your situation
Weekly Insights -- analysis and legislation updates

The site is available in 24 EU languages at euinc.me.

What do you think -- would you use EU Inc for your next project? Drop a comment below.

I Built a 209-Page Sauna Site Without Knowing How to Code

AC0Hero — Thu, 02 Apr 2026 13:31:21 +0000

I am not a developer. I want to say that upfront so you know what kind of post this is. What ive tried to do is figuring out distribution before figuring out code.

The site is sauna.guide. It has 209 pages. Sauna listings, brand reviews, buying guides, gear recommendations. All of it built with Next.js, all of it static, all of it generated from JSON files and markdown.

I did not write the code by hand. I used AI tools to help me build it. But the decisions, the outreach, the content strategy, the emails to manufacturers. That part is all me. I hope and believe that will make the difference.

Why saunas

I love saunas. That is the whole origin story. No market research spreadsheet, no TAM analysis. I wanted to build something in a space I actually care about, and saunas felt right. There is a growing community, real buyer intent, and not a lot of good independent content online.

So I started. 🧖

Distribution first, features second

The biggest lesson so far: nobody cares about your site until you give them a reason to.

I have spent more time emailing sauna manufacturers than I have spent on the site itself. Real emails, one by one. Introducing myself, explaining what Sauna Guide is, asking if they want their brand page reviewed and updated. Some reply. Some don't. All will ;)

That is the whole distribution strategy right now. Talk to the people who make the things I write about. Build relationships. Get them to share their pages.

What 209 pages actually looks like

Every page on the site comes from data files. Saunas are stored in a big JSON file with ratings, features, editorial notes, and quality scores. Guides are markdown files with a publish date in the header. Products have specs, prices, and Reddit sentiment.

At build time, Next.js reads all these files and generates a static HTML page for each one. No database, no server, no CMS. Just files in a folder that become a website.

I also built a simple scheduling system. Every guide has a date, and the site only shows guides where the date has passed. I have 14 guides queued through September. They go live on their own. All I need to do is redeploy every couple of weeks. 📅

Early signs

I want to be honest here. I do not know if this will work long term. The site has been live for a few months and I am still figuring things out.

But some things are starting to move:

Google is indexing pages and some are ranking on page one for specific queries
A few brand pages get steady organic traffic
Manufacturers who engaged with outreach are sharing their pages
People who find the site tend to stay and read multiple pages

None of this is explosive growth. It is more like seeds starting to show above the soil. Enough to keep going. Enough to believe there is something here.

What I have learned so far

Content quality beats content quantity. I started by trying to publish as much as possible. That was a mistake. The pages that rank are the ones I spent real time on. The ones with editorial opinions, real tips, honest drawbacks. The thin pages just sit there.

Outreach is the unlock. SEO takes months. Social media is noisy. But a personal email to a manufacturer who then shares your review of their product? That is immediate, targeted traffic from exactly the right audience.

You do not need to code to build. I am proof of that. AI tools can handle the implementation if you know what you want to build and why. The hard part is not the code. The hard part is knowing what to say, who to talk to, and having the patience to wait for results.

What is next

More outreach. More guides. More relationships with people in the sauna world. I am also working on a quiz that helps people find the right home sauna, which feeds into an email sequence.

I do not have a grand vision for where this ends up. Maybe it becomes a real business. Maybe it stays a passion project that makes a little money. Either way, I am grateful to God for the ability to build something from nothing and learn along the way. That alone has been worth it. 🙏

If you are thinking about building a content site, my advice is simple: pick something you love, build the pages, and then spend most of your time talking to people instead of tweaking your code.

The site is at sauna.guide if you want to see it.

Thanks for reading.

I built a church discovery site with 2,200+ churches in 50 countries

AC0Hero — Sat, 21 Mar 2026 11:52:10 +0000

GospelChannel is like "Yelp for churches" but with worship playlists, YouTube links, and a prayer wall.

Why I'm building this

Finding a church shouldn't be hard. But it is. You google "churches near me" and get a mix of outdated directories, broken websites, and listings that tell you almost nothing useful.

I moved cities a few years ago and spent weeks trying to find a church that felt right. Service times were wrong. Websites were down. There was no easy way to get a feel for a place before showing up.

So I started building GospelChannel. Not as a business plan or a startup pitch. Just as something I wished existed.

What the site actually does

Every church on GospelChannel gets a profile page with the stuff that actually matters when you're looking for a place to attend:

Worship playlists from Spotify so you can hear what the music sounds like before you visit. This is a bigger deal than people think. Music sets the tone for an entire service.

YouTube links for each church, so you can watch a service from your couch before deciding to visit.

Service times that are actually current (more on how I keep these updated below).

A prayer wall where people can share and support each other. In all honesty, the prayers on there right now are seeded since the site doesn't have real traffic yet. But the feature is built and ready for when people start showing up.

You can browse by country, city, or denomination. The goal is: land on the site, find a church, and know what to expect before you walk through the door.

The tech behind it

The site runs on Next.js 16 with Tailwind for styling, Supabase as the database and auth layer, and Vercel for hosting. Pretty standard modern stack, nothing fancy.

The interesting part is the data pipeline. Manually researching 2,200+ churches would take forever, so I built an AI pipeline:

Apify crawls church websites
Firecrawl extracts structured data from those pages
Claude enriches and normalizes everything: service times, denominations, locations, descriptions

This pipeline lets me add churches in bulk and keep the data fresh without doing everything by hand. It's not perfect, but it gets me 80% of the way there, and I can review and correct the rest.

The Spotify API handles the playlist integration. Each church gets matched with their official Spotify profile when one exists.

The numbers so far

2,200+ churches listed
50 countries covered
Growing steadily through the AI pipeline and community submissions

It's still early and traffic is basically zero. But the data is there, the features work, and now it's time to get it in front of people. That's partly why I'm writing this post.

What's next

A few things on my list:

Better search and filtering. Right now it's functional but basic. I want filters for language, accessibility, denomination, and service style.
Church claiming. Let pastors and admins claim their church profile and keep it updated themselves.
More countries and languages. 50 countries is a start, but there are churches everywhere.

Check it out

If you're curious, the site is live at gospelchannel.com.

I'd love your feedback. Whether it's about the tech, the UX, or churches you think should be listed. Drop a comment here or reach out through the site.

And if you know someone who's looking for a church, maybe send them the link. That's the whole point of this thing.

Thanks for reading.