project / February 3, 2026
GOPC Business Website
A practical business website and product catalogue foundation for a local computer hardware brand.
Problem
The business needed a credible public website that could present products, contact details, location information, opening hours, and future catalogue updates without forcing a complex e-commerce system too early.
Constraints
The setup had to stay affordable, simple to maintain, easy to update, and suitable for later integration with inventory and quotation workflows.
Approach
Build the public website foundation first: domain, hosting, SSL, business email, page structure, product catalogue direction, contact paths, location visibility, and a customer flow that can later connect to structured business data.
Outcome
The business gained a working online presence and a practical foundation for future product, quotation, inventory, and customer-contact workflows.
Secondary details
Role Fit
This work is best aligned with practical web implementation, small-business technical setup, and business systems support.
It demonstrates the ability to take a business that needs a public online presence and move it toward a structured, maintainable website without overbuilding the first version.
The value of the project is not in showing a complicated frontend stack. The value is in understanding what the business actually needs first: credibility, clear product presentation, contact paths, and a foundation that can later connect to inventory and quotation workflows.
Project Summary
GOPC is a local computer hardware business that needed a public website to present its products and make the business easier to contact and understand online.
The first stage focused on creating a practical website foundation: domain setup, hosting, SSL, business email, product catalogue structure, public pages, contact information, location visibility, and a path toward future product-data integration.
The project was intentionally kept simple at the beginning. A full online store, payment system, customer accounts, and complex backend were not the first priority. The important part was to avoid building a website that looked finished visually but would become difficult to update later.
Stack and Tools Used
The stack was kept practical and affordable for a small business setup.
Frontend
- React
- JavaScript
- HTML
- CSS
- Node.js build tooling
Node.js was used as part of the frontend/build workflow, not as a heavy backend layer.
Hosting and Domain
- Hostinger for hosting
- Nindohost for domain management
- SSL/HTTPS setup
- DNS configuration
Business Email
- Hostinger business mailbox
- SMTP testing
- SPF/DKIM configuration direction
- professional contact email setup
Commerce and Business System Direction
- Odoo planned/used as the direction for products, inventory, quotations, invoicing, and future structured business workflows
Website Features
- homepage
- product catalogue structure
- product/category presentation
- contact information
- location/map direction
- opening-hours visibility
- future inventory-backed product flow
What This Project Is Meant To Prove
- a small business website should start from the real customer flow, not from a list of features
- a product catalogue can be planned in a way that supports future inventory integration
- domain, hosting, email, SSL, and public pages are part of the same business presence
- the first version should be useful without becoming too complex to maintain
- technical decisions should leave room for future business workflows such as stock updates, quotations, and invoicing
Intended Build
The intended build was a public-facing business website with:
- a clear homepage
- product/category presentation
- contact information
- location/map access
- opening-hours visibility
- professional business email
- secure HTTPS access
- product catalogue foundation
- a structure that can later receive product data from business tools
The site was not meant to become a heavy platform immediately. It was meant to create a stable base first.
Delivery Scope
1. Public Website Foundation
Set up the public-facing website structure so customers can understand what the business offers and how to contact it.
This included the main pages, product presentation direction, contact paths, location information, and general business credibility.
2. Domain, Hosting, SSL, and Email
Prepare the basic web infrastructure needed for the business to operate online:
- domain setup
- hosting setup
- SSL/HTTPS
- DNS configuration
- public access
- business email configuration
This made the site more than just a local design preview. It became a real online presence.
3. Product Catalogue Direction
Plan the product catalogue as a foundation for future business data instead of treating it as a one-time static list.
The catalogue needed to support product names, categories, specifications, availability direction, and future connection to stock or quotation flows.
4. Business Communication
Set up the site so customers could find the business, understand what it sells, and contact it through proper business channels.
This included email direction, contact visibility, location access, and clearer public presentation.
Practical Decisions
Keep the first version manageable
The business did not need a complex platform before the workflow was clear. A simpler first version makes it easier to validate what customers actually need.
Separate public presentation from future operations
The website should present products publicly, but the deeper business workflows such as inventory, quotations, and invoicing should be handled cleanly instead of being improvised inside the frontend.
Avoid making the catalogue a dead-end
Even if products start as static or semi-static content, the structure should make it possible to move toward dynamic data later.
Treat email, domain, SSL, and hosting as part of the project
For a small business, the website is not only the visible pages. The surrounding setup matters because it affects credibility and maintainability.
What A Finished Version Should Show
A strong finished version of this work should show:
- a public website that clearly presents the business
- clean product/category pages
- contact and location information that customers can use
- a professional email setup
- HTTPS and stable hosting
- a product structure that can later connect to inventory data
- a clear path from product discovery to customer contact or quotation request
- documentation explaining how future product updates should be handled
Evidence Worth Capturing
Useful evidence for this project would include:
- screenshots of the homepage and product catalogue
- screenshots of contact/location sections
- proof of the domain resolving correctly
- SSL/HTTPS working correctly
- email sending/receiving tests
- SPF/DKIM or mailbox configuration screenshots
- product catalogue examples
- notes showing how the catalogue can later connect to structured product data
- before/after comparison between static product handling and planned dynamic product handling
Technical Assumptions
The website is treated as the public layer of the business, not the entire business system.
Product data, inventory, quotations, and invoicing can be connected later, but the first website phase should remain understandable and maintainable on its own.
The project assumes that customers mainly need to discover products, confirm details, and contact the business before a full checkout or payment flow becomes necessary.
Key Risks
- overbuilding the website before the business workflow is clear
- creating product pages that are hard to update later
- mixing frontend presentation with inventory logic too early
- relying on manual updates without a future data plan
- poor email/domain configuration affecting credibility
- making the website visually attractive but operationally weak
Current State
The website foundation is in place as a practical online presence for the business.
The project is still part of a larger direction: moving from a public catalogue toward a more structured business workflow with inventory, quotations, and internal product management.
The current value is the foundation. The next value comes from connecting the public product presentation with cleaner business data.
What This Project Does Not Claim
This project does not claim to be a full enterprise e-commerce platform.
It does not claim that every business workflow is automated already.
It does not claim that the public website alone solves inventory, quotations, invoicing, and customer management.
The project is best understood as the first public layer of a larger business system.
Interview / Client Talking Point
A useful explanation for this project is:
I started by building the public business presence first, but I treated the product catalogue as something that should later connect to real business data. The goal was not to overbuild the first version. The goal was to make the site useful now while keeping the structure ready for inventory and quotation workflows later.
Related Work
- Odoo Product & Inventory Integration
- Client-Facing Technical Documentation