There is a difference between building a website to learn a technology and building one that a real business will actually use.
I experienced that difference while working with TechnologyPeopleLLC, where I was responsible for developing and launching a production website.
It was my first real client project where I took a website from development to production. Beyond building the frontend, I worked on enquiry handling, Firebase integration, an administrative dashboard, Arabic and English language support, and deployment.
In this article, I'll walk through the project, the technologies I used, and some of the lessons I learned along the way.
The Project and Tech Stack
TechnologyPeopleLLC needed a website to present its software solutions, services, industries, partnerships, and other business information.
My responsibility was to develop and deliver the website, ensuring that it worked across different screen sizes and supported the business's requirements.
The main technologies I used were:
- HTML5 — Structuring the website's content.
- Tailwind CSS — Building and styling responsive interfaces.
- JavaScript — Implementing interactive functionality and application logic.
- Firebase — Storing enquiry data and connecting the website with its administrative interface.
- Vercel — Deploying the public website and the admin interface.
- Git — Managing source code and development changes.
The public website included sections for the company's services, solutions, industries, partners, testimonials, FAQs, and contact options.
However, the project involved more than presenting information on a collection of pages.
It also needed to handle enquiries, notify the relevant people, and make submissions available for administration.
1. Building an Enquiry Workflow
One of the important parts of the project was implementing the enquiry workflow.
A contact form can look simple from the frontend, but a useful business enquiry system needs to do more than display a success message after someone clicks Submit.
The submission needs to be recorded, the business needs to know about it, and the visitor should receive confirmation.
I implemented a workflow that connected the website's forms with Firebase and the administrative interface.
The process looked roughly like this:
Visitor
|
v
Public Website
|
v
Enquiry Form
|
+------> Confirmation Email to Visitor
|
+------> Notification Email to Administrator
|
v
Firebase
|
v
Admin Dashboard
The workflow supported several requirements:
- Processing enquiries submitted through the website.
- Storing enquiry information in Firebase.
- Sending confirmation emails to visitors.
- Notifying the administrator about new submissions.
- Recording the page from which an enquiry originated.
- Making the submissions available through the admin dashboard.
Recording the originating page was particularly useful because visitors could submit enquiries from different product, service, and contact pages.
Keeping that information alongside each submission made it possible to identify where enquiries were coming from.
This part of the project changed how I thought about frontend development. A form is not an isolated interface component when it is connected to a real business process. Its behavior affects what happens after the visitor leaves the page.
2. Developing the Admin Dashboard
The enquiry workflow also required an administrative interface.
I developed a separate frontend that allowed administrators to review and manage submitted enquiries.
The dashboard supported tasks such as:
- Viewing enquiry submissions.
- Reviewing submission details.
- Identifying the originating page.
- Filtering submissions by source.
- Separating enquiries by product or website section.
The public website and the administrative interface were deployed independently using Vercel, while Firebase served as their shared data layer.
Conceptually, the system consisted of three main parts:
The public website: The interface visitors used to explore the company's services and submit enquiries.
The data and enquiry workflow: The part responsible for handling submissions, storing information, and supporting email notifications.
The admin dashboard: The interface administrators used to review incoming enquiries.
Thinking about these parts together helped me understand that even a relatively small business website can involve multiple connected components.
It also reinforced the importance of considering the complete workflow rather than focusing only on the interface visible to visitors.
3. Implementing Arabic and English Language Support
Another interesting part of the project was implementing support for Arabic alongside English.
This was my first experience working on a website where supporting multiple languages was an actual product requirement.
Rather than relying on automatic browser translation, I implemented Arabic translations directly into the website.
This required considering the translated content across the different sections and maintaining a consistent interface in both languages.
I also had to think about how the interface behaved when its content changed.
Translated text can have different lengths, which affects spacing, navigation, buttons, and other interface elements. Arabic also introduces right-to-left layout considerations.
These details made localization more interesting than simply translating individual strings.
I learned that supporting another language involves adapting the interface to the language, not just replacing its text.
This was my introduction to internationalization and localization as practical frontend development concerns.
4. Making the Website Responsive
The website needed to work across desktop, tablet, and mobile screens.
Before working on a real client project, it was easy to think of responsive development primarily as a CSS task.
This project made me pay more attention to how individual interface elements behave at different viewport sizes.
Navigation, typography, spacing, images, cards, forms, and buttons can all behave differently when the available space changes.
A layout that looks good on a desktop screen does not automatically provide the same experience on a phone.
I repeatedly tested and adjusted the website across different viewport sizes rather than treating mobile support as something to consider at the end.
The experience taught me to think about responsiveness as part of the overall interface design, not merely a final styling step.
5. Deploying to Production with Vercel
Developing the website locally was only part of the work. The final result needed to be deployed to the company's domain and made accessible to actual visitors.
I used Vercel to deploy the production website and the separate administrative interface.
Moving from development to production changed what I needed to pay attention to.
It was no longer enough for the website to work in my local environment. The deployed version needed to behave as expected, and the different parts of the enquiry workflow needed to work together.
The process gave me practical experience with production deployment, testing, and fixing issues that appeared outside the local development environment.
You can visit the live website here:
Seeing the website live was a different experience from running a project locally. It was something I had developed for a real business, rather than an application that existed only for learning or experimentation.
What I Learned from the Project
The biggest lessons weren't tied to any single technology.
Building for a real client changes your priorities
When working on a personal project, it is easy to change requirements or move on when something becomes inconvenient.
With a client, the website needs to meet actual business requirements and serve the people who will use it.
That requires thinking about the purpose of each feature, the information visitors need, and what should happen after an interaction.
A frontend feature is often part of a larger system
The enquiry forms connected the public website to data storage, email notifications, and an administrative interface.
Working on that workflow helped me think beyond individual components and consider how different parts of an application fit together.
Production is part of the development process
A feature is not necessarily finished just because it works locally.
Deployment, testing, and verifying the behavior of the production application are also important parts of delivering software.
There is always room to improve
Looking back, I would approach parts of the project differently with the experience I have today.
I would be more deliberate about certain architectural and accessibility decisions, and I would reconsider aspects of how I structure applications.
I see that as a useful part of development. Reviewing older work helps identify what I've learned and where I can improve.
Final Thoughts
This project was an important step in my development journey because it changed how I thought about building software.
I had to consider not only the interface, but also the business requirements, enquiry workflow, data storage, administration, localization, responsiveness, and production deployment.
The project wasn't the most technically complicated thing I've built, but it gave me something that tutorials alone couldn't provide: experience taking a website from development to a real production environment for a business.
That experience made me more interested in the systems behind user interfaces, how applications handle data, and how software can solve practical business problems.
The biggest lesson I took away was simple: software isn't finished just because it works on your computer. It needs to work for the people it was built for.
I'm continuing to learn by building projects, exploring different technologies, and working on software beyond the frontend.
You can find more about my work on my portfolio.
Top comments (1)
Congrats on shipping a real client site. The jump from learning projects to client work is mostly about requirements: what the client says versus what they need. For the next one, a short written brief before you start helps a lot. I built chatform.in for briefs like that; it follows up when an answer is vague.