DEV Community: Mohammed Saif Ibrahim

Building My First Client Website: From Development to Production

Mohammed Saif Ibrahim — Thu, 08 Oct 2026 15:39:55 +0000

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:

TechnologyPeople.ae

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.

Labanaat UI

Mohammed Saif Ibrahim — Thu, 01 Oct 2026 13:13:54 +0000

🚀 I’ve launched Labanaat UI — a React component library I built to explore what it takes to create a complete, reusable UI system.

Labanaat (لبنات) means “building blocks” in Arabic — reflecting the idea behind the library: composable building blocks for creating modern React interfaces.

🧱 What’s included

• 47 React components — including Kanban, DataGrid, Calendar, Chart, and more
• Token-based theming using CSS variables
• Tree-shakeable component entry points
• Interactive docs with live, editable examples
• 3 application templates
• Accessibility testing with axe-core + component tests
• Monorepo setup with TypeScript, CI, and automated build/test workflows

📦 Try it

npm install @labanaat/ui

🌐 Website:

Labanaat UI — a production-grade React component platform

Accessible, type-safe, composable React components built on design tokens, with full theming, localization, and slot-based customization.

labanaat.com

💻 GitHub:

Mohammed-Saif-Ibrahim / labanaat

A modern React UI component library built for developers.

Labanaat UI

A production-grade, composable React component library — accessible by default, themeable to the token, and built to feel like one product instead of forty-seven separate ones bolted together

What is Labanaat UI?

Labanaat (لبنات) means "building blocks" in Arabic — a fitting name for a library built around real, composable pieces rather than a wall of configuration props.

It's a full React component platform, not just a button and a modal:

47 components, from foundational (Button, Input, Card) through application-shell (Sidebar, Navbar, CommandPalette) to genuinely advanced (Kanban with real drag-and-drop, DataGrid with resizable columns, Chart, Calendar with range selection).
Accessible by construction. Complex patterns — Dialog, Select Combobox, Tabs — use Radix Primitives internally for keyboard/focus behavior that's been proven across thousands of production apps; where no primitive exists (Combobox, Calendar), the WAI-ARIA pattern is implemented directly instead of reaching for an unmaintained dependency.
Themeable down to…

View on GitHub

Current version: v0.9.0

It’s still a work in progress — particularly around real-browser QA for some of the newer components — but the library is now available to use and explore.

If anyone here works with React / TypeScript / design systems, I’d really appreciate feedback on the components, API, docs, or anything else that could be improved.

Would love to know what you think! 🙌

Developer Assessment Platform

Mohammed Saif Ibrahim — Fri, 25 Sep 2026 10:30:21 +0000

Hey everyone! 👋

🚀 I’ve been building something I’ve wanted to create for a while — a Developer Assessment Platform (DAP).

Over the past few weeks, I’ve been working on a full-stack platform designed to help developers practice, assess, and identify gaps in their technical knowledge across modern web technologies.

Rather than building another simple MCQ quiz app, I wanted to create something closer to an actual developer assessment experience.

🧩 What’s inside?

Multiple question types
MCQs, theory, code-output, and debugging questions.

📚 Multiple technologies
JavaScript, TypeScript, React, SQL, and more.

🎯 Custom assessments
Choose subjects, topics, and difficulty levels.

⚡ Instant results
Get your score along with explanations for each question.

📊 Progress tracking
Track your performance and identify areas where you need more practice.

🔖 Bookmarks
Save questions to revisit later.

🔐 No account required
The candidate experience doesn't require sign-up. Your quiz activity stays in the browser.

🛠️ Admin console
A separate protected interface for managing the question bank and assessment content.

I also deliberately kept the UI simple, black-and-white, and developer-focused, rather than following the usual colorful quiz-app design.

🌐 Try DAP

Developer Assessment Platform | Practice Coding Skills

Test your knowledge. Practice real programming concepts.

developer-assessment-platform.com

💻 Source code

Mohammed-Saif-Ibrahim / Developer-Assessment-Platform

A full-stack platform for assessing and practicing developer skills across modern web technologies.

Developer Assessment Platform

Practice. Test. Track your growth as a developer — all in one place.

A focused platform for sharpening programming knowledge through multiple-choice questions, theory questions, code-output questions, and debugging challenges Built for candidates who want real practice and admins who want a clean reliable way to manage the question bank.

✨ At a Glance

🎯 Question Types	MCQs · Theory · Code-Output · Debugging
📚 Subjects	JavaScript, React, TypeScript, SQL, and more
🖤 Design	Strict black & white — dark mode by default
🔒 Privacy	No account needed. Nothing about you ever leaves your browser
📈 Progress	Automatic weak-area tracking, right on your device

What This Platform Does

The Developer Assessment Platform gives you a growing bank of programming questions, organized by subject and topic, and lets you turn that bank into a quiz in seconds. You answer, get graded instantly, and can review exactly where you're…

View on GitHub

The project is still evolving. I’ll be expanding the question bank and adding more technologies and languages over time.

If you try it, I’d love to hear what you think — especially about the assessment experience and anything you think could be improved.

showdev #webdev #typescript #react