Eighteen hours.
A real portal in production.

01 / Out into production

The next requirement came with a history.

Our first observation examined a small public website. The second added a shared server runtime and a first GraphQL query. The next step was to put that foundation to work on an established product.

Pivkarta — the Beer Map is a portal for discovering beers and the venues connected to them. It already had a database, photographs, articles, profiles, comments, and years of public addresses. Rebuilding it meant understanding that history as well as creating a new interface.

We cloned the HAIH site and added the application-specific backend and frontend. Eighteen hours later, the rebuilt public experience was in production. That is the development window recorded by the project owner, across roughly two days, building on the existing HAIH foundation and Pivkarta’s content.

For this project, 18 hours from an existing foundation to a rebuilt portal in production is a very encouraging result.

Visit Pivkarta ↗

02 / The scale of the job

Thousands of records. One existing database.

The migration inventory contained 1,636 beers, 3,797 venues, 600 articles, 64 cities, 3,296 comments, and 26,548 public profiles. These are content records, not traffic figures or active-user counts. Publication rules still exclude material that should not be public.

We kept the existing MySQL database. Knex gives the new backend access to its actual tables and relationships. The GraphQL API provides lists, filters, counts, pagination, and connections between users, venues, beers, and assortment records. Apollo Client and typed operations provide the frontend integration that the previous field note left open.

The public pages also use server loaders. Their initial HTML contains useful content and links; the homepage is prerendered, while dynamic pages are rendered at request time. The architecture grew to accommodate the data instead of requiring the data to fit the original demonstration.

03 / What the visitor gets

Start with a beer. Follow the connections.

The new homepage leads with beer search, real product photographs, and a small editorial selection. A visitor can read about a beer without choosing a city, then follow its connections to venues. Bars, shops, breweries, publications, profiles, and comments remain part of the same site.

That distinction matters with historical data. A relationship between a beer and a venue does not prove it is on sale today. The interface avoids turning old assortment information into a promise of current stock.

The shared layout and homepage establish the new visual direction. The remaining sections have working public pages; their individual design can continue to develop. This release covers reading and discovery. Authentication and authoring forms remain outside its scope.

04 / The work behind the redesign

An old link is still someone’s entrance.

Many of the interesting problems were invisible on the homepage. Old addresses used numerical IDs, several route shapes, city prefixes, and slugs containing quotes, ampersands, Cyrillic characters, or capital letters. Regenerating every slug from a title would have been an easy way to lose useful links.

We built a registry of 73,760 canonical and historical addresses. During implementation, a complete HTTP pass against a local production build matched the expected status and target for every entry. Old routes lead to the corresponding object, with permanent redirects where needed. Unknown records retain a real 404 response.

That full pass predates the final route and sitemap adjustments, which received targeted checks. It is evidence of the migration work, not a claim that every external link on the internet has been found or that every production request has been tested.

Content needed similar care. Draft.js, Markdown, and permitted HTML now retain supported links, images, headings, lists, and galleries, with server-side HTML sanitization. Authors, venue owners, comments, and old section anchors remain connected to their subjects.

05 / Small discoveries with real consequences

The details decided whether it worked.

A city ID was not a shared identity. The old city and venue tables did not use matching city identifiers. The new geographic selection uses a disclosed 50 km radius around a city center. Reading the old schema and behavior mattered more than assuming similarly named fields meant the same thing.

The first sitemap page could disappear into its own index. A canonicalization rule removed page=1. That is useful for an ordinary first page, but wrong when the parameter identifies a specific XML batch. The sitemap index now preserves that distinction.

Image preparation paid off immediately. The five homepage images went from about 3.90 MB to 153 KB, a 96.1% reduction in file weight. Real beer photographs were retained, and editorial illustrations were marked as illustrations. The application also gained image resizing through Sharp. We have not converted this asset-size result into an unmeasured claim about page speed.

Some broken links were already broken. The audit separated missing source images and dead historical links from migration regressions. A redirect to unrelated content would have hidden the symptom while losing the meaning.

06 / What this tells us about HAIH

A useful foundation can change its job.

The strongest result is how quickly the existing work could be adapted. The shared runtime, routing, styling, and delivery setup provided a starting point. The new project then acquired the database access, domain relationships, image handling, and compatibility rules it needed.

This is the direction described in our introduction to HAIH: giving AI agents useful engineering context about requirements, decisions, and verification. Here, that context and a working codebase helped turn an established portal into the next concrete experiment.

The 18-hour window is one project’s outcome. We already had the content, database, a working foundation, and an owner who could make scope decisions. It does not establish a universal productivity multiplier. It does give us a much more substantial case than another demonstration page.