September at AiVikings.ai - building in public

September: I wrote five promises down. Here is how it went.

It is Saturday. Before I go and celebrate 12 years since my wife and I started dating :), I am taking a look back at everything we did in September.

There is a reason I do it in public. At the end of August I published a list of five things AiVikings.ai would do next. That is a risky habit, writing things down where people can see them, because people can go back and check. And some of you do. I know, because it is exactly what I would do myself.

So let me check, before anyone else gets to it.

The five promises

1. Crypto payments

Done

The integration with Nicky.me is live, and on 14 September I paid with crypto myself to see if it really worked. It did (and yes, there were exclamation marks when I told Markus). You can now top up your account with Bitcoin, USDT or USDC. You might ask why we bother with crypto at all, and the answer has two parts. I want our clients to have as many ways to pay as possible, and to pick the one that suits them. And paying with crypto simply costs a lot less in fees than paying by card. If a client prefers that and saves money on it, who am I to stand in the way?

2. Support through Telegram

Done

There is now a live chat on the website and inside the dashboard, and it goes straight to our Telegram, where a real person answers. I vibecoded it myself, which is a story I will come back to further down. The original plan was the dashboard only. But think about when you actually have questions about a product. It is before you sign up, not after. And at that moment you should get a person, not a form.

3. WHMCS module

Done

It is in the WHMCS Marketplace, and it has its own module page on our site for hosting companies. The thinking here is not complicated. Hosting companies already run their whole business in WHMCS, and I am not going to ask them to learn a new system just to sell our domains. So we went to where they already are.

4. Better billing

Partly

Quick top-ups, more payment methods, automatic currency conversion and invoice syncing all shipped. The nice branded invoice PDFs did not, and they move to October. That order was on purpose, by the way. Being able to pay comes before the receipt looking nice.

5. An EPP endpoint

Not done

I could give you a long explanation, but the short one is better. EPP is the protocol that larger registrars and resellers expect, so it matters, and I have not forgotten it. But it is also a new door into the system, and I did not want to open a new door before the ones we already have were properly tested. So the testing came first, and EPP moves to October.

That makes three and a half out of five. I have had worse months. I have also had better ones, to be fair, but I would rather give you the real number than a nice one.

The work nobody takes a screenshot of

You know how it is when you renovate a house. The money goes into pipes and wiring, and when the guests come round, nobody says a word about the pipes. September was a pipes-and-wiring month.

Markus and I went through the whole MCP server, all 21 tools, one by one. We found several bugs, and we fixed them. It is not a headline. But here is the thing about agents: an agent is not a person. A person who hits a bug shrugs, tries again, or writes to support and complains. An agent either stops or, which is worse, carries on and does the wrong thing with someone's money. So when nobody is watching, there is less room for sloppiness, not more.

The server also grew while we were at it. It went from 21 tools to 31, and most of the new ones are about DNS: listing the records on a domain, adding new ones, changing them and deleting them. I will be the first to say that DNS is not exciting. But think about what an agent is actually trying to do. Registering a domain is only step one. A domain that points nowhere is just a name on a receipt. The agent also has to point it at the website or the service it is building, and if it cannot do that itself, it has to stop and wait for a human to log in somewhere and click. Then it is not much of an agent anymore. So now it can do the whole job, from finding the name to having it point at something that works.

The rest of the engine room got the same treatment. Pricing, availability checks and premium-domain handling all got better, and domains in pending transfer now sync properly. And one small thing I am quite pleased with: when someone starts a signup and does not finish it, we can now see it. Before, those attempts simply disappeared, and with them a person who wanted to become a client and got stuck somewhere. Now we can help instead.

And then there was the bug. I have to tell you about the bug. A client paid with crypto, the payment went through, and our system insisted the invoice was still open. So we went looking. It turned out the amount we received and the amount we expected were different in the eighteenth decimal. One digit, at the very end of a very long number, and the system flatly refused to call it paid. (Technically it was right. That did not make the client any happier.) It was fixed the same day, and open invoices are now checked again automatically. I tell you this because it is what building a payment system actually looks like, and anyone who says otherwise has not built one.

Two things from the engine room are worth a closer look if you build on us.

• A public pricing API, with documentation. An agent can ask what a domain costs before it buys, and it gets a clear answer when a TLD is not supported. This one came from a client. He asked if he could check prices over REST, because until then it only worked over MCP, and I promised him it would be there within a week. It was. And he was right to ask. Price is a large part of why people choose us, so it should be something a machine can verify, not something you have to take my word for.
• Read-only API access. You can now give a script or an agent access to look at your account and your domains, without giving it access to change anything. Most people want to see what an agent does with their portfolio before they hand it the wallet. I would too.

The domain checker on the website also got clearer. It now tells you plainly when a domain is taken and when it is a premium name.

What I built myself

Now to the part I have been looking forward to. I vibecoded things this month. For those who have not tried it: you describe what you want to an AI, it writes the code, and then you test and complain until it works. It is surprisingly close to managing a developer, except that it never gets tired of me.

The first thing is the Telegram chat from the list above. A visitor or a client writes in the chat window, on the website or in the dashboard. The message shows up in our Telegram, we answer from there, and the answer appears back in the chat. A year ago I would have bought a support tool with a monthly fee and forty features I did not need. This time I built the one feature I do need, on my own.

Before anyone gets nervous, I have one rule. What I vibecode stays outside the production environment. The registrar itself, the part that handles your domains and your money, is built and tested by our developers, and it will stay that way. A chat window is a fine place for a founder to experiment. The connection to the registries is not.

The second thing is an internal dashboard. It shows every client in one place: domains, status, top-ups, payments, invoices. And it sends me a Telegram message every time someone signs up, tops up or registers a domain.

It is not pretty, and it was never meant to be. I could of course have asked Markus to build it. But he has more important things to do than making a tool that only I will ever look at, and honestly, I wanted to see if I could do it myself. It turns out I could. More or less. What I get out of it is that I know what is happening in my own company without asking someone to look it up. And the alerts are there because at this stage every new client matters. I want to know the moment someone arrives, so I can help if they get stuck.

The third thing is the one I am most pleased with, and I will allow myself to say that I think it is extremely cool. It is called "Vote for a TLD", and it sits on the website. If there is a domain ending you want and we do not have it, you vote for it.

Let me explain why it exists. We offer 650 TLDs today. That sounds like a lot until you remember how many there are out there, and every one of them has its own registry, its own rules and its own way of doing things. We cannot add them all at once. We are three people. So somebody has to decide which ones come next, and I could of course sit here and guess. I have guessed before. I was not always right.

It is better that you decide. If enough of you ask for the same TLD, it moves up the list, and that part of our roadmap is now driven by the people who actually pay for the domains. That seems to me the right way round.

And because a vote nobody counts is not worth much, I vibecoded a page in my internal tools where I can follow the votes as they come in. So when you vote, it does not disappear into a database. It lands in front of me.

We are three now

Asad joined in September as our second developer, working alongside Markus. I know that going from two people to three does not sound like much. For a team our size it is a big step.

We are growing fast, and the list of tasks is growing just as fast, and at some point you have to admit that two people cannot do it all. What I like about Asad is that he knows this industry. He does not need the domain business explained to him before he can start. For a small team, bringing in a strong person with that knowledge matters a great deal, and we already feel the difference.

So, Asad: welcome. Properly welcome. We are very glad you are here. I have already put more on your desk than it is polite to give a new man, and you have not complained yet. I choose to take that as a good sign.

The website

The site kept growing. We added landing pages for ChatGPT users, guidance on connecting ChatGPT, and a walkthrough for renewing a whole portfolio in one go. But the biggest job on the website deserves its own section, so here it comes.

The TLD pages, and why I refused to make them boring

Every registrar has a page for each domain ending it sells. One for .com, one for .icu, and so on. And let us be honest about why, because nobody else will be. These pages exist to attract traffic. People search for a TLD, AI models look for facts about it, and the registrar with a good page gets found. That is why we build them too. I am not going to pretend it is a public service.

But have you ever actually read one? Go and try. They are painfully boring. The same three paragraphs, with the name of the TLD swapped out, and a button that says "Get your domain today". Nobody learns anything, and nobody reads to the end. I am not sure the people who wrote them did either.

I wanted something different. My thinking was that if a page is there to be found, it should also be worth finding. So each of ours has its own headline, its own angle, and real facts about that TLD. And every fact has to point back to an official registry source. If we cannot show where it comes from, it does not go on the page.

That is a lot of work per page, and we sell a lot of TLDs, and I am one man with a Saturday. So I did not write them by hand. I vibecoded a small factory instead. It has three parts.

1. The collector. An agent that goes out and gathers data about each TLD from many different sources. It organises what it finds in a JSON file per TLD. Think of it as a fact sheet a machine can read.
2. The page machine. It takes the fact sheet and produces the finished page: the text, the structure, and the markup that search engines and AI models read. Before anything is published, the page has to pass a set of validation gates. A page with a missing source is stopped. A page that passes is pushed live.
3. The control room. A small tool in my browser where I can see every page and keep track of it. I can open the fact sheet for a TLD, correct it, and add to it.

That last one matters more than it sounds. Sometimes a registry tells me something directly that is not published anywhere. Now I have a place to put it. And that is how a page becomes better than what a machine could put together on its own.

Now, a factory that can write pages on its own can also write nonsense on its own, and at some speed. So before the page machine is allowed to turn anything into a page, the fact sheet has to get past a set of gates.

Every fact must come with its source, and the source has to be the official registry, not a blog that copied another blog. A fact without evidence is not softened or reworded. It is thrown out. The fact sheet also has to be complete, so the page does not quietly fill a gap with something that merely sounds right. And there are editorial rules for the text itself: what we may claim, what we may not, and how it should sound.

Only when all of that is passed does a page get built. If one gate says no, nothing is published, and I get to find out why in the control room. I would rather have a page missing than a page that is wrong.

You could ask why it has to be three parts and not just one. The answer is that facts and words should be kept apart. When a registry changes a rule, I change one line in the fact sheet and the page follows. I do not have to rewrite anything.

And yes, before you ask, this follows my rule from above. These are pages on the website. None of it touches the registrar that handles your domains.

Is it perfect? No. Some pages are better than others, and I will keep adjusting. But I have read them without getting bored, and in this category that is saying something.

Started, not finished

Three things are under way, and it would be dishonest to call them shipped. So I will not.

The first is Hugin, our next availability checker. It is named after one of Odin's two ravens, the ones that flew out every morning and came back with news of the world (with a company name like ours, you take the ravens where you can get them). Hugin combines registry checks, DNS, RDAP and cached zone files, so an agent gets an answer it can trust. It is early, but it is real.

Let me explain why we are building our own. The availability check is the first step in every registration. If that answer is wrong, everything after it fails, and an agent has no gut feeling to tell it something is off. Today we depend on our upstream partner for that answer. In September I saw prices and availability drop out now and then, and when Asad tested it, he found the same. The cause was upstream, not with us. But a client does not care whose fault it is, and frankly neither does an agent. So I would like us to depend on ourselves.

The second is a new middleware layer that handles the communication with the registries in the background. Nobody will ever see it, and if we do it right, nobody will ever need to. It exists because registries do not always answer right away. A transfer can take days, and the registry tells you about it when it suits the registry. Someone has to keep listening, and that is what this layer does. It is also built to handle more than one registrar and more than one registry, which is what will let us offer more TLDs later.

The third is an audit log. The idea is a history of every change made to a domain: what happened, when, and who did it, whether that was a person, an API key or an agent. I got the idea from the brand protection world. People who manage many domains for a company get asked "who changed this, and when?", and today they often cannot answer. A first test version exists. It is not finished, so it goes on the list for later and not on the list of things done.

October

Here is the list for next month. Written down again, so you can check again.

• The EPP endpoint I owe you.
• Branded invoice PDFs.
• Hugin in a state where clients can use it.
• More practical examples for developers building agents.
• Getting AiVikings.ai listed in the ChatGPT and Claude directories.
• The audit log, finished.

That is six promises this time. We will see in a month how that number looks.

If you want to follow along, create an account and you will get these updates by email. And if you think I have the priorities wrong, tell me in the chat on the website. It ends up on a phone, and someone will answer. It might even be me.