My First Real Client Project: Building a Production Website for TechnologyPeopleLLC

There is a difference between building a website because you want to learn something and building one because someone is actually going to use it.

My first experience with that difference came when I worked with TechnologyPeopleLLC.

It was my first real client project where I was responsible for taking a website from development to production. I wasn't building it for a course, a tutorial, or a portfolio mockup. I was building something that a real business would use.

That changed the way I thought about development.

Before the project

Most of my earlier development experience had been about learning.

I would build something, get it working, experiment with a technology, fix the bugs, and move on to the next project.

A client project is different.

You don't get to decide that a feature is "good enough" simply because it works on your machine. The website has to work for the people who are going to use it, represent the business properly, work across different screen sizes, and remain usable after it has been deployed.

That was the first time I had to think about development as more than writing code.

The project

TechnologyPeopleLLC needed a production website to present its software solutions, services, industries, partnerships, and other business information.

I worked on the project as a freelance Software & Web Developer and was responsible for the development and delivery of the website.

The stack was relatively simple:

• HTML5
• Tailwind CSS
• JavaScript
• Firebase
• Vercel
• Git

The public website was designed to be responsive across desktop, tablet, and mobile, with sections for the company's solutions, industries and services, partners, testimonials, FAQs, and contact calls-to-action.

It also included Arabic language support and enquiry forms across relevant pages.

But the project ended up being more than just a landing page.

My first experience with translations

One of the new challenges I encountered on this project was supporting multiple languages.

This was my first time building a website where translation was an actual product requirement.

The website needed to support both English and Arabic, so I didn't want to simply depend on the browser's automatic translation.

Instead, I implemented the Arabic translation directly into the website.

This meant thinking about the content as something that could exist in multiple languages rather than treating the English version as the only version of the site.

I had to account for translated text across the different sections of the website and make sure the Arabic version remained usable and visually consistent with the English version.

This was also my first experience thinking about how language can affect an interface. Text isn't always the same length after translation, and Arabic introduces additional considerations around right-to-left content and layout.

It was a relatively small part of the overall project, but it was an important first step for me into internationalization and localization.

I learned that supporting another language isn't simply about translating words. The interface itself has to accommodate the language.

From a website to a small system

One of the first things I learned from this project was that a business website isn't always just a collection of pages.

The website needed to handle enquiries.

That meant the forms needed to do more than simply display a success message. They needed to connect the visitor with the business while also giving both sides confirmation that the enquiry had been received.

When someone submitted an enquiry, the system needed to:

1. Process the submission.
2. Store the information in Firebase.
3. Notify the administrator by email.
4. Send a confirmation email to the person who submitted the enquiry.
5. Record which page the enquiry came from.
6. Make the submission available to the administration interface.

The confirmation email was an important part of the workflow. After submitting an enquiry, the user received an email confirming that their enquiry had been successfully submitted, while the business received its own notification so the enquiry could be followed up.

The originating page was also recorded with the enquiry. An enquiry could come from a product page, a service page, or the general contact page. Recording that information meant the business could understand where enquiries were coming from.

So instead of building only a frontend, I ended up building a small workflow around the website.

The overall flow was roughly:

Visitor
   │
   ▼
Public Website
   │
   │ Enquiry
   ▼
Form Workflow
   │
   ├──────────────► Confirmation Email → Visitor
   │
   ├──────────────► Notification Email → Administrator
   │
   ▼
Firebase
   │
   ▼
Admin Dashboard

This was one of the first times I started thinking about a website as a small system with multiple connected parts rather than simply a collection of pages.

Building the admin side

I also developed a separate administrative frontend for managing those enquiries.

The public website and the admin interface were deployed separately, while Firebase acted as the shared data layer.

The dashboard allowed administrators to:

• view submitted enquiries
• review submission details
• identify the originating page
• filter submissions by source
• separate enquiries by product or website section

This was one of the first times I had to think about a website as multiple connected pieces rather than a single application.

The architecture was roughly:

Visitor
   │
   ▼
Public Website
   │
   │ Enquiry
   ▼
Form Workflow
   │
   ├──────────────► Email Notification
   │
   ▼
Firebase
   │
   ▼
Admin Dashboard

The production website and the administrative dashboard were deployed independently using Vercel.

What I learned about responsive development

Before working on a real client website, it was easy to think of responsiveness mainly as a CSS problem.

This project changed that perspective.

A section that looks good on a desktop screen doesn't automatically translate well to a phone.

Navigation, spacing, typography, images, cards, forms, buttons, and entire section layouts can behave differently depending on the available space.

I had to repeatedly test and adjust the website across different viewport sizes rather than treating mobile as an afterthought.

That experience made me much more conscious of responsive behavior when building interfaces later.

What I learned about requirements

Another important lesson was that building software for someone else is different from building software for yourself.

When building my own projects, I can change the requirements whenever I want.

With a client, the requirements come from an actual business.

That means understanding what the website needs to communicate, which information matters, how users should navigate it, and what the business needs after a visitor submits a form.

I started paying much more attention to the question:

"What does the person using this system actually need?"

rather than only asking:

"How do I implement this feature?"

That distinction has stayed with me.

Getting it into production

Eventually, the website had to leave my development environment and become the actual website people could visit.

The production website was deployed to the company's domain using Vercel.

That introduced another set of considerations: deployment, production behavior, testing, fixing issues that appeared outside the local environment, and making sure the final result worked as expected.

The website is still available at TechnologyPeople.ae.

For me, seeing something I had built become an actual production website was a different feeling from seeing a project running on localhost.

It was the first time I could point to something and say:

"I built this for a real business, and people are actually using it."

What I would do differently today

Looking back at the project now, I would approach parts of it differently.

My development experience has grown considerably since I built it. I've worked on larger applications, backend systems, deployment architectures, component libraries, and open-source projects since then.

I would probably structure some parts of the application differently today and be more deliberate about certain architectural and accessibility decisions.

But I don't see that as a problem.

That's one of the reasons I wanted to write about this project.

Looking back at older work makes it possible to see how much has changed.

The beginning of something bigger

This project was important to me for another reason.

It was the beginning of a shift in how I approached development.

After working on a real production website, I became more interested in what happens beyond the frontend.

How do you build systems around a website?

How do you handle data?

How do you automate workflows?

How do you design software that solves an actual business problem?

Those questions eventually led me to other projects, including larger full-stack applications and more complex software systems.

But this was where that transition started.

My first client project wasn't the most technically complicated thing I've built.

It didn't use the most advanced technology.

And I wouldn't build it exactly the same way today.

But it taught me something that tutorials couldn't:

software isn't finished when it works on your computer.

It's finished when it solves a real problem for the people it's being built for.

And this was the first project that really taught me that.