What logging should a new ISP have in place from the first day?

Three things before the first customer connects: translations being written out somewhere other than the device doing them, one identifier for each subscriber that every system agrees on, and clocks that all read the same. Everything after that is refinement, and everything before it is guesswork.

Why is the first day the cheapest moment to do this?

Because nothing is running yet. No maintenance window, nobody to notify, no risk of interrupting a customer who is on a call, and no arguing about whether a reboot can wait until Sunday.

Retrofitting the same arrangement onto a live network is not technically harder. It is organisationally harder, which in practice is the same thing. Someone has to plan the change, someone has to approve it, and it happens at two in the morning because that is when the traffic is lowest.

There is a design freedom as well that quietly closes. Right now you can choose your addressing, name your interfaces, and decide how customers are identified, all without migrating anything. Six months in, each of those choices has become a convention that other things depend on, and changing one means finding all of them.

What has to be running before the first customer connects?

A record of translations leaving the network and landing somewhere they can be searched. That is the whole of it, and it reduces to five values per record.

Those five are not a house preference. They are close to what the industry standard for large scale translation sets out as the information needed to identify a subscriber later, and any arrangement that captures them will answer the questions that eventually arrive.

Two practical points sit alongside. The records need to survive the device that produced them, because a router that reboots, fails or gets replaced takes everything held locally with it. And they need to be searchable by somebody who is not you, which mostly means they should not require a login to a production router.

One more thing belongs in this first pass and is usually left until something goes wrong: deciding who is allowed to look. Two named people with search access, written down somewhere that is not a chat message, is enough on day one and settles a question that becomes awkward once there are twenty staff.

Which decisions taken now are expensive to reverse later?

The ones that become conventions. A convention is not hard to change in itself, it is hard to change because a dozen other things quietly assumed it.

Choices that cost minutes now and weeks later

The choice	What it costs to change once customers are on
How subscribers are identified across billing, authentication and the network	Every historical record now needs a translation step that somebody has to maintain
The internal addressing plan and how it is divided by area	Renumbering live customers, in stages, with no benefit anybody can see
Interface and device naming	Old records refer to names that no longer exist, and only one person remembers the mapping
Where records are sent and who holds them	A migration, plus a period where the history sits in two places in two shapes
Whether the time is stored with its offset	Everything already stored stays ambiguous, permanently, and cannot be fixed afterwards

The last row deserves its own moment of attention, because it is the only one on the list that cannot be repaired at any price. A record written without knowing which offset it was written in is a record nobody can place on a timeline with confidence, and no later effort recovers that.

Why does the subscriber identifier matter more than the address?

Because subscribers stay put while addresses circulate. Every question you will ever be asked is about a person or an account, and the address is only the route back to one.

The trap is that three systems each invent their own way of naming a customer. Billing knows an account number, authentication knows a login, and the network knows an address it handed out this morning. Where those three do not join up cleanly, every single trace needs a human to bridge them, and that human will not always be available.

Deciding this on day one costs nothing. One identifier, chosen once, carried into the authentication system and visible wherever records are written. New networks that settle it early answer a request in ten minutes. Networks that did not find that it takes a day and involves a spreadsheet somebody made privately.

There is a second benefit that shows up sooner than any request does. Support tickets, usage complaints and abuse reports all become answerable by the same lookup, so the work you did for a legal obligation pays for itself in ordinary operations first.

None of this requires the identifier to be clever. An account number is fine, a login is fine, and anything stable and unique will do. What matters is that one of them is chosen rather than three of them being allowed to coexist because nobody thought it mattered.

What does the clock have to be doing from the start?

Agreeing with everything else. Time is the axis every one of these records sits on, and a record with an uncertain time is a record with an uncertain meaning.

In practice that means every device takes its time from the same source, that source is checked rather than assumed, and the offset is recorded rather than implied. A device that quietly lost its time source and drifted is not obviously broken from the outside. It keeps working, keeps writing records, and the records come out wrong in a manner that surfaces only when somebody tries to use them.

The related habit is to write down which offset your stored records use and to put that in the same place as the procedure for searching them. It takes one line and prevents the most common wrong answer anybody gives from a set of otherwise perfect records.

How much of this actually needs money on day one?

Less than most people planning a network assume. The equipment doing the translating is being bought anyway. What gets added is somewhere to put the output and something to search it with, and neither is at the scale where hardware decisions become interesting.

What does deserve thought is storage that can grow without a rebuild, because the volume follows the customer count and the customer count is the thing you are trying to increase. Choosing something that expands is a different decision from choosing something large, and the first one is cheaper.

The other cost is attention rather than money. Somebody has to confirm that records are arriving, once a week at first, until it becomes obvious that they always are. Networks that skip this discover months later that collection stopped on a date nobody can identify.

Growth changes what is easy rather than what is required. A network of a few hundred customers can be searched slowly and get away with it. The same arrangement at a few thousand becomes something that has to be planned properly, and the change tends to arrive in the same quarter as everything else that comes with growing.

What can honestly wait until later?

Most of the visible parts. Report formatting, saved searches, dashboards, alerting, access levels for different staff, and anything that makes the output look finished can all be added while the network runs, because none of them change what is captured.

The order matters more than the list itself.

1. Capture, because it is the only item that cannot be applied backwards.
2. Somewhere to put the output that outlives the equipment producing it.
3. One identifier for a subscriber, agreed across billing, authentication and the network.
4. Clocks taking their time from one source, with the offset written down.
5. Everything else, once there are customers and you know what you actually need.

What cannot wait is the capture itself, for the plain reason that it is the only item on the list that works backwards. A dashboard built next year can display records from today. No amount of work next year produces records for a day that was never recorded.