Case Study · 2024

Zigma

A digital advertising marketplace — Client, Provider, and Admin in one system

Frontend Developer · Continuing and finishing a delayed project

02 — A project waiting for a restart

When I joined, the project was about a year behind.

Zigma needed a restart — not from scratch, but from the point where development had effectively stalled.

In the first month, I took ownership of continuing and pulling the Frontend together. The job was not rebuilding the whole product; it was putting an incomplete system back on a real delivery path.

A project delayed by roughly a year
Need to assemble the Frontend quickly
Focus on the real product path
Joining to continue the work, not start from zero

03 — One month to Version 1

About one month of focused work; Frontend nearly ready.

The goal was clear: finish the core UI, implement key flows, define roles in the Frontend, and wire real API integration.

By the end of that window, Version 1 was nearly ready — not as a decorative UI, but as an API-connected SPA usable across the system's main roles.

01
Speed of execution
In a short window, the Frontend moved from delayed to near-ready.
02
Ownership
Continuing the project, prioritizing work, and getting critical pieces to a dependable state sat with me.
03
Into a product
From an unfinished Frontend to a connected, role-based experience close to Version 1.

04 — One interface, three roles

Client, Provider, and Admin; three experiences in one Frontend.

Zigma was never only a single panel. One SPA had to cover three user types with different goals and operations.

Each role had its own entry path, dashboard, and workflow — while the product foundation stayed shared.

Client

Browse services and products, place orders, manage orders, top up the wallet, and track transactions.

An advertiser who needs to find a service quickly, order it, and follow status.

Provider

Create and manage ad products, receive orders, update status, sales dashboard, and settlement.

A publisher who offers products and drives orders through to delivery.

Admin

Manage categories, dynamic fields, products, orders, settlements, and the marketplace as a whole.

The operational layer that holds the system's structure and rules.

05 — From catalog to payment

One path; from entry to settlement.

Zigma's main flow was not a page list. It was a connected journey: from authentication to order, payment, and Provider-side fulfillment.

After OTP, the user received a role from the API, entered the matching environment, and moved through ordering to wallet and final status.

01
OTP Login
Sign-in with a one-time code.
02
Role
Receive role from the API and enter the matching space.
03
Catalog
Browse services, products, and packages.
04
Select
Product, Package, or Campaign.
05
Order
Place the order and complete dynamic fields.
06
Payment
Wallet or payment gateway.
07
Fulfillment
Provider receives and advances the order.
08
Settlement
Status updates, transactions, and settlement.

06 — Dynamic by design

The order form was not the same for every service.

Categories carried dynamic fields — so the information required for an order changed with the service type.

An Instagram Post differed from a Story; Telegram differed from Website and Reportage. The Frontend had to keep that flexibility in how information was shown and collected — without breaking the role-based experience.

Instagram Post
Instagram Story
Followers and other services
Telegram Promotion
Website / Reportage

01
Category-bound fields
Each category could define its own set of fields for an order.
02
Flexible forms
The UI had to handle different structures without being hard-coded to one service.
03
Product complexity
That flexibility was one of the real complexity points in the Frontend experience.

07 — Built around the API

The Frontend was not only UI; it was wired to a real API.

The API already existed. The Frontend's job was to connect the interface to live data, roles, and system operations.

Role, products, orders, wallet, transactions, and other required data came from the API. The result was turning a visual surface into a functional product.

Auth and Role
OTP and role detection for entering the right environment.
Catalog and products
Reading and presenting services, packages, and product detail.
Orders
Creating, viewing, and tracking orders in the live system flow.
Wallet and transactions
Top-ups, payments, and Client-side financial history.
Provider operations
Receiving orders, updating status, and running fulfillment.
Admin layer
Managing marketplace structure through live API data.

08 — The operational side

The real breadth of the product showed up in Provider and Admin.

A marketplace is not only the Client purchase path. It also has to cover supply, fulfillment, management, and settlement.

This section shows how far the Frontend reached into operational depth — from products and orders to categories and settlement.

01
Product management
Creating, editing, and maintaining ad products for Provider and Admin.
02
Incoming orders
Viewing orders and advancing them through service delivery.
03
Order status
Updating status across the fulfillment path.
04
Sales and settlement
Provider sales dashboard and settlement processes.
05
Categories
Defining and managing categories and service structure.
06
Marketplace management
Admin oversight of products, orders, and operational rules.

09 — Ready, but not launched

Version 1 was nearly ready; an official launch did not happen.

The Frontend was connected to the API and the product had reached a near-ready state. The stop was not caused by a fundamental Frontend technical failure.

Some required information and inputs were never delivered by the client. After that, the project did not continue in any formal way.

This is a product reality, not a Frontend technical failure. The system had reached a near-ready Version 1; a dependency outside the Frontend blocked an official launch.

Frontend status
Version 1 nearly ready and connected to a real API.
Why it stopped
Required client-side information and inputs were not delivered.
What is not claimed
Because there was no official launch, there are no claims about users, traffic, or commercial impact.

Sometimes the value of the work is not a public launch; it is getting a stalled project to a point where it is genuinely usable.

10 — What I owned

The real scope of responsibility.

My focus was Frontend and the client-side experience — from SPA architecture to preparing Version 1.

01Frontend development
02React architecture
03TypeScript
04SPA implementation
05RTL Persian UI
06Role-based experiences
07API integration
08Authentication / OTP flow
09Product and catalog interfaces
10Order flows
11Dynamic forms
12Wallet / transactions interfaces
13Provider dashboard
14Admin interfaces
15Responsive implementation
16Bug fixing
17Preparing Version 1

Zigma was never about starting from zero.

It was about the distance it takes to turn a delayed project back into a product-minded Frontend that is nearly ready.

When I joined, the project was about a year behind.

Zigma needed a restart — not from scratch, but from the point where development had effectively stalled.

In the first month, I took ownership of continuing and pulling the Frontend together. The job was not rebuilding the whole product; it was putting an incomplete system back on a real delivery path.

The order form was not the same for every service.

Categories carried dynamic fields — so the information required for an order changed with the service type.

Zigma

When I joined, the project was about a year behind.

About one month of focused work; Frontend nearly ready.

Speed of execution

Ownership

Into a product