Building a telco e-commerce platform from zero.

01 / Greenfield

Start with the decisions that shape everything after them.

I joined Yettel at the beginning of a greenfield telco e-commerce project. There was no inherited application architecture to protect, so I helped decide which technologies we would use, how the infrastructure should be arranged, and how the frontend would communicate with the APIs.

The product needed to sell phones, plans, connectivity, and related services. That made search visibility and page speed part of the product requirements from the start, rather than improvements to make after launch.

02 / Architecture

Choose a foundation that serves both customers and the business.

I pushed for Next.js because the storefront needed SEO-ready pages as well as interactive e-commerce flows. Server-side rendering gave product and content pages a strong HTML response for crawlers, while the client could take over for configuration, cart, and checkout interactions.

I also worked through the API boundary and release model: which data should be requested on the server, which interactions belonged in the browser, how environments should be separated, and where releases should run. These decisions gave the team a shared direction before implementation accelerated.

SEO-ready product and content pages

SSR

Architecture and delivery model

0 → 1

Explicit frontend/backend boundary

API

03 / Foundation

Make the first commits useful to everyone who follows.

I wrote the first commits, established frontend best practices, and started a knowledge base for the engineers joining the project. The goal was to make decisions visible: how we organized pages, where API calls belonged, how errors were handled, and how a new feature should move from a branch to a release.

I was also responsible for the infrastructure direction around releases. That work connected the application architecture to a practical delivery process, so the team could ship increments regularly and understand what was running in each environment.

04 / Performance

Treat image-heavy pages as a design constraint.

Telco commerce pages carry large product imagery, promotional artwork, and responsive layouts. I used performance profiling to find the expensive paths and applied an image strategy based on responsive sources, modern formats, explicit dimensions, and lazy loading below the fold.

The example below is adapted from the image-loading guidance I used while shaping the approach. Hero images can opt into high priority; the rest of the page can load the size and format that the viewport actually needs.

<picture>
  <source
    type="image/avif"
    srcSet="/images/phone.avif?w=480 480w, /images/phone.avif?w=960 960w"
  />
  <source
    type="image/webp"
    srcSet="/images/phone.webp?w=480 480w, /images/phone.webp?w=960 960w"
  />
  <img
    src="/images/phone.jpg?w=960"
    srcSet="/images/phone.jpg?w=480 480w, /images/phone.jpg?w=960 960w"
    sizes="(max-width: 800px) 100vw, 50vw"
    width={1600}
    height={1000}
    loading={isHero ? "eager" : "lazy"}
    fetchPriority={isHero ? "high" : "auto"}
    decoding="async"
    alt={productName}
  />
</picture>

05 / Product surfaces

Design for the moments that carry the sale.

The storefront had to work as a connected journey: discover a product, understand the offer, configure the plan, and complete the order. I kept the page structure and API boundary clear across the main storefront, product detail, and checkout surfaces so each step could evolve without turning the whole flow into one coupled screen.

06 / Security

Move from storefront foundations to trusted account flows.

Once the core storefront direction was in place, I shifted focus to authentication and application security. The important boundary was server-side: credentials and session material stayed behind the server boundary, route handlers checked authorization before calling protected APIs, and the browser received only the data needed for the current screen.

I documented the security patterns around HTTP-only, Secure, and SameSite cookies, validation at the API boundary, short-lived sessions, and authorization checks close to the data access layer. For a Next.js application, that led us toward a library-backed session implementation rather than hand-rolling token handling in every page.

import "server-only";
import { cookies } from "next/headers";
import { redirect } from "next/navigation";

export async function requireCustomer() {
  const session = (await cookies()).get("session")?.value;
  const customer = await verifySession(session);

  if (!customer) redirect("/login");
  return customer;
}

// Set sessions on the server with httpOnly, secure, and sameSite cookies.
// Check authorization again before protected API calls or mutations.

Next.js — Authentication guide

07 / Delivery

Keep leadership close to the real state of the build.

Every month I presented the progress to Yettel directors. I showed which features had been introduced, what was working across the product journey, and where the team still needed time. That made delivery status concrete and gave the project a regular forum for discussing scope, risk, and sequencing.

The presentations were part of the engineering work: they connected the architecture decisions and implementation detail to the business question of what customers could actually do next.

08 / Outcome

A clear technical starting point for a complex storefront.

The greenfield work established a Next.js foundation for SEO-ready pages, a defined API and infrastructure direction, practical image-performance rules, an authentication and security approach, and a repeatable release conversation with leadership.

My ownership covered the decisions before the UI existed, the first implementation patterns, the performance constraints that shaped page construction, and the communication needed to move the product forward with confidence.