The Foundation of Acores9

Less than a month ago, I wrote that Acores9 was my most ambitious project so far. At the time, most of the ambition was still architectural. I knew what I wanted to build: one central source of truth for information about the Azores, capable of feeding different websites, tools and future ideas without recreating the same database every time.

The theory was simple. The implementation was not.

Acores9 now exists as a working content platform. It has a custom administration system, a bilingual content model, a structured HTTP API, controlled access for AI agents, Cloudflare R2 media storage, channel based distribution and a public portal already taking shape. More importantly, it is no longer waiting for some future project to prove whether the idea works. Geoacores and Azores Surf are already online and consuming information from it.

The architecture has escaped the diagram. It is doing real work.

I am not building three websites

Geoacores is a map focused way of exploring places across the archipelago. Azores Surf is a specialised guide to surf spots, events and the local surf directory. Acores9 will become the broader bilingual portal for the islands.

They are deliberately different products.

They have different audiences, different visual identities and different ways of presenting information. Geoacores needs an experience built around a map. Azores Surf needs ratings, swell and wind information, surf levels, galleries, reviews and specialist filters. The future Acores9 portal needs news, events, islands, weather, culture, nature, history and deeper editorial stories.

What they should not need is three independent versions of the Azores.

The central platform is custom PHP and MariaDB. The consumer websites can be modern React applications running with TanStack Start, TypeScript, Tailwind and Bun. That separation is important. The database does not dictate the interface, and the interface does not own the data.

Acores9 manages the shared truth. Each vertical project decides how that truth should feel. Geoacores and Azores Surf receive their content through dedicated API clients. Credentials remain inside the production server and never reach the browser. Each client can be restricted to its own channel, so a specialised website only receives the information intended for it. This means I can improve the location model, working hours, media structure or canonical URLs once and let several projects benefit. A future project can begin with a mature information layer instead of an empty database and another admin area.

That is the part that changes everything. I am no longer building isolated projects. I am building specialised interfaces over a common regional platform.

The public websites are separate. The infrastructure is not.

Production makes this architecture even more efficient. Acores9, Geoacores and Azores Surf run on the same Hetzner server. Visitors see three independent domains, but the consumer applications do not contact Acores9 through its public URL. They connect to it internally through localhost.

The request never needs to leave the machine, resolve public DNS, negotiate another public TLS connection, pass through the external network and return to the same physical server. Geoacores and Azores Surf use the shortest possible route to the source through the server’s internal loopback connection.

The benefits are significant:

• Much lower latency between the websites and the API.

• No external bandwidth for internal content requests.

• Fewer network, DNS, proxy and TLS failure points.

• API credentials remain inside the server environment.

• Cached and uncached responses avoid a public network round trip.

• The public API remains available for authorised external tools and future projects.

Combined with server side caching inside the consumer applications, most visitors do not trigger an Acores9 request at all. When a cache refresh is required, it happens through localhost rather than making a public request back to the same machine. It is an important distinction. Centralised does not have to mean remote. The projects are independent where that independence matters: domain, design, audience and deployment. They remain physically close where distance would only add latency and unnecessary failure points.

From the outside, they are separate products. Inside the server, they behave like parts of the same platform.

Duplicate means two different technical problems

Centralising the content solved one kind of duplication and immediately created another.

The first is operational duplication: accidentally importing the same news item, event or place more than once. This becomes especially important when automated agents are discovering content. Comparing titles alone is not enough. The same event can appear on a municipal website, a venue page and a news article with three different headlines. Accents, punctuation, translations and invisible characters make naive comparisons even less reliable.

The API therefore returns recent candidates based on more than a matching title. An agent can search, inspect possible duplicates and only then prepare a draft. It is a heuristic rather than an impossible promise of perfect historical uniqueness, but it catches the kind of repetition that matters during regular imports.

The second problem is SEO duplication.

If Acores9, Geoacores and Azores Surf can all display information from the same source, search engines may encounter the same content on multiple domains. Having one database does not automatically mean there is one search result. This forced me to separate two ideas that are often treated as the same:

The source of truth for the data does not always have to be the search owner of the page.

Most shared content can be owned by Acores9, with consumer websites pointing their canonical URLs back to the central portal. But there are valid exceptions. An event created specifically for Azores Surf can remain visible inside Acores9 while declaring Azores Surf as its canonical owner. The portal stays complete. The specialist project keeps its SEO authority. Search engines receive one unambiguous primary URL.

Canonical ownership is therefore decided by the relationship between the content and the project, not by a simplistic global setting. Stable slug and ID URLs also travel through the API so every consumer can construct the same durable address. This is one of those challenges that barely exists when projects are separate. It only becomes visible when the system starts working as a real network.

Caching without creating five versions of reality

Centralisation introduces another obvious risk: every website now depends on the same API.

A badly designed implementation would turn Acores9 into a latency multiplier. Every page view would trigger several API calls, the same information would be assembled repeatedly, and one slow response could affect every connected project. So caching exists at several levels.

Authenticated API responses are cached by client, channel, route and query. Authentication is still checked before cached data is returned, preventing one consumer from receiving another consumer’s information. Writes from the admin or API invalidate the cache so published changes can propagate. The consumer applications also cache server side responses instead of contacting Acores9 for every visitor. Their public pages can then use browser and CDN caching where it makes sense.

Because the production applications communicate with Acores9 through localhost, even a cache miss remains extremely cheap. The central API performs the work once, the consumer stores the response, and subsequent visitors receive it without another API request. Even weather needed its own strategy. Forecasts for all nine islands are requested in one batch, stored for several hours, protected against multiple simultaneous refreshes and allowed to fall back to slightly older data when the external provider fails.

Caching sounds boring until it goes wrong.

During deployment, I discovered that API responses were being written into one cache directory while the admin was clearing another. The system could update correctly and still serve an older version of the truth. Worse, the unintended directory existed under the public web root. That small path error captured the entire difficulty of distributed systems. The database can be correct, the interface can say the update succeeded, and visitors can still see stale information.

The cache now has one private location shared by the API and its invalidation logic, with an automated regression test ensuring they cannot diverge again. The problem was not making the API fast. The problem was making fast information remain correct.

Acores9 now has its own AI discovery desk

Another project has grown beside the main platform: acores9ai.

It is a local discovery and drafting application for Azorean news and events. It searches for current candidates, lets me review the sources, asks Acores9 for possible duplicates and prepares a new Portuguese and English draft. It does not write directly to MariaDB. It does not bypass the platform because it happens to be an AI tool. Everything goes through the same authenticated HTTP API as any other client. The agent can discover and synthesise. The API controls permissions and validates the payload. The resulting content remains inactive until a human reviews and publishes it.

That separation is deliberate:

AI can propose. The platform controls. A human publishes.

The local application keeps its job history and source review material outside the central content database. If a discovery task is interrupted, it can resume. News and event searches can run independently. Drafts are attached to the candidate that produced them, and the final content is rewritten as an original bilingual article rather than storing copied source material. This is the kind of AI integration I find useful. It is not a chatbot placed over an admin panel. It is a bounded workflow connected to real permissions, duplicate checks, content rules and human approval.

The public portal is becoming more than news and events

The visible Acores9 portal is still only the beginning.

News and events will remain important. They make the site current, useful to residents and valuable for search visibility. I do not want to turn Acores9 into another generic tourist planner that treats the archipelago as a collection of lists and itineraries covering three supposedly perfect days. The long term portal is a showcase of the Azores.

It will be bilingual from the foundation and combine the changing islands with the permanent ones. The first Discover stories are already prepared and will be published soon. They are not simple articles with one large text field and a gallery attached at the bottom. I built a modular editorial system with eleven reusable block types: text, images, image and text compositions, galleries, carousels, facts, quotes, timelines, cards, video and related content. Stories can use different visual formats depending on the subject. A historical narrative can flow chronologically. A visual story can let photography dominate. A profile can feel intimate and resemble a magazine feature. An explainer can use tighter information panels and structured facts.

The content remains fully driven by the database, searchable, bilingual and distributable through the API, but it does not need to look as if it came out of a rigid CMS template. That balance took a surprising amount of work. The goal was not to make every page different. It was to create enough controlled variation that the subject determines the rhythm without destroying consistency.

The project in code

Lines of code are not a measure of quality, but they help communicate the difference between an idea and an operating platform.

That code covers the public portal, administration system, API, MCP server, media handling, bilingual routing, canonical ownership, caching, location hierarchy, content channels, agent drafts, surf specific functionality, story composition and the automated tests protecting those behaviours. The number itself is not the achievement. The more important part is that the foundation is reusable.

Every content type does not need a new authentication system. Every project does not need new media storage. Every agent does not receive direct database access. Every frontend does not invent a new interpretation of an island, location, event or canonical URL. The code is becoming a set of rules for how information about the Azores moves.

The next major technical area is trails

Trails should become another dedicated area in Acores9.

I do not want to force them into generic points of interest. A trail has its own structure: route type, difficulty, distance, duration, elevation, coordinates, downloadable route data, current status, safety information and relationships with locations, weather and nearby content. Once that structure exists centrally, it can power a trail section inside Acores9 and become available to future specialised projects without being rebuilt.

The more interesting possibility is how trails connect with the rest of the system. A route can belong to an island and municipality, appear inside a nature story, connect to nearby Geoacores locations, react to weather conditions and surface relevant alerts. That is where a unified base starts to compound in value. A new vertical is no longer an isolated database project. It becomes another structured layer that can enrich everything already connected to the platform. Trails will probably be connected to Geoacores as well.

The largest remaining problem cannot be solved with code

The backend can scale. The API can distribute the information. The story system can produce rich layouts. But a tourism portal about nine extraordinarily visual islands cannot survive on structure alone. It needs photography. I am a photographer, but most of my archive is from São Miguel. That is useful for one island and completely insufficient for representing an archipelago stretching across nine islands and hundreds of distinct locations, traditions, landscapes and events.

The difficult part will not be creating an empty gallery field. It will be finding the right image for every island, section and story, and doing it with real quality, permission, authorship and proper attribution. I do not want Acores9 to pretend that São Miguel is the entire archipelago. I also do not want to fill the missing areas with random photographs simply because they are available.

To become the portal I imagine, it will eventually require contributions from across the Azores: photographers, residents, cultural organisations, event organisers and people who understand their own island better than I ever could from São Miguel. That will be a long process. Code can give those contributions a consistent structure. It can preserve credits, copyright information, locations and bilingual context. It cannot manufacture authentic coverage of an archipelago.

The data problem is technical. The visual truth requires people.

The real future of Acores9

Acores9 is still a huge work in progress, but the risk has changed.

A month ago, the question was whether building one central platform for all these ideas was realistic. Today, the architecture is running, two independent websites are consuming it, the AI workflow can prepare controlled drafts, and the richer public portal has a foundation. Now the challenge is depth. More information. Better imagery. Stronger coverage across every island. Trails, culture, gastronomy, nature, history and traditions presented with enough editorial and visual quality to make people want to keep exploring.

The system also has to remain simple enough that it can keep growing without collapsing under its own ambition. Every new vertical should improve the shared base. Every correction should benefit more than one project. Every future idea should begin further ahead than the one before it. That is the real value of a unified platform. I am not trying to build one enormous website that does everything. I am building a regional information system that allows several focused projects to become better at what makes each of them unique.

Geoacores can remain the map, Azores Surf can remain the surf guide and Acores9 can become the living bilingual showcase of the archipelago. Whatever I build next will not have to start from zero. That was the ambition in the first article, and less than a month later, it is already starting to work.