Not what you pay. What it costs. Because in this industry those are two different numbers, and the gap between them depends entirely on how recently you joined, how loudly you complain, and whether you've mastered the ancient art of Threatening To Leave.

Broadband pricing in this country isn't a price. It's a casino. And the house always wins - unless you're willing to spend your lunch break gambling on the phone.

The haggling ritual: a national embarrassment

You know the drill, because at this point it's basically folklore. Your deal ends. Your bill jumps. So you phone up, sit through the painful hold music, and perform the sacred dance:

"I'm thinking of leaving."

Click. You're transferred to the mysterious retentions team - a department that exists purely because the normal price is a work of fiction. And lo, a discount materialises. A discount that absolutely did not exist ninety seconds ago when you were talking to normal support. A discount that was in a drawer the whole time, waiting to see if you'd ask.

Stop and actually think about what that means. The good price existed all along. They were simply withholding it to see if you'd blink first. Your ISP is running a pricing model where the best rates go to whoever's most willing to bluff, and everyone else - the busy, the trusting, your nan who's been with them since the modem made noises - subsidises the whole operation.

That's not a loyalty programme. That's a poker game where one side can see your cards and the other side is your nan.

The loyalty penalty: congratulations, you're the sucker

Because here's the grim engine underneath it all: in broadband, loyalty is a tax.

Stay for years. Pay every bill on time. Never cause a fuss. Your reward? You quietly roll onto an out-of-contract rate that's often double what the new customers pay, while the person who signed up yesterday gets the discount, the red carpet, and probably a free doorbell camera (Hi Sky).

The customers who've paid the most, for the longest, get treated the worst. Somewhere in a head office there's a spreadsheet of customers who haven't checked their bills lately, and that spreadsheet is load-bearing. The entire model is a bet that you're too busy living your life to notice you're being farmed.

The intro-price bait, or: the £24.99* experience

And how does everyone get lured into the casino in the first place? The big glowing "£24.99 a month!" - with an asterisk doing more heavy lifting than a fat guy driving a forklift.

£24.99 for six months. Then £36. Plus the setup fee. Plus the "activation" fee, which is a fee for the concept of beginning. Plus the router delivery. By the time you've read all the footnotes, the advertised price has roughly the same relationship to your bill as a movie poster has to the actual film. Unless its Project Hail Mary! Amaze Amaze Amaze.

The bit where we're honest about the awkward thing

Right. Cards on the table, because we're not going to write a whole post about pricing games and then dodge this bullet.

Yes, Olilo offers contracts. And yes, if you read ours, there's a clause in there about prices potentially rising. Practically every ISP has one, including us, because running a network in the real world means our own costs - backhaul, power, kit - can move in ways nobody controls (Hi Telehouse).

Here's the difference, and it's the whole point of this post: that clause is a seatbelt, not a business model.

The big players treat the annual price rise as a guaranteed revenue event - pencilled into the forecast before the year's even started, applied to everyone, every April, like clockwork. For us it's a break-glass-in-emergency thing. We're not planning to use it, we don't budget around using it, and if we ever genuinely had to, you'd hear it from us straight - plain English, actual reasons, no burying it in paragraph 47 of an email titled "Some exciting updates to your plan! 🎉"

We'd rather tell you the uncomfortable truth in a blog post than hide it in the footnotes. That's the deal. Well and an email of course.

The boring alternative

So here's Olilo's entire pricing strategy, and fair warning, it's painfully dull:

The price is the price. The rate on the website is the rate you pay - no intro-rate bait, and on our contracts, no activation fee for the privilege of existing. (Rolling monthly does have an activation fee, and we'll tell you exactly why: installing you costs real money, and we can't foot that bill for someone who dips on day 30. That's not a pricing game - that's maths. It's on the website in normal-sized font, like fees should be.) There's no retentions team, because there's no secret second price for them to guard. And there's no loyalty penalty, because the deal doesn't get worse just because you've been around a while. Staying with us shouldn't be a mistake you're punished for. Heck didn't we reduce all our openreach products? Even for those in contracts? Yup, that's us.

No poker. No drawer full of secret discounts. No spreadsheet of people who haven't noticed yet.

Boring? Extremely. But you know what's genuinely exciting? Never having to spend 40 minutes on hold negotiating the price of the internet like you're haggling for a rug.

The casino's fun until you realise you're not the player. You're the chips.....

Olilo - We legit are broadband without the bullshit.

The addresses

• IPv4: 5.182.115.74 and 5.182.115.75
• IPv6: 2a11:2646:1:2::4 and 2a11:2646:1:2::5
• DoT: dns.as212683.net on port 853
• DoH: https://dns.as212683.net/dns-query

Setup instructions per platform live at dns.as212683.net. Yes the landing page is served by dnsdist itself, we'll get to that.

Why

The obvious question. There are already excellent public resolvers run by very serious companies with very serious budgets and we are not going to out-Anycast Cloudflare. Fair.

The less obvious answer: DNS is one of those pieces of the internet where "more distributed" is genuinely better, most public resolvers on offer are three companies in a trenchcoat, and if you're a small ASN with the boxes already spinning it's approximately the same amount of work to serve fifty users or fifty thousand. The customer-facing config we were already running does 90% of what a public service needs. The rest was, in retrospect, an interesting weekend.

Also we wanted to write a blog post about it, which is arguably the real reason anyone does anything these days.

The stack, briefly

Nothing exotic. Two boxes, both in London:

• dnsdist out front doing all five transports (Do53, DoT, DoH, DoQ, DoH3), packet caching, rate limiting, dynamic blocking, and - this bit is genuinely funny - the landing page too
• PowerDNS Recursor loopback-only behind dnsdist, doing actual recursion with DNSSEC validation
• nftables with notrack on public UDP (more on why in a sec)
• Let's Encrypt via acme.sh for the TLS
• Prometheus + Grafana pointing at both boxes

The topology is deliberately boring. Boring is a feature.

The bit where we tried not to become a DDoS weapon

Every open resolver is a potential amplification reflector. This is the biggest reason "just run a public resolver" is a bad idea by default, and the reason most attempts by small networks end up on Shadowserver's problem list within a week.

You cannot make the risk zero. What you can do is make yourself an unattractive tool compared to the thousands of naked resolvers already floating around:

• ANY queries dropped. The classic amplification vector, gone.
• UDP answers capped at 1232 bytes (DNS Flag Day 2020). Big answers force clients to TCP, which spoofed sources can't complete. Amplification factor plummets.
• Non-recursive (RD=0) queries dropped. Real clients set the recursion-desired bit. Scanners often don't.
• Per-IP rate limit at 200 QPS, dropped past that.
• Dynamic blocking that watches per-IP QPS, NXDOMAIN rate, SERVFAIL rate, and response bandwidth, and bans offenders for five minutes at a time. Random-subdomain attacks and volumetric abuse get shown the door within seconds.
• DoQ and DoH3 are QUIC-based and QUIC has anti-amplification built into the protocol itself so that's a plus.

The application-layer stuff above handles abuse patterns. For actual volumetric attacks - the kind that don't care what's listening, they just want to fill your pipe - that's what our DDoS scrubbing is for. Traffic hits our scrubbers upstream of the resolvers, gets cleaned, and only the legit stuff makes it to dnsdist. Between the two layers, the resolvers themselves basically never see an attack in the shape that matters. Which is roughly the goal.

The notrack thing

Enough people asked about this in the review that it's earned its own header.

Linux tracks every "connection" through nftables' conntrack table so that ct state established,related accept works - that's how return traffic gets in. Fine for customer volumes. Genuinely catastrophic for a public UDP DNS server, because every query looks like a new connection, the table fills, and then the kernel starts dropping packets. On everything. Including the SSH session.... Do not ask me how I know.

The fix is boring and universal: bypass conntrack entirely for public UDP 53/853/443 via nftables' raw prerouting hook with notrack. TCP stays tracked (it's stateful anyway, and there's dramatically less of it). Every serious public resolver does this. Nobody talks about it. If you're standing up a public UDP-anything and you don't do this, you will find out in production, and it will be at 3am.

The nerdy bits worth mentioning

dnsdist serves the landing page. It owns port 443 for DoH already, so we told it to also serve / with a small HTML info page. /dns-query is still DoH, / gets a human. This is one fewer service on the box, one fewer thing to keep patched, one fewer reverse proxy to argue with. If it feels wrong, that's because you've been told for years that DNS servers only speak DNS. dnsdist 2.x quietly stopped bitching.

DDR (RFC 9462) is on. Clients that speak DDR - Windows 11, increasingly others - will ask us for _dns.resolver.arpa SVCB records, and we hand them back a pointer to our DoT and DoH endpoints. They then auto-upgrade to encrypted transport with zero user configuration. Try it yourself if you're into that sort of thing:

dig @5.182.115.74 _dns.resolver.arpa TYPE64

Two-layer caching. dnsdist has a 1M-entry packet cache in front, recursor has 2.5M record cache behind it. Popular names never touch the recursor. This is the reason a resolver on modest hardware can sit at very high QPS without breaking a sweat.

The Grafana

We monitor the boring stuff (up/down, QPS, cache hit ratio), the interesting stuff (latency percentiles, per-transport response times, dynamic blocks in flight), and the paranoid stuff (kernel UDP drops, response bandwidth vs query bandwidth, DNSSEC bogus rate). If any of those tiles turn red for long enough, Alertmanager tells us before you do. Probably.

What we don't do

• No per-client query logging. Aggregate Prometheus counters only.
• No EDNS Client Subnet sent upstream. Authoritative servers see us, not you.
• No filtering. No blocklists. No walled gardens on the public service (this is simply there for the future... AdBlocks anyone?).
• No ads, no upsell, no analytics on the landing page.

Written down so you can hold us to it.

How to actually use it

Easiest: Android Private DNS, put dns.as212683.net in the box, done. Everything encrypted.

Windows 11: DNS server assignment -> Manual -> the four IPs + DoH template.

Browsers: Settings -> Secure DNS -> custom provider -> paste the DoH URL.

iOS / macOS: install our configuration profile from olilo.co.uk/as212683-dns.mobileconfig

Routers: point WAN DNS at both IPs.

Linux: systemd-resolved with DNSOverTLS=yes.

Full walkthrough at dns.as212683.net.

Please break it (nicely)

If you find something weird, misbehaving, or straight-up broken, tell us: noc@as212683.net.

If you find something we should be doing differently, also tell us. Especially if you've run this kind of thing at bigger scale and have opinions on our thresholds. We can be persuaded.

Have fun. Tell your mates. Please don't use it to run for-profit DNS-over-DNS-tunnelling schemes.

However, if you've ever struggled with port forwarding, remote access, self-hosted services, or certain online applications, there's a good chance you've encountered a technology called CGNAT.

Many internet providers now use it by default, often without customers realising.

So what exactly is CGNAT, and why does it matter?

What Is CGNAT?

CGNAT stands for Carrier Grade Network Address Translation.

To understand it, we first need to talk about IPv4 addresses.

Every device connected to the internet needs an address. Historically, this was provided through IPv4, which uses a pool of approximately 4.3 billion unique addresses.

That might sound like a lot, but with billions of people, smartphones, computers, servers, and IoT devices online, those addresses have largely been exhausted.

As a result, many providers now share a single public IPv4 address between multiple customers using CGNAT.

Instead of your router receiving its own public address, it receives a private address, and the ISP translates your traffic behind a shared public IP.

Why Do Providers Use CGNAT?

The answer is simple: IPv4 addresses are expensive.

As address availability has declined, the market value of IPv4 space has increased significantly.

Using CGNAT allows providers to serve many customers while using fewer public IPv4 addresses.

For some providers, this reduces costs and simplifies growth.

For customers, the experience is often mixed.

What Problems Can CGNAT Cause?

For basic web browsing, streaming, social media, and video calls, CGNAT usually works perfectly fine.

The problems appear when you want inbound connections from the internet.

Port Forwarding Doesn't Work

Port forwarding allows external devices to connect to services running on your network.

Common examples include:

• Game servers
• CCTV systems
• Home automation platforms
• Self-hosted websites
• Remote desktop access
• VPN servers

With CGNAT, you typically cannot create working port forwards because the public IP address isn't actually assigned to your connection.

Remote Access Becomes More Complicated

Many homelab enthusiasts use services such as:

• WireGuard
• OpenVPN
• Home Assistant
• Plex
• Nextcloud

These can require additional workarounds when operating behind CGNAT.

Shared Reputation

When dozens or even hundreds of customers share a single public IP address, the actions of one user can potentially affect others.

This is uncommon, but shared IP reputation can occasionally cause issues with certain services or security systems.

Troubleshooting Is Harder

When multiple customers appear under the same public IP, diagnosing network issues can become more complex for both customers and support teams.

Does CGNAT Affect Gaming?

This is one of the most common questions.

For most modern games, CGNAT has little or no impact on latency.

Your ping is primarily determined by routing and network quality rather than whether you're behind CGNAT.

However, some games and peer-to-peer applications may report stricter NAT types, which can occasionally affect hosting sessions or direct connections.

The Long-Term Solution: IPv6

The internet's long-term answer to IPv4 exhaustion is IPv6.

IPv6 provides a vastly larger address space, allowing every device to have its own globally routable address.

With proper IPv6 deployment, the need for technologies like CGNAT is significantly reduced.

Unfortunately, not every service fully supports IPv6 yet, which means public IPv4 addresses still remain important today.

How To Tell If You're Behind CGNAT

One simple check is to compare:

1. The WAN IP address shown in your router.
2. The public IP address reported by websites such as "What Is My IP".

If the addresses don't match, there's a good chance you're behind CGNAT.

Another indicator is if your router receives an address from private ranges such as:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 100.64.0.0/10

The 100.64.0.0/10 range is commonly used specifically for CGNAT deployments.

Olilo's Approach

At Olilo, we believe customers should have full control over their internet connection.

That's why every prosumer broadband service includes:

• A public IPv4 address
• Native IPv6 connectivity
• No CGNAT
• Support from people who understand networking

Whether you're running a homelab, accessing services remotely, hosting applications, or simply want a more traditional internet connection, you won't find your traffic hidden behind carrier-grade NAT.

Final Thoughts

CGNAT isn't inherently bad. It allows providers to continue growing despite IPv4 shortages and works perfectly well for many everyday internet activities.

However, if you value control, remote access, self-hosting, or advanced networking features, it's worth understanding whether your provider uses it.

Sometimes the difference between something working immediately and spending hours troubleshooting comes down to whether you have your own public IP address.

So what actually separates an Internet Service Provider (ISP) from a broadband reseller?

The answer can have a bigger impact on your experience than you might think.

The Network Is Only Part Of The Story

Many broadband providers in the UK use wholesale networks such as CityFibre, Openreach, or other national infrastructure providers. These networks handle the physical connection between your home and the wider internet.

What happens after your traffic leaves that network is where providers begin to differ.

Some companies simply purchase a wholesale service, apply their branding, and provide customer support. Others invest heavily in their own network infrastructure, routing, monitoring, and technical expertise.

Both approaches are valid, but they can deliver very different customer experiences.

What Is A Broadband Reseller?

A broadband reseller typically relies on a third party for most aspects of service delivery.

This often includes:

• Authentication systems
• Routing infrastructure
• Core network services
• Traffic management
• Monitoring platforms
• Technical operations

In many cases, the reseller has limited control over how traffic is handled once it reaches the wholesale provider's network.

For customers with basic internet requirements, this may not be an issue. However, when something unusual happens or a more technical requirement arises, the reseller may need to escalate requests through multiple layers of suppliers before changes can be made.

What Is An ISP?

An ISP operates and manages its own network infrastructure.

This can include:

• Core routers
• Internet transit connections
• Peering relationships
• IPv4 and IPv6 address space
• Authentication platforms
• Monitoring systems
• Customer management systems

Because the ISP controls these systems directly, it can often diagnose and resolve issues faster, make network changes when required, and provide more flexibility for customers with advanced requirements.

Why Does This Matter?

For many people, broadband is simply expected to work.

But network design decisions can affect:

Performance

Two providers may use the same fibre connection into your property, but traffic can take very different routes across the internet afterwards.

Factors such as routing policies, peering arrangements, and transit providers can all influence latency and performance.

Reliability

Providers operating their own network can often identify and resolve issues more quickly because they have direct visibility of the infrastructure carrying customer traffic.

Technical Features

Features that enthusiasts and businesses often value include:

• Static IPv4 addresses
• Native IPv6 connectivity
• Reverse DNS support
• Public IP addressing
• Flexible network configurations
• Advanced troubleshooting

Not every provider offers these features, even when using the same underlying access network.

Support

When a provider owns and operates its own systems, support teams typically have greater access to diagnostic information and more control over resolving issues.

Rather than passing requests through multiple suppliers, they can often investigate directly.

Bigger Isn't Always Better

It's easy to assume that the largest providers automatically offer the best service.

In reality, many smaller ISPs have built loyal communities by focusing on technical excellence, transparency, and customer service.

Smaller providers often have the flexibility to make decisions quickly, listen to customer feedback, and offer features that larger organisations may not prioritise.

Where Does Olilo Fit In?

At Olilo, we believe broadband should be more than just a connection.

While we utilise modern fibre infrastructure, we also operate our own network systems and focus on delivering the features that internet enthusiasts, homelabbers, remote workers, and businesses expect.

That means:

• Static IPv4 addresses included as standard
• Native IPv6 connectivity
• No CGNAT
• Direct access to knowledgeable support
• A network designed with reliability and performance in mind

We're proud to be part of a growing community that values openness, technical expertise, and a genuinely customer-focused approach.

Final Thoughts

The fibre entering your home is only one piece of the puzzle.

When comparing broadband providers, it's worth looking beyond advertised speeds and asking deeper questions about how the service is delivered, who operates the network, and what level of control the provider has over your connection.

The answers can reveal the difference between a company that simply sells broadband and one that truly delivers internet services.

Here’s the clean version of the flow.

1) Name Resolution (DNS)

Your client needs an IP for the hostname.

• Stub resolver -> recursive resolver (often ISP, or public like Cloudflare / Google)
• Cache hit? Return immediately.
• Cache miss? Walk the walk: root -> TLD -> authoritative
• Respect TTLs, possibly DNSSEC validation

Latency cost: typically 5-40ms with a warm cache, more on cold paths.

Gotchas:

• High RTT to resolver
• Poor cache hit rates
• Misconfigured TTLs causing excess lookups

2) Transport Setup (TCP or QUIC)

TCP (HTTP/1.1, HTTP/2)

3-way handshake:

• SYN -> SYN-ACK -> ACK

Cost: 1 RTT before data.

QUIC (HTTP/3)

Runs over UDP, combines transport + crypto setup.

Cost: 0-1 RTT depending on session resumption.

Why it matters: Fewer round trips = faster TTFB, especially on high-latency paths.

3) TLS Negotiation

For HTTPS, you’re doing TLS (usually 1.3 now):

• Cipher suite negotiation
• Key exchange (ECDHE)
• Certificate validation
• Session resumption if available

Cost: ~1 RTT (less with resumption/QUIC)

Gotchas:

• Large cert chains
• OCSP/CRL delays (if not stapled)
• No session reuse

4) HTTP Request / Response

Now we actually ask for /.

• Headers go out (cookies, UA, etc.)
• Server responds (status, headers, body)

With HTTP/2:

• Multiplexed streams over one connection
• Header compression (HPACK)

With HTTP/3:

• Similar semantics, better under packet loss

TTFB depends on:

• Server processing time
• Upstream dependencies (DB, APIs)
• Network RTT

5) Rendering Pipeline (Client-Side)

Browser:

• Parses HTML -> builds DOM
• Fetches subresources (CSS, JS, fonts, images)
• Builds CSSOM
• Executes JS (which can block rendering)
• Layout + paint

This is where a “fast server” can still feel slow.

Common issues:

• Render-blocking JS/CSS
• Too many round trips for assets
• No prioritisation

6) Edge Caching / CDN

Most production setups sit behind a CDN like Cloudflare.

• Anycast routes you to a nearby POP
• Cached assets served at the edge
• Origin only hit on miss

Benefits:

• Lower RTT
• Offload origin
• Better resilience

Where Performance Is Actually Won/Lost

If you’re optimising, these are the levers that matter:

• RTT (physical + routing path)
• Handshake overhead (TCP + TLS vs QUIC)
• Cache hit ratio (DNS + CDN)
• Connection reuse (keep-alive, H2 multiplexing)
• Payload efficiency (compression, fewer requests)

Bandwidth matters far less than people think once you’re past a certain point.

Why This Matters (In Practice)

When someone says “the internet is slow”, it’s usually one of:

• Resolver latency or DNS issues
• High RTT / poor routing
• Packet loss impacting retransmissions
• TLS / handshake overhead on fresh connections
• Origin slowness or bad frontend design

Not “my line speed is too low”.

Takeaway

Loading a site is a pipeline of dependent steps:

DNS -> transport -> TLS -> request -> render

You don’t feel the individual pieces - you feel the sum.

And the difference between a “snappy” site and a sluggish one is usually just a few extra round trips in the wrong places.

When your internet slows down, what’s the first thought?

My ISP is trash.

Fair.
But also… not always true.

A lot of the time, your broadband is perfectly fine - it’s your WiFi that’s struggling.

Let’s break it down.

WiFi Hates Your House

WiFi signals aren’t magic. They’re radio waves.

And your house? Basically the worst enemy.

Things that absolutely destroy WiFi:

• Thick walls (especially brick or concrete)
• Metal (radiators, appliances, foil insulation)
• Floors (yes, upstairs = pain in the arse)

That “full fibre gigabit” connection?
Yeah… it’s not getting through three walls and a bathroom intact.

Distance = Speed Killer

The further you are from your router, the worse it gets.

Not just slower speeds - but:

• Higher latency
• More packet loss
• Random dropouts

WiFi doesn’t fail dramatically… it just slowly becomes unusable.

2.4GHz vs 5GHz (This Actually Matters)

Quick cheat sheet:

• 2.4GHz = longer range, slower speeds
• 5GHz = faster speeds, shorter range

Most devices switch between them automatically… badly.

So you end up:

• Stuck on a slow band when you shouldn’t be
• Or clinging to a weak 5GHz signal instead of switching

Your Neighbours Are Fighting You

If you’re in a flat or dense area (hi London 👀), WiFi is chaos.

Everyone’s router is shouting over each other on the same channels.

Result:

• Interference
• Congestion
• Random slowdowns at peak times

Your WiFi isn’t just your WiFi. It’s shared airspace.

Cheap Routers = Bad Time

A lot of ISPs ship… let’s be real… shit routers.

They:

• Struggle with multiple devices
• Have weak antennas
• Don’t handle congestion well

So when your house has:

• Phones
• Laptops
• TVs
• Consoles
• Smart home stuff

…it starts to fall apart.

Your Devices Aren’t Helping

Some devices just have trash WiFi chips.

Looking at:

• Older laptops
• Budget phones
• Smart TVs (honestly the worst offenders)

So even if your network is perfect… that one device will still struggle.

Speed ≠ WiFi Performance

This is the big one.

You can have:

• 900Mbps fibre
• Perfect line
• Zero issues from your ISP

…and still get 30Mbps over WiFi in your bedroom.

Because WiFi is the bottleneck.

So What Actually Fixes It?

Here’s what genuinely helps:

Move Your Router (seriously)

• Central location
• Not hidden in a cupboard
• Not behind your TV

This alone fixes a lot.

Use Ethernet Where You Can

Gaming PC? Console? Work setup?

Wire it.

Instant stability boost.

Get a Mesh System

If your place isn’t tiny, one router won’t cut it.

Mesh = multiple access points around your home = consistent coverage everywhere

Upgrade Your Hardware

A decent router makes a huge difference.

Better radios, better handling, less pain.

Real Talk

Your ISP delivers internet to your home.

WiFi is how it moves around your home.

Two completely different problems.

So before blaming your provider…

Check your setup.

If Your WiFi Still Sucks…

Then yeah - maybe it is your ISP.

And that’s where we come in.

If you’ve tried recently, you’ve probably hit at least one of these:

• You ordered service… and heard nothing for days
• Your internet just stopped working mid-migration
• Support ghosted you when things went wrong
• You got billed… for a service you didn’t even have

Yeah. It’s a mess.

And the worst part?
This isn’t rare anymore - it’s becoming normal.

The Problem No One Wants to Admit

A lot of ISPs aren’t actually built to handle the scale they’re operating at.

They rely heavily on wholesale networks - which is fine in theory - but when things go wrong, responsibility gets bounced around like a ping pong ball.

You end up stuck in the middle hearing:

It’s not us, it’s the network provider.

Meanwhile… you’ve got no internet.

The Migration Chaos (Yeah, We’re Going There)

Let’s talk about migrations - because this is where things really fall apart.

We’ve seen situations where:

• Customers are moved between providers with little to no notice
• Services go offline for days
• Billing systems keep running like nothing’s wrong
• Support channels just… stop responding

It’s not just frustrating - it’s unacceptable.

Broadband isn’t a luxury anymore.
People rely on it for work, healthcare, communication - everything.

So Why Does This Keep Happening?

A few reasons, and none of them are great:

1. Overpromising, Underbuilding

Some providers grow fast… without building the systems to support that growth.

2. Support Is Treated Like a Cost, Not a Priority

When things break, there aren’t enough real humans to fix it.

3. No Transparency

Customers are left in the dark because companies are too scared to just say:

Yeah, something’s gone wrong and we fucked up - here’s what we’re doing.

What We’re Doing Differently at Olilo

We didn’t start Olilo to be “just another ISP.”

We started it because we were genuinely tired of watching this happen.

So here’s the deal:

We Tell You What’s Actually Going On

If something breaks, we don’t hide it. We explain it - properly.

Real Support, Fast

No ticket black holes. No scripted nonsense.
You talk to actual humans who know what they’re doing.

Built Properly From Day One

We’re not duct-taping systems together and hoping for the best.

Our backend is designed to scale at any given moment.

The Bottom Line

The UK broadband industry doesn’t have to be this painful.

You shouldn’t have to chase support.
You shouldn’t lose service without warning.
You definitely shouldn’t be billed for nothing.

We built Olilo to fix that.

No bullshit. No silence. No messing you around.

Just broadband that actually works - with people who actually care.

Thinking of Switching?

If you’ve been caught up in a messy migration or just want a provider that won’t you know ghost you…

We’ve got you.

Olilo’s been up, running, and doing its thing the whole time.
We’ve just been… a bit quiet on here.

Not because nothing’s happening - quite the opposite.
We’ve been busy building, fixing, scaling, and dealing with all the fun chaos that comes with running an ISP.

The blog? Yeah… that took a back seat.

So why bring it back?

Because there’s actually a lot worth sharing.

We’re doing things differently, and most ISPs don’t exactly open the curtain on how things work behind the scenes.
We do.

This is where you’ll see:

• What we’re building (and sometimes breaking)
• Network updates and improvements
• The reality of running an ISP (the good and the slightly cursed)
• The occasional industry take when things go sideways

What’s changed?

Honestly? A lot.

The network’s stronger.
Things are faster.
We’ve learned a ton.
And we’re way more dialled in on what matters - stability, performance, and actually being there when people need help.

And yeah… the industry is still a mess

You’ve probably seen it.

Providers overpromising.
Support going missing.
Migrations turning into chaos.

We’re not here to pretend we’re perfect - but we are here to do it properly.

The plan

Keep building.
Keep improving.
And actually talk about it this time.

No corporate bullshit. No pretending everything’s perfect.
Just real updates from the people running the network.

Anyway

The blog’s back.
The broadband never left.

More soon.

- Aydan