When an editorial section grows next to a small product, almost any structure feels good enough. You publish one entry, then another, add a chronological index and keep moving. The cost of mixing formats stays hidden because there is not much to mix yet. That is exactly how Blupoli’s first Journal worked. It was a reasonable place to explain how the project was growing, document a technical change and occasionally announce something important for people using the site. The problem appeared when those three use cases stopped being occasional and became three separate editorial tracks.
The same surface ended up containing an article about puzzle-engine architecture, a guide to a specific game, a brand update, a piece on internationalisation, an onboarding story, an announcement about language support and a diary-like entry about what we learned while rebuilding a game. All of it was “content about Blupoli”, but it did not answer the same reader intent. Someone looking for product news had to cross implementation details. Someone interested in the development process found marketing-shaped pieces in the middle. The more we wrote, the less obvious it became what the Journal was supposed to be.
The recent redesign started as a visual request — make the blog less chaotic, add images, improve the structure — and turned into an editorial product restructuring. The conclusion was easy to state and much harder to implement: Blog and Devlog needed to become two different surfaces.
Separate by intent, not by implementation
Our first important decision was to avoid classifying content by how it happened to be created. We could have split “automatic posts” from “manual posts”, “long articles” from “short updates”, or “puzzle content” from “infrastructure content”. None of those categories solved the core problem. What mattered was the intention a reader brings when opening the section.
The Blog should answer public-facing questions: what changed in Blupoli, what product is new, why a part of the website was redesigned, which puzzle deserves a deeper explanation, what version or feature we want to introduce. It is a brand and product publication. It can be technical when the story benefits from technical context, but following implementation details should never be a prerequisite.
The Devlog serves a different kind of curiosity: how was it built, what went wrong, what decision did we make and why, what trade-off appeared, what did we learn from auditing an engine, how did the repository or pipeline change? It is development memory. It does not need to disguise itself as an announcement and it does not need to turn every technical problem into a marketing benefit.
That split lets us write better because every article knows the promise it is making.
The same change can have two useful readings without becoming two copies of the same article.
“Devlog” had stopped helping
For a while we used “Devlog” as the label for everything that exposed the process. Conceptually it fit: we wanted development to be visible. As a public section name, however, it had two problems. First, it described a philosophy more than a content format. Second, it introduced English terminology that required explanation exactly where we wanted navigation to become simpler.
“Devlog” works better. It is short, familiar in software culture and directly communicates that this is a development diary. In Spanish we can clarify it as “diario de desarrollo” when useful, but the visible name remains compact. It also allows “Devlog” to survive as a principle or historical phrase without carrying the burden of being the navigation label.
There was a practical complication. The repository already contained filenames, scripts and structures created around the previous terminology. Renaming everything in one move would increase risk without creating much user value. We therefore drew a line between public identity and internal compatibility. Visitors see Devlog. Some legacy files may still be named devlog.json while we complete a safer migration. That temporary mismatch is intentional rather than accidental.
We did not want a clean structure at the cost of losing 51 posts
The editorial split happened after we had already published a meaningful body of work. Starting over was not an option. Every article had a URL. Some were linked from other posts. Some could already be indexed by search engines. All of them formed part of the project’s history. The redesign needed to classify and improve content rather than erase it.
That turned the work into a migration. Articles were grouped into Blog and the former devlog categories according to their actual intent. The editorial index began expressing those categories explicitly. At the same time, build scripts had to preserve routes that already existed, generate new editorial surfaces and prepare redirects where public architecture was changing.
Our rule was to avoid one giant break. If someone had bookmarked a technical story, the link should continue to work. If an old post linked to another, we did not want a forest of 404s simply because our taxonomy improved. Editorial architecture should be able to evolve without pretending that the publication was born yesterday.
Cover images became mandatory instead of optional decoration
One of the old Journal’s most obvious problems was visual. A long list of titles, snippets and dates works when there are only a handful of entries. With dozens of posts it becomes a wall of text. It is difficult to scan, difficult to remember and difficult to distinguish a technical story from a guide or a product announcement.
That is why cover images became a requirement. Not as random decoration, but as part of each story’s identity. A cover can show the technical flow behind a change, borrow visual language from the puzzle being discussed, contrast two system states or summarise a product shift. Its job is to help a reader recognise the article before reading the full headline.
The build now has validation around those images: presence, metadata, alt text and consistency across editorial surfaces. We also started treating infographics as real content. In a technical story, a state diagram can communicate more than several paragraphs. In a guide, a mechanic diagram can eliminate an abstract explanation. Visuals stop being a cosmetic requirement and become documentation.
Shared chrome matters more when Blog and Puzzles have different jobs
Splitting surfaces creates another risk: each one can start looking like a different website. We could already see hints of that in the project. Logos were duplicated, headers had small variations, footers used different treatments and button styles slowly drifted apart. If Blog, Devlog and Puzzles are going to serve different purposes, the shared identity needs to become more consistent rather than less.
Recent commits address exactly that layer. The logo becomes a shared asset instead of being repeated as slightly different inline marks. The blog header uses the same brand language as the rest of the ecosystem. The footer follows the same direction. Components can still expose different destinations — Puzzles needs product actions a Blog does not — but logo treatment, navigation shape, visual states and the overall feel should clearly belong to one family.
This distinction between “same component” and “same content” matters. Reuse does not mean every header has exactly the same links. It means we stop redesigning the identity from scratch for every application.
The editorial redesign needed build logic, not only CSS
We could have created two index pages and filtered cards in the browser. It would have been quick, but it would have left the separation at the shallowest layer. We wanted Blog and Devlog to exist as real concepts inside the pipeline, with explicit categories, navigation, metadata and generation rules.
That is why the repository now contains scripts for editorial architecture, metadata normalisation, visual generation, route migration, SEO finalisation and quality gates. The build no longer just copies HTML. It interprets which editorial family an article belongs to, completes metadata, builds derived surfaces, links resources, normalises names and checks invariants before publication.
There is an obvious cost: more scripts create more things to maintain. We try to offset that by keeping their responsibilities narrow. A script that normalises the public Devlog name should not decide canonical SEO rules. A script that generates cover art should not rewrite routes. Small responsibilities make future migration less dangerous and make temporary compatibility easier to remove when it is no longer needed.
SEO turns editorial structure into real architecture
An editorial section does not change names only in navigation. Search engines know URLs, titles, canonicals, structured data, sitemaps and language relationships. If we move a story without updating those layers, the site can end up exposing competing versions or declaring a route canonical even though it no longer represents the public structure.
The restructuring added stronger checks for canonical URLs, Open Graph, Twitter cards, publisher identity, BlogPosting data and metadata that used to be inconsistent. Branding validation also became stricter so old browser titles do not keep surfacing a name we no longer use publicly. Blog localisation continues to require the same slug, date and author across language versions.
This matters even more because Blupoli Puzzles supports six languages. We do not want to “solve” translation by publishing the Spanish body under an English URL. When an article has an English version, it should be a real editorial translation and the build should publish language-specific canonicals and reciprocal hreflang. If it does not have one, we would rather expose that honestly than manufacture duplicate content.
Blog and Devlog needed different writing contracts
Technical architecture only solves half the problem. We could separate routes perfectly and still write the same kind of article in both places. To prevent that, we created two editorial skills: write-blog and write-devlog. They are not decorative prompts. They are publishing contracts.
The Blog skill asks for a public voice: natural, useful and capable of discussing product, brand, news or guides without turning into corporate copy. The Devlog skill requires repository evidence, concrete decisions, trade-offs and honesty about unfinished work. Both require complete Spanish and English editions, a cover, one or two infographics, internal links, a dedicated SEO pass and a final quality loop.
The most important difference is what they reject. A Devlog cannot invent an interesting failure just to make the story more dramatic. A Blog should not be a technical changelog with a friendly headline. Both formats can cover the same underlying change, but they must do so from genuinely different angles.
Publishing is no longer “save some HTML”. It is a chain of evidence, editing and validation.
Dates are part of the story too
Another issue with the old content was temporal. We had created or reworked many pieces in a short period and several ended up with nearly identical publication dates, even when they described work spread over weeks. The result looked as if the publication had appeared overnight. More importantly, it weakened the Devlog’s value as a record.
The fix is not to invent dates. It is to reconstruct chronology from real work and use editorial dates consistently. Some stories belong close to the moment a decision was made. Others are retrospectives written later and should read like retrospectives. What matters is that the calendar should not be an accidental side effect of the day a migration script happened to run.
We want the Devlog to be readable as memory a few months from now. A reader should see a progression: catalogue expansion, scale problems, shared onboarding, audit waves, brand restructuring, and now a quality-over-quantity publishing model. Dates help that narrative remain legible.
Cards needed to communicate more with less
On an editorial home with dozens of entries, every card competes for attention. When all cards have the same weight, the reader ends up scanning titles line by line. The new layout uses imagery, category, typography, excerpt length and spacing to create a more readable hierarchy. The goal is not to make the site look like an overloaded magazine. It is to make the type of story obvious at a glance.
The Blog can highlight a major product story and group guides or releases around it. The Devlog can prioritise a recent architecture or process story while keeping older entries available by category. Taxonomy stops being a backend classification and becomes part of navigation.
We also want covers to have enough identity that the grid does not look generated from a single template. A gradient and a generic icon on every post would technically satisfy an image requirement while failing the design goal. The visual system can share type, composition and palette, but each article should contain a semantic element that makes it recognisable.
Separating Blog and Devlog does not mean isolating them
One of the most important editorial decisions is to cross-link the two surfaces. When a product announcement has an interesting technical story behind it, the Blog can send curious readers to the Devlog. When a Devlog explains a decision that is already visible in production, it can link to the public article or directly to the product. This lets us avoid writing one impossible piece that tries to satisfy everyone at once.
Links also connect older articles. A piece about engine architecture can point to a concrete game audit. A responsive-design story can connect to the latest shared header and footer work. A product announcement about “coming soon” states can link to the Devlog where we explain why repository presence stopped being equivalent to publication.
This network matters for both reading and SEO. A useful editorial archive is not a chronological pile. It is a map of decisions and themes where every new story gains context from the ones around it.
The brand was scattered through the HTML as well
The migration from Blupoli Puzzles to Blupoli exposed another weakness. We had changed the conceptual identity, but old references still survived in titles, labels, scripts and fragments of HTML. Some were historical and should remain. Others were simply leftovers.
The newest commits complete a broad clean-up: Blupoli for the umbrella brand, Blupoli Puzzles for the product, consistent browser titles and metadata, and a build-time guard that catches legacy branding in places where it should no longer appear. This kind of validation sounds excessive until a project has enough surfaces for an old string to reappear months after a rebrand.
The lesson is similar to catalogue counts: any value tied to global identity should have a source of truth and a regression check. Repeating it manually across fifty pages works until it very suddenly does not.
The mobile footer reminded us that “shared” does not mean “solved”
During the wider redesign we also found a very concrete problem: the footer was not appearing correctly on mobile. It is a good example of how a large structural change can expose small failures that still matter across the whole experience. The footer contains secondary navigation, the path back to the main brand site, product links and the visual ending of a page. If it disappears on a narrow screen, the information architecture becomes incomplete exactly where simplicity matters most.
Redesigning it meant looking at more than colour or link count. We had to consider responsive behaviour, its relationship to the brand, and consistency between the main host and Puzzles. The long-term direction is for header and footer to become shared chrome: adaptable to context, but not independently reinvented inside every application.
This work does not have the novelty of a new puzzle mechanic, but it reduces the feeling that someone is jumping between unrelated websites. In a subdomain-based ecosystem, those seams are the part people can actually feel.
Observability belongs in the same conversation
The editorial restructuring coincides with another cross-cutting change: Firebase Analytics and a layer of web error observability. These are not Blog features, but they affect how we will learn whether the redesign is working. Many navigation decisions have so far been made by manually reviewing the interface and reasoning about likely flows. That remains important, but we can now complement it with consent-aware signals about how the public surfaces are used.
The integration is designed around consent and CSP rather than treating analytics as an excuse to relax security. The build injects the shared observability layer into both sites, and policy changes are limited to the services actually used.
Over time, this can help answer editorial questions with real evidence: whether readers move from Blog to Devlog, which categories are actually explored, whether certain articles become catalogue entry points, and which internal links see little use. We do not need to instrument every gesture. We need enough information to validate structural decisions.
What is still unfinished
The restructuring has moved far forward, but we do not want to describe it as closed. Some internal legacy names still exist. The blog still lives inside the current infrastructure while Blupoli’s broader architecture prepares clearer boundaries between blupoli.com, puzzles.blupoli.com and future surfaces. Some older posts still need better translations or richer visuals. Taxonomy will keep changing as we publish more real content into each category.
There is also work to reduce transitional scripts. A healthy migration accumulates compatibility for a while and then removes it. If we still need every normaliser we have today a year from now, that would mean a temporary phase turned into permanent architecture. That is not the goal.
The useful difference is that direction is now clear. We know what the public sees, what exists only for compatibility, what is generated and which source of truth governs each surface.
Publishing has become part of the product
This may be the biggest conceptual shift. Content used to sit around the product. Now publishing is one of Blupoli’s products. It has navigation, identity, quality rules, localisation, SEO, assets, a build pipeline and an audience with its own needs. That justifies treating it with the same care we apply to a game or a landing page.
That does not mean publishing for the sake of volume. In fact, the new writing skills make the bar higher. A long-form article should have a story worth the length, proper editing in both languages and visual material that explains something. The intention is to reduce shallow content, not generate more pages.
Blog and Devlog give us a structure for doing that without mixing voices. The Blog can be clear, visual and product-oriented. The Devlog can go deep into architecture, debt, tests, decisions and limits. Together they tell the Blupoli story better than one stream trying to do everything.
What we learned by restructuring memory while still building
Doing this migration while other changes were happening — branding, domains, catalogue state, audits, responsive design and analytics — had an unexpected benefit. It forced us to test whether the editorial architecture could survive a moving project. A taxonomy that only works while everything is still is not useful for a Devlog.
We needed to publish a product story about upcoming games while also being able to write a technical post about how that state was implemented. We needed to discuss visual redesign without losing the build details that migrated existing posts. We needed to use Blupoli as the current brand without erasing the historical period when Blupoli Puzzles really was the product name. Those tensions were a useful stress test.
The answer was not to create endless new categories. It was to define boundaries more clearly and then connect them. A good editorial system does not remove the project’s complexity; it lets readers choose how deeply they want to enter it.
What a reader should notice — and what should stay invisible
If we do this well, most of the architecture should disappear. Someone opening the Blog should see a clear, attractive publication that is easy to browse. Someone opening the Devlog should immediately understand that they are entering the workshop behind the product. Logo, navigation and visual behaviour should make it obvious that both belong to Blupoli. Links should work. Language should persist. Images should load. None of that needs to expose how many scripts are involved.
The technical layer exists so that simplicity is sustainable. So adding an article does not require remembering twenty metadata fields by hand. So a translation does not accidentally publish the wrong canonical. So a missing cover fails before deployment. So an old brand reference does not creep back into a browser title.
That is the kind of infrastructure we like: the better it works, the less visible it becomes.
One publication, two front doors
The previous model tried to use one entrance for every story. The new model accepts that there are two. The Blog is where you follow Blupoli as a product and a brand. The Devlog is where you follow how we build it. Both can cover the same month, even the same underlying change, but they should not answer with the same article.
At the same time, we are strengthening the relationship between editorial content and the catalogue. A game article should lead to play when the game is published, or clearly explain that it is upcoming when it is not. A design story can link to the surface where the change is already visible. A technical entry can connect to earlier decisions to create a chain of context instead of an isolated post.
If you want to follow the roots of several decisions described here, continue with the transition from Blupoli Puzzles to Blupoli, the work that turned infographics into real editorial content, and our experiment using Git as raw material for the Devlog. If the other major change of this phase is more interesting to you, Quality before quantity explains why the catalogue is also moving from growth by count to growth by completed audits.
This separation does not finish the editorial area. It makes its next phase possible. Every new story now has a clearer home, each surface knows what it promises, and the publication can keep growing without collapsing back into the mixture that forced us to redesign it in the first place.