Telecom Web Development Case: Fiber and ISP Projects

This telecom web development case covers my work as a developer on projects for four Danish companies in the fiber and telecom industry: Onefiber, GlobalConnect, Hiper and Fiber Teamet. The short version: the hard part of an operator's website is rarely the design. It's making sure a customer can check their address, see what's available and place an order that reaches the right back-office systems without anyone fixing it by hand.

[PLACEHOLDER: Confirm which of the four companies may be named, and remove the others from the intro, table and sections.]

[PLACEHOLDER: 1-2 sentences on your role across the projects, e.g. freelancer inside the client's team, subcontractor to an agency or direct contract, and roughly when.]

The short answer

Telecom is rarely a greenfield. Nearly every operator already runs systems for customers, products, orders and billing, and anything new has to talk to them. Here's how the projects break down:

All four were projects inside existing businesses. The focus is on integrations, data and software that fits the systems already in use.

What fiber providers and ISPs need from their websites

In Denmark, as in much of Europe, the company that owns the fiber isn't always the one selling the subscription. Network owners often sell wholesale access, and service providers sell internet, TV and phone to consumers on top. Both end up needing the same handful of things on the web:

1. An availability check: the customer enters an address and learns whether fiber is available, which speeds are possible and when it can be installed. It's usually the first thing a new customer does.
2. An order flow: product, start date, contact details, consents and possibly equipment. Four simple steps often hide many rules about contract terms, promotional pricing and what can be delivered at that address.
3. Rollout and interest pages: before digging in a new area, an operator often wants to know whether enough households are interested. That means sign-ups per address and a view of how close each area is to its target.
4. Self-service: order status, installation date, moving house and cancellation. Every task a customer can do alone is one less contact for customer service.
5. Integrations: the order has to reach the CRM, billing, and the systems that book installation or activate the line.

How much gets built from scratch depends on the operator's size. Large operators typically run standard BSS/OSS platforms (the business and operations support systems behind billing, orders and network activation) and bring in developers for the customer-facing layer and the glue between systems. Smaller operators more often need the whole chain.

Self-service usually ends up as a customer portal. If that's where you are, here's what a customer portal costs to build.

The projects

Below are the individual projects. I only describe what each client has approved, and numbers appear only where they're real and cleared for publication.

Onefiber

[PLACEHOLDER: Starting point. What was the need, and how did you join the project?]

[PLACEHOLDER: The work. What did you build (e.g. availability check, order flow, campaign page or integration), and on which stack?]

[PLACEHOLDER: Outcome. Only numbers, statements and quotes the client has approved.]

GlobalConnect

[PLACEHOLDER: Starting point. What was the need, and how did you join the project?]

[PLACEHOLDER: The work. What did you build, and on which stack?]

[PLACEHOLDER: Outcome. Only numbers, statements and quotes the client has approved.]

Hiper

[PLACEHOLDER: Starting point. What was the need, and how did you join the project?]

[PLACEHOLDER: The work. What did you build, and on which stack?]

[PLACEHOLDER: Outcome. Only numbers, statements and quotes the client has approved.]

Fiber Teamet

[PLACEHOLDER: Starting point. What was the need, and how did you join the project?]

[PLACEHOLDER: The work. What did you build, and on which stack?]

[PLACEHOLDER: Outcome. Only numbers, statements and quotes the client has approved.]

When a freelance developer fits telecom work, and when not

Most operators have an internal IT team and a set of long-term vendors. A freelancer doesn't replace either. I'm useful when there's a specific piece of work to deliver and the team doesn't have the hours for it.

A freelancer is a good fit for:

• A well-defined deliverable: a new availability check, an order flow, a rollout campaign page with sign-ups, or an integration between two systems.
• Extra capacity in an existing development team, where I work in your codebase and follow your review and release process.
• A smaller operator or ISP that wants one developer who understands the whole web stack, with direct contact to the person writing the code.

A freelancer is the wrong fit for:

• Core provisioning (activating lines) and network operations systems. Those need a team, specialist telecom software and people who know the network from the inside.
• 24/7 on-call with guaranteed response times at night. I reply within one business day, but that's not an on-call rota, and no single person can honestly promise one.
• Large public tenders that require certifications and a bench of consultants. An agency or consultancy is the honest answer there.

For larger projects I start with a paid, fixed-price discovery phase, so scope, integrations and price are settled before any code is written. You own the code from day one. I'm based in Denmark (CET), which keeps meetings easy for operators elsewhere in the Nordics and the EU. The full flow is in my write-up of how a project with me runs from first call to launch.

Four things that come up in most telecom projects

These apply to most operator websites, and I look for them first when I assess a new project.

Addresses should come from a list, not a text box

The same apartment can be written a dozen ways: floor and side, with or without a letter in the house number, abbreviated or spelled out. Let customers type freely and the order ends up with an address no other system can match. My rule of thumb: the customer always picks from the country's official address data (in Denmark, the national register, Danmarks Adresseregister), and the system stores the address ID, not just the text.

Campaigns cause traffic spikes

When a campaign goes out to an entire area, a lot of people arrive at once and all of them want to check their address. The availability check has to respond quickly and cache results. Orders should go into a queue and be processed in the background, so one slow external service can't take the whole site down with it.

An order must never disappear

An order for a subscription is revenue. If the call to billing or provisioning fails, the order must already be saved, the error logged, and the system should retry and alert someone. I recommend making every order traceable from the form to the last system, so customer service can answer "where's my order?" without asking a developer.

Accessibility is now a legal requirement

Under the European Accessibility Act, electronic communications services and e-commerce services provided to consumers after 28 June 2025 must meet accessibility requirements. Microenterprises (fewer than 10 employees and an annual turnover or balance sheet total of no more than €2 million) are exempt for services. For an operator, that means the availability check and order flow need to work with a keyboard and a screen reader. Each member state has its own implementing law, so confirm your obligations with a lawyer.

[PLACEHOLDER: Which of these four mattered most in your projects? One concrete example of a problem and how it was solved, using only details the client has approved.]

Next steps

If your company has a similar project, start with three pieces of information: what the solution needs to do, which systems it has to talk to, and whether there's a fixed date, such as a campaign launch. With those, I can usually tell you quickly whether the project suits me and what the next step looks like.

You can read more about how I build web apps and platforms for businesses. For more client work, see the case on new features for a fast-growing employee platform and the one on digital products for a fitness chain.

Frequently asked questions

Can you work inside our existing codebase and systems?+

Yes, that's a very common setup for a freelancer. I start by reading the code and getting access to a test environment, and I follow your existing review and release process. If the code is in a state where building on it is risky, I'll say so before I start and suggest a scoped cleanup first.

How do you handle confidentiality and customer data?+

I'm happy to sign an NDA, and if I get access to personal data, you'll normally need a data processing agreement under the GDPR as well. I prefer working with test data instead of real customer records, and only with the access the project requires. If you're unsure which agreements your situation calls for, check with your own lawyer.

Can you take on projects for operators outside Denmark?+

Yes. I work in English and I'm based in the EU, so the GDPR is the default for how I handle data. Country-specific details, such as the national address dataset or local consumer rules, are mapped out with your team during the discovery phase.

Who owns the code when the project is done?+

You do, from day one. The code lives in your own repository, so you can continue with your internal team or another vendor without needing my permission. In telecom that matters, because an operator's web platform usually has to live for years and adapt to new products, prices and campaigns.