What it cost to rebuild diggs.no

On the method page I promised to rebuild diggs.no according to the doctrine, log the work and publish the result whatever it turned out to be. It was meant to give a first figure for question 3: what does an exit cost in practice, measured in hours, money and lost function, and how much of the cost can be foreseen before you start? This is the result. The cutover was made on 31 October 2026 at 23:06. Some work remains, and it is listed at the end.

What was replaced

Before the rebuild I mapped 24 dependencies in a register, with a status for each. Two of them, unused packages, were removed before the start. Of the other 22, the register now reads as follows:

Six have been replaced. Deployment moved from Laravel Forge (US) to Kamal, run from my own machine. Email from the forms moved from Mailgun (US, owned by the Swedish company Sinch) to Scaleway (France). The fonts are served from the site instead of being fetched from Google Fonts at build time. The framework, the runtime and the libraries moved from Next.js, React, Node.js and npm packages to a single program written in Rust.
Four have been removed from the site. The database (MySQL), the consent banner from CookieYes, Google Analytics and the language model the Scorecard used, Gemini.
Two remain. The server at Hetzner and the web server in front of the site. The program runs in a container behind the same web server as before.
Ten are untouched. The domain and DNS at Domeneshop, the certificate from Let's Encrypt, the code repository on GitHub, the inbox in Google Workspace, the verification with Google, the language models I work with, and three entries that belong to the old code: npm and two leftovers that were not in use. The last three will probably disappear when the old code is deleted, but that has not been recorded in the register.

The rebuild removed most of the American services, but also brought two new ties. The base images are fetched from Docker Hub, and the site's packages are stored in GitHub's registry (ghcr.io). I already used GitHub for the code. Now deployment depends on GitHub too. The architect in the agent team suggested a registry on my own server. I chose GitHub, because Diggs Music already uses it. It is a deliberate choice within pragmatic patriotism: both can be replaced without touching the site itself. Docker itself is open-source software running on my own server, and is not counted as a dependency.

What could not be moved

The plan was a new server for diggs.no, and then to cancel Forge. Three things stopped that.

The first was that the server hosted more sites than I knew. I thought it had three. It had nine in the web server configuration. Over the years I have tried out various solutions on the same server. Most were small tests of no importance, but some are in use and need a larger piece of work before they can be moved. Forge manages the web server and the certificates for all of them, so Forge cannot be cancelled until the other sites have moved. This means an American service still sits in front of the site, even though it no longer deploys the code.

The second was that the server size I wanted (Hetzner CX23) was sold out in Helsinki, Falkenstein and Nuremberg. I chose to use the existing server.

The third was the database. The Scorecard is paused and is not part of the new site, but its data is still in MySQL on the server. It will be removed when the clean-up is done.

Lost function

The site no longer has visitor statistics. Google Analytics has been removed, and nothing has replaced it. The consent banner is no longer needed, because the site sets no cookies and fetches nothing from others. The Scorecard and the admin page were deliberately not rebuilt. The contact forms work as before, with a new sender.

To check that nothing else disappeared, I took a snapshot of the whole old site before the start: every page, response headers, links, structured data and redirects. The new site was compared with that snapshot before the cutover. The comparison afterwards found 4,197 differences. All of them fall under 20 points of differences I had approved in advance, such as the new design, the new fonts and the removal of tracking. None of the differences was an error.

Time

All time is taken from the log and is measured, either with the clock in the session or with the time of a commit. The rebuild took six sessions, five of them on 31 October.

Sessions 1 and 2 are measured from start to finish: 182 and 69 minutes.
Sessions 3, 4 and 5 have no measured start. From the first measuring point to the end they are 50, 41 and 158 minutes.
Session 6, when the code was merged on 1 November, is not measured.

The total for sessions 1–5 is 500 minutes. It is a lower bound, because three of the sessions lack a start time. The figure is how long the sessions lasted, not how long I worked. For parts of the sessions I was away from the machine while the agents worked. For sessions 5 and 6 I have stated that I spent no time outside the sessions. For sessions 2 and 3 the log found no trace of work outside them, but that is an inference, not a figure I have stated. For sessions 1 and 4 there is no figure.

Money

The running costs changed little.

The Hetzner server costs the same as before: €8.49 a month excluding VAT (€7.99 for the server and €0.50 for the IPv4 address), and €10.61 with Norwegian VAT, according to the invoice for September 2026.
Forge Hobby still costs 12 dollars a month, because Forge remains.
Scaleway costs nothing as long as the forms send fewer than 300 emails a month, then 0.25 euros per 1,000.
A snapshot of the server, taken before it was changed, costs about 0.13 euros a month.
Backups of the server at Hetzner cost 20 per cent of the server price, about €1.60 a month excluding VAT. They were switched on the day after the cutover.
The registry at GitHub has not produced a cost I have seen, but this has not been checked against the invoice.

Mailgun will be cancelled no earlier than 30 days after the cutover. Its price was not in the log, so I cannot state the saving. The largest saving, Forge, only comes when the other sites have moved.

The day after

Before the rebuild there was no backup of the server. The day after the cutover I switched on backups at Hetzner, and the agents installed Monit on the server. Every two minutes Monit checks that the server has enough memory and disk, that the site responds and that the certificate is not about to expire. Every ten minutes it checks that the form has not failed to send an email. Alerts arrive by email, sent through Scaleway like the forms. Monit is open source and runs on my own server, so there is no new provider.

How the work was done

Almost all the work was done by a team of language model agents in Claude Code: an architect, a UX researcher, a designer, a developer and a quality assurer, plus a lawyer for privacy. All 88 commits in the period were made by the agents. I made the decisions, logged in where needed, and read what was to be published.

The quality assurer sent the work back several times. Three examples: the snapshot of the old site lacked links and text outside the main content. The first version of the new site had an open redirect, where a link could send visitors on to another domain. The recipe for setting up the server would have given the user that owns all the sites full control of the server, and could have restarted the database and the web server without warning. At the cutover the returns concerned only the documentation. All the findings were fixed before anything went into production.

The safety check in Claude Code stopped the agents when they were about to delete data in the production database. I ran that deletion myself. Once I asked the agents to do something my own rule says only I should do: add the DNS records for the new email service. The rule stands, and the exception is logged.

A privacy finding

Mapping the database showed that the Scorecard had stored the IP address of people who asked for an evaluation, in a handful of rows from September 2026. The privacy notice promised deletion after 30 days. The deletion only ran when someone asked for a new evaluation, and when the Scorecard was paused on 27 September, it stopped. The addresses were therefore kept longer than promised. They have been deleted, including from the backup, and an internal note has been written. The new site does not store IP addresses. Without the rebuild I would not have found this.

The answer to question 3

Documented: ten of 22 dependencies were replaced or removed in one day, with at least 500 minutes of measured session time. The running costs are nearly unchanged. The lost function is the visitor statistics and the Scorecard, which was already paused.

Inference: the most expensive part was not the code. It was what surrounded it and was not written down anywhere: which other sites shared the server, who controlled the web server, where the data actually was and for how long. What could be foreseen was the code and the content, because they were in the repository. What could not be foreseen was the server, and that is where the plan had to change. No time estimate was made before the start, so I cannot measure how well the cost could be foreseen in hours. The next exit should make one.

Caveats: this is one small site, built and rebuilt by the same person, with agents doing the work. The figures say little about what an exit costs for an organisation with staff, contracts and users who need training. The time is session time, not working time. And a site without a database and without logins is the simplest case there is.

The doctrine's assessment: measured against pragmatic patriotism the site is better, but not finished. The remaining American dependency that matters most is Forge, because it has access to the server and manages the web server in front of the site. It has a way out, but no deadline.

What remains

The old code and the database will be removed, and Forge will stop deploying the old version.
Mailgun will be cancelled no earlier than 30 November 2026.
Forge will be cancelled when the other sites on the server have moved.
A check from another server, which alerts if the whole server is down, has not been set up. Monit cannot see that from the inside.
The site is planned to be owned by a limited company instead of my sole proprietorship, probably Diggs FoU AS. The company has not been founded, and the agreements have not been made.

The rebuild is a milestone, not an end point. The ties that remain will be assessed further under the same conditions. First in the queue is GitHub, which now carries both the code and deployment, and which is on its way to becoming the largest tie. GitHub will be replaced with Forgejo, which is open source and which I run myself on my own servers.

The work continues to be logged, and the figures will be updated here when the clean-up is done.

Disclosures

I am a product lead at Akari, which sells Google Workspace. The inbox for diggs.no is in Google Workspace. The code is on GitHub. The agents that did the work run on Claude from Anthropic (US).

How this text was made

The text was written by Claude from the log, the register of dependencies and the git history. Every figure can be traced to one of them. I read it before publication.