IDWE | IT Services and Product Discovery Platform

Project Overview

IDWE is a prototype for an IT solutions business that presents professional services and technology products in one website. Visitors can explore service categories, individual offerings, delivery teams, product categories, and product details. Clients also have account screens for identity, profile information, addresses, sessions, and activity history. A Django API supplies the records behind the public catalogs and account features.

I developed IDWE to bring two kinds of discovery together. Someone planning an IT project needs to understand the available expertise and the team behind it. Someone evaluating equipment needs to compare product information, variants, and availability. Those are different decisions, but both benefit from consistent navigation, structured data, and a shared client identity.

The frontend uses Next.js 16, React 19, TypeScript, and Tailwind CSS. The backend uses Django 5.2 and Django REST Framework. Its database configuration defaults to SQLite for a simple local setup and can be configured for another Django database engine. This case study describes what the repository implements rather than assuming a public deployment or a completed purchasing system.

The Problem

An IT company may offer both technical services and physical products, yet a visitor does not always know which path to take. A service page must explain what will be delivered, what the work requires, and who can perform it. A product page needs specifications, stock context, price information, and relevant alternatives. Without a clear structure, these experiences become a collection of unrelated pages that is difficult to maintain.

IDWE organizes services, teams, products, and client information as separate domains behind one interface. The project explores how a public website can present detailed business content while the backend retains control over catalog records and account data.

Application Architecture

The Next.js application provides public browsing and a separate account workspace. Django REST Framework exposes service, product, and identity endpoints. The diagram shows the implemented information paths, not a purchase or booking flow.

The frontend reads service and team information from the API for listings and detail pages. Product listings and detail pages also request catalog data from Django. Authentication endpoints support registration, email verification, login, logout, token refresh, and password reset. Profile, address, session, and activity endpoints support the client account area.

This separation lets the public interface focus on presentation while the backend owns data models, filtering, access rules, and administration. The repository also includes a customized Django Unfold administration interface for managing the underlying records.

Service Discovery

The services area includes a landing page, category browsing, a filtered service list, detail pages, and team profiles. A service record can describe its category, type, pricing model, deliverables, requirements, features, and related team. Detail pages combine those fields into an explanation of the offering instead of showing only a short card description.

The service API exposes active, visible services and categories. It supports search, filtering, ordering, and featured results. Team records connect people and specializations to services, allowing the interface to show which group is associated with a particular offering. On the frontend, service detail pages request API data on the server and generate page metadata from the returned record.

The backend also defines service request records, attachments, updates, and time tracking. These models show how a future client request could connect to delivery work. In the current frontend, however, the main Request This Service action only writes to the browser console. I therefore present the service catalog and team discovery as implemented experiences, while treating end to end service ordering as unfinished.

Product Discovery

The product side offers a category driven listing and individual product pages. Product data includes brands, images, variants, attributes, pricing fields, and inventory information. Visitors can move from a category to a detail page, inspect available options, and see related products. The product listing reads category and page values from the URL so browsing can be revisited or shared.

The product API publishes active, visible products. Its list and detail queries load related brands, images, categories, attributes, and variants as needed. The API provides search, featured products, recent arrivals, sale items, and related products. Django filters allow queries by category, brand, price, stock, and attributes. These are useful catalog capabilities even before a purchase transaction is available.

The product detail page has quantity and variant controls, but its current Add to Cart handler only logs the selection. Although the backend contains cart, order, payment, and refund models, the cart and order route files expose no API endpoints. This project should therefore be understood as a product discovery prototype, not an operating online store or checkout system.

Client Identity and Account Workspace

IDWE has account screens for registration, login, email verification, password reset, profile information, saved addresses, and session activity. The Django authentication module provides the corresponding identity and client endpoints. JWT authentication protects client data, while the frontend maintains account state and calls profile and session services.

The account workspace demonstrates how a visitor could continue from anonymous discovery to a recognized client relationship. It also contains interface areas that are not yet backed by complete operational data. For example, the dashboard displays a fixed activity score. I would not present that card as live analytics or claim that the account area includes completed ordering history.

Technical Decisions and Current Scope

The repository keeps the frontend and backend as separate applications. This makes the public presentation independent of the business models while giving both service and product pages a common API boundary. On the backend, public catalog views restrict results to content marked active and visible. On the frontend, service pages use server rendering and page metadata for discoverability, while the product listing uses client side fetching for pagination and category changes.

The project is best described as an integrated prototype. The contact form validates fields but simulates submission. Service request buttons are not connected to the request API, and cart and order actions do not complete a transaction. The backend test files for the service and order apps are placeholders, so the repository does not establish broad automated test coverage. It also does not provide verified adoption, transaction, or deployment results.

These boundaries matter because the codebase contains extensive models and polished interface components. A model expresses an intended business concept, but it does not prove the complete user journey. The next meaningful step would be to connect the request and cart actions to their backend operations, then test the entire path from a visitor action through persistence and confirmation.

Outcome

IDWE brings service expertise, team information, a detailed product catalog, and client account foundations into one coherent application structure. Its strongest contribution is the shared discovery architecture: two different catalogs can remain distinct while relying on the same backend and identity system. The project also taught me to evaluate features across their full path. A convincing interface is only one layer; the operation is complete when the action, API, stored record, and user feedback all agree.