DEV Community: Fady Desoky Saeed Abdelaziz

SWIFT GO — Building a Smarter Corporate Transportation Platform from Scratch 🚍

Fady Desoky Saeed Abdelaziz — Thu, 02 Jul 2026 11:59:25 +0000

How our graduation project evolved into a real-world transportation management platform.

Every day, thousands of employees spend hours commuting.

Late buses.

Unclear pickup locations.

Phone calls between drivers and passengers.

No visibility into seat availability.

No way to know where the bus actually is.

These aren't just transportation problems—they're operational problems that affect productivity, time, and user experience.

As Software Engineering students, we wanted to ask ourselves a simple question:

Can technology make daily transportation smarter, more predictable, and more efficient?

That question became SWIFT GO.

What is SWIFT GO?

SWIFT GO is a smart transportation platform designed to simplify shuttle and fleet management for companies, universities, and organizations.

Instead of relying on spreadsheets, phone calls, and manual coordination, SwiftGo digitizes the entire transportation experience for both passengers and drivers.

Our goal wasn't simply to build another ride-hailing application.

We wanted to create something different:

A scheduled transportation system where every trip is organized, trackable, and optimized.

The Problem

Traditional transportation management usually suffers from several challenges:

Limited visibility of vehicle locations
Manual passenger coordination
No live trip tracking
Difficulty managing available seats
Poor communication between drivers and passengers
Time lost due to inefficient scheduling

These problems become even more noticeable when managing hundreds of employees across multiple daily routes.

Designing the Solution

SWIFT GO consists of multiple integrated applications working together:

Passenger Mobile Application
Driver Mobile Application
Backend API
Administration Dashboard
Real-time GPS Tracking Services

Each component was designed to solve a specific part of the transportation workflow.

Passenger Experience

The passenger application focuses on making transportation simple.

Instead of contacting the driver manually, passengers can:

Browse available routes
View pickup stations
Check available seats
Reserve a seat
View pricing
Review complete trip details
Track their assigned shuttle

The reservation process requires only a few taps.

Everything the passenger needs is available inside the application.

Driver Experience

Drivers have a completely different interface designed around operational efficiency.

Using the Driver App, they can:

Receive assigned trips
Accept scheduled routes
Start trips at the correct time
Navigate using integrated maps
Follow pickup stations
Update trip status
Complete routes

The application continuously updates the driver's location, allowing passengers and administrators to monitor trip progress in real time.

Real-Time Tracking

One of the most important features of SwiftGo is live GPS tracking.

Passengers no longer need to wonder:

"Where is the shuttle?"

Instead, they can follow the trip as it progresses between pickup stations.

Real-time tracking also allows administrators to monitor transportation performance and quickly identify delays.

Smarter Route Management

Transportation isn't only about maps.

It's also about planning.

SWIFT GO allows users to:

Explore available routes
View detailed station lists
Check estimated arrival times
See trip duration
Monitor seat availability before booking

If a desired route isn't available, users can even submit a route request, helping organizations understand transportation demand before launching new routes.

Building the System

Developing SWIFT GO required much more than designing user interfaces.

Behind every screen is a complete software architecture.

The project includes:

Mobile Development

React Native

Backend

NestJS
Fastify
Express

Database

PostgreSQL
Prisma

Authentication

JWT Authentication
Role-based Authorization

Maps & Navigation

Google Maps API
Directions API
Geolocation Services

Notifications

Firebase Cloud Messaging

Development Practices

RESTful APIs
Repository Pattern
Dependency Injection
Clean Architecture principles
Agile teamwork
Git version control

Challenges We Faced

Like any real software project, SwiftGo wasn't built without obstacles.

Some of the biggest technical challenges included:

Synchronizing Seat Reservations

Preventing multiple users from booking the same seat at the same time.

Live Location Updates

Balancing GPS accuracy with battery consumption.

Trip State Management

Handling every trip stage correctly:

Waiting
Accepted
Started
Active
Completed

Performance

Ensuring maps and route information load quickly without affecting the overall user experience.

What We Learned

SWIFT GO became much more than a graduation project.

It taught us how software engineering works beyond writing code.

Throughout the project we gained practical experience in:

Requirements Engineering
UI/UX Design
Database Design
Mobile Development
Backend Development
API Integration
Testing
Debugging
Team Collaboration
Version Control
Project Management

Most importantly, we learned how to transform a real business problem into a complete software solution.

Looking Ahead

Although SWIFT GO already provides a complete transportation management workflow, we see many opportunities for future improvements.

Some ideas include:

AI-powered route optimization
Demand forecasting
Predictive fleet maintenance
Driver performance analytics
Fuel consumption optimization
IoT integration
Intelligent scheduling recommendations

These features could help organizations make even smarter transportation decisions using data.

Final Thoughts

SWIFT GO started as a graduation project.

Today, we see it as proof of what a motivated Software Engineering team can accomplish when solving a real-world problem.

Building this platform challenged us technically, strengthened our teamwork, and gave us experience that goes far beyond the classroom.

This project reminded us that great software isn't just about writing code—it's about understanding people, solving problems, and creating technology that makes everyday life a little easier.

We're proud of what we've built, and we're excited to continue improving SwiftGo in the future.

Thank you for reading!

Interested in the project or have feedback?

I'm always happy to connect with fellow developers, recruiters, and software engineers.

GitHub: https://github.com/fadydesoky

LinkedIn: https://www.linkedin.com/in/fadydesokysaeedabdelaziz

Email: fadydesoky45@gmail.com

How I Built Qualioro — A Software Quality Intelligence Tool

Fady Desoky Saeed Abdelaziz — Fri, 24 Apr 2026 13:21:25 +0000

Most teams don’t lack effort — they lack visibility into code quality.

That’s something I kept noticing while working on projects. You ship features, fix bugs, and keep moving… but you rarely have a clear answer to a simple question:

“Is this codebase actually in a good state?”

So I decided to build something that tries to answer that.

The Idea

Qualioro is a lightweight tool that takes a few core engineering metrics and turns them into something actionable:

A quality score
A clear risk level
Practical suggestions on what to improve

The goal wasn’t to build a complex AI system, but rather a simple, explainable model that helps developers make better decisions.

What It Measures

Instead of overwhelming the user with dozens of metrics, I focused on a small set that actually matters:

Bug Density → how many defects exist relative to activity
Code Complexity → how maintainable the system is
Test Coverage → how confident we are in changes
Team Output → development activity balance

These signals are combined into a weighted scoring model that produces an overall quality score (0–100).

This is a simple approach to software quality metrics and code quality analysis.

How It Works

The flow is simple:

Input metrics → scoring engine → analysis output

From that, the system generates:

A quality score
A risk classification (low / medium / high)
A confidence level
Actionable recommendations

There’s also an advanced mode where you can see how each factor contributes to the final score.

Tech Stack

Next.js (App Router)
TypeScript
Tailwind CSS
Recharts

Everything runs client-side — no data is stored or sent externally.

What I Learned

Building this made me realize something important:

Software quality isn’t just about writing clean code — it’s about making quality measurable and visible.

Even a simple model can provide real value if it helps answer the right questions.

It also pushed me to think more in terms of products, not just projects:

Clear problem
Simple solution
Usable interface

Final Thoughts

This started as a university project, but I treated it as a real product.

There’s still a lot that can be improved — especially integrating real repository data and CI/CD pipelines — but the core idea is there.

If you have any feedback or suggestions, I’d genuinely like to hear them.

Try it yourself

If you're curious about how your codebase might score, you can try the tool directly:

Live Demo: https://qualioro.vercel.app/
GitHub Repository: https://github.com/Fadydesoky/Qualioro

If you have ideas, feedback, or want to build something similar, feel free to reach out:

LinkedIn: https://www.linkedin.com/in/fadydesokysaeedabdelaziz/

Sentiment Analysis Using NLP: Visualizing Emotions in Text with Python and Power BI

Fady Desoky Saeed Abdelaziz — Fri, 17 Apr 2026 00:45:04 +0000

Introduction

Sentiment analysis is one of the most practical applications of Natural Language Processing (NLP).

In this project, I explore how to perform sentiment analysis on a short story and visualize emotional patterns using Python and Power BI.

The goal is simple: transform raw text into meaningful insights.

In this guide, we’ll walk through how to perform sentiment analysis using NLP step-by-step.

What is Sentiment Analysis in NLP?

Sentiment analysis is a technique used in NLP to determine whether a piece of text expresses a positive, negative, or neutral emotion.

It is widely used in:

Customer feedback analysis
Social media monitoring
Product reviews

In this case, I applied sentiment analysis to a literary text to understand how emotions evolve throughout a story.

Project Idea

Most people read stories…

But what if we could analyze how a story feels?

I used “The Tell-Tale Heart” by Edgar Allan Poe and broke it into smaller segments, then applied sentiment analysis to each part.

This allowed me to track emotional changes across the narrative.

How to Analyze Text Using NLP

The workflow for this project was:

Load and clean the text
Split the text into segments
Apply sentiment analysis
Generate a structured dataset
Visualize the results

Here’s a simplified Python example:

from textblob import TextBlob

text = "I felt nervous and terrified."
blob = TextBlob(text)

sentiment = blob.sentiment.polarity
print(sentiment)

This returns a sentiment score that helps classify the emotional tone of the text.

Building a Sentiment Analysis Dataset

After processing the text, I created a dataset like this:

   Segment  | Label   | Score
   1        | Positive| 0.91
   2        | Negative| 0.45

This step is critical because it transforms unstructured text into structured data that can be analyzed and visualized.

Visualizing Sentiment Analysis Results Using Power BI

Once the dataset was ready, I built a dashboard using Power BI to visualize:

Emotional trends over time
Distribution of positive vs negative segments
Key moments of emotional intensity

Sentiment analysis dashboard using NLP and Power BI

This helped turn raw numbers into a clear emotional narrative.

Key Insights from the Analysis

The story appears mostly positive overall (~56%)
However, it contains frequent sharp emotional drops
These drops align with moments of tension and psychological intensity

This shows that even if a story seems balanced overall, emotional spikes reveal its most impactful moments.

What I Learned

How to apply sentiment analysis using NLP in a real project
How to transform text into structured datasets
How to visualize insights using Power BI
The importance of storytelling in data analysis

Conclusion

This project demonstrates how sentiment analysis using NLP can go beyond traditional use cases and be applied to creative domains like literature.

By combining NLP with visualization tools, we can better understand how emotions evolve in any text.

Project Links

GitHub Repository: https://github.com/Fadydesoky/ai-story-sentiment-analysis

LinkedIn: https://www.linkedin.com/in/fadydesokysaeedabdelaziz

If you're interested in sentiment analysis using NLP or building real-world data projects, feel free to explore the full project on GitHub or connect with me on LinkedIn.

[Boost]

Fady Desoky Saeed Abdelaziz — Thu, 05 Mar 2026 22:25:06 +0000

Fady Desoky Saeed Abdelaziz

Mar 5

Why Most Data Projects Fail Before the First Model Is Built

#dataengineering #dataanalytics #dataquality #dataarchitecture

2 min read

[Boost]

Fady Desoky Saeed Abdelaziz — Thu, 05 Mar 2026 18:41:11 +0000

Fady Desoky Saeed Abdelaziz

Mar 5

Why Most Data Projects Fail Before the First Model Is Built

#dataengineering #dataanalytics #dataquality #dataarchitecture

2 min read

Why Most Data Projects Fail Before the First Model Is Built

Fady Desoky Saeed Abdelaziz — Thu, 05 Mar 2026 18:40:51 +0000

Many organizations invest in AI, analytics, and dashboards — yet most data projects fail before the first model is even built.

When people think about data projects, they often imagine machine learning models, predictive algorithms, and complex pipelines.

But in reality, most data initiatives fail long before any model is trained.

Not because the algorithms are weak.

But because the foundation is broken.

The Data Illusion

Organizations today generate enormous amounts of data.

They store logs, transactions, operational records, and performance metrics.

On paper, everything looks ready for analytics.

But when teams actually start working with the data, they quickly encounter problems:

Missing values
Inconsistent formats
Conflicting sources
Undefined metrics
Poor documentation

Suddenly, the project shifts from analysis to data archaeology.

Data Science Starts with Data Reliability

Before any meaningful analysis can begin, teams must answer fundamental questions:

What is the source of truth?
Who owns the dataset?
How frequently is it updated?
What transformations are applied?
Are definitions consistent across departments?

Without clear answers, even the most advanced models produce misleading insights.

The Hidden Cost of Poor Data Foundations

Many organizations invest heavily in analytics tools, dashboards, and AI platforms.

But without strong data foundations, these investments create an illusion of intelligence.

Dashboards become visually impressive but operationally misleading.

Models generate predictions, but the inputs themselves are unstable.

This leads to one of the most dangerous outcomes in data work:

False confidence.

Decisions start relying on numbers that appear precise but are fundamentally unreliable.

Data Engineering Is the Real Backbone

In practice, the majority of effort in data projects is not modeling.

It is:

Data cleaning
Validation
Schema alignment
Pipeline reliability
Monitoring data quality

That is why experienced teams often say:

“80% of data science is data preparation.”

And the better the data infrastructure, the faster meaningful insights appear.

A Simple Rule for Data Teams

Before building any model, ask three questions:

Is the data trustworthy?
Is the definition of the metric consistent?
Can the pipeline reproduce the same dataset tomorrow?

If the answer to any of these is unclear, the problem is not analytical.

It is architectural.

Final Thought

Good data teams do not start with models.

They start with reliability.

Because in data systems, accuracy is not created by algorithms.

It is created by architecture.

If you're interested in systems thinking, data architecture, and enterprise optimization, feel free to connect.

LinkedIn: https://www.linkedin.com/in/fadydesokysaeedabdelaziz

GitHub: https://github.com/fadydesoky

[Boost]

Fady Desoky Saeed Abdelaziz — Fri, 13 Feb 2026 16:14:29 +0000

Fady Desoky Saeed Abdelaziz

Feb 13

Data Is Not a Department — It’s a Decision Architecture

#dataengineering #systemthinking #enterprisearchitecture #processoptimization

2 min read

Data Is Not a Department — It’s a Decision Architecture

Fady Desoky Saeed Abdelaziz — Fri, 13 Feb 2026 12:53:56 +0000

Most organizations say they want to be “data-driven.”

They invest in dashboards.
They build reporting systems.
They hire analysts.

Yet somehow, decisions still rely on intuition, hierarchy, or urgency.

The issue is rarely the absence of data.

It’s the absence of decision architecture.

The Illusion: “We Need More Data"

In many enterprise environments, the default reaction to underperformance is:

“We need better data.”

But when you look closely, the organization often already has:

Historical performance metrics
Operational KPIs
Real-time dashboards
Financial summaries
Compliance reports

The problem isn’t collection.

It’s translation.

Data exists — but decision flow does not.

Where Data Quietly Fails

Over time, I’ve noticed a recurring pattern in large systems.

Reports are generated. Dashboards are circulated. Metrics are reviewed.

But very few questions are clearly defined:

Who owns this metric?
What threshold triggers action?
What happens when it deviates?
Who is accountable for response?
Is there feedback after the decision?

Without these layers, data becomes informative — not operational.

And informative systems do not scale well.

Data Without Structure Becomes Noise

Imagine a KPI dashboard that shows:

Turnaround time
Error rate
Processing backlog
Resource utilization

All useful.

But unless the organization defines:

A decision threshold
A response protocol
An escalation path
A measurable follow-up

The dashboard becomes a passive artifact.

It looks analytical. It feels analytical. But it doesn’t change behavior.

That’s not a data problem.

That’s an architecture problem.

What Decision Architecture Actually Means

Decision architecture is not a tool.

It’s a structured design that connects:

Metrics
Ownership
Triggers
Actions
Feedback loops

In mature systems, every critical metric answers:

When does this require action?
Who initiates the action?
What is the defined response?
How is impact measured afterward?

That is when data becomes operational.

A Practical Enterprise Lens

In large organizations, complexity multiplies quickly:

Multiple regions
Multiple policy versions
Multiple approval layers
Multiple reporting lines

Without structured decision architecture, each layer interprets the same data differently.

Over time, this creates:

Fragmented responses
Delayed interventions
Manual overrides
Invisible technical debt

And eventually, performance issues are treated as isolated incidents instead of systemic misalignments.

The Human Element

There’s also a subtle human factor.

When decision rules are unclear:

Teams hesitate.
Accountability blurs.
Escalation becomes personal instead of structural.

Clear architecture removes ambiguity. It replaces emotion with logic. And it reduces friction across teams.

Data alone cannot do that.

Design can.

From Data Collection to Data Responsibility

Organizations that truly operate on data do something different.

They don’t just measure.

They define:

Ownership boundaries
Trigger conditions
Decision latency limits
Review cycles
Iteration mechanisms

They treat data as infrastructure — not decoration.

Final Thought

Good organizations collect data.

Mature organizations analyze it.

High-performing organizations design decisions around it.

Data is not a department.

It is an architectural responsibility.

And when that architecture is clear, performance becomes a byproduct — not a struggle.

Finally, If you’re interested in systems thinking, enterprise optimization, and designing responsible decision frameworks, feel free to connect.

LinkedIn: https://www.linkedin.com/in/fadydesokysaeedabdelaziz
GitHub: https://github.com/fadydesoky

Originally published on CoderLegion: https://coderlegion.com/11594/data-is-not-a-department-its-a-decision-architecture

[Boost]

Fady Desoky Saeed Abdelaziz — Fri, 06 Feb 2026 09:10:26 +0000

Fady Desoky Saeed Abdelaziz

Feb 6

Modern Enterprise HR Is a Distributed System

#distributedsystems #systemdesign #architecture #processoptimization

2 min read

[Boost]

Fady Desoky Saeed Abdelaziz — Fri, 06 Feb 2026 08:49:05 +0000

Fady Desoky Saeed Abdelaziz

Feb 6

Modern Enterprise HR Is a Distributed System

#distributedsystems #systemdesign #architecture #processoptimization

2 min read

Modern Enterprise HR Is a Distributed System

Fady Desoky Saeed Abdelaziz — Fri, 06 Feb 2026 08:48:38 +0000

A Systems Thinking Perspective

Most people see HR as administration, policies, forms, and approvals.

But inside large organizations, HR operations behave much more like distributed systems than administrative departments.

And if you don’t approach them architecturally, inefficiency becomes structural.

Enterprise Processes Are Systems

In software engineering, we think in terms of:

Inputs
Logic
Dependencies
Outputs
Failure points

Large-scale enterprise operations follow the same pattern.

An employee lifecycle workflow may appear simple: Onboarding → Payroll → Benefits → Exit

But under the surface, it involves:

Conditional logic
Policy variations
Data validation layers
Approval chains
Historical record dependencies

The complexity isn’t visible — but it’s real.

Where Enterprise Operations Usually Struggle

Across industries, common patterns emerge:

Hidden Dependencies
Processes rely on assumptions that aren’t formally documented.
Version Drift
Policies evolve, but legacy data doesn’t always align with updated logic.
Manual Overrides
Temporary fixes become permanent workflow fragments.
Data Fragmentation
Different business units may interpret similar rules differently.

These are not HR problems, They’re architecture problems.

The Systems Thinking Shift

When you stop treating enterprise operations as tasks and start viewing them as systems, optimization changes.

Instead of asking:

“How do we process this faster?”

You begin asking:

Where is the structural bottleneck?
What logic is implicit rather than explicit?
Which step creates cascading impact downstream?
Is automation accelerating inefficiency?

That shift transforms operational thinking.

Automation Is Not Optimization

Many organizations rush to digitize workflows; Digitizing a flawed structure doesn’t fix it, but scales it.

Optimization starts with:

End-to-end process mapping
Clear ownership definitions
Policy logic documentation
Dependency isolation
Data integrity validation

Only then does automation create value.

Why This Matters for Engineers

Software engineers are trained to think structurally.

Enterprise environments increasingly require that mindset — even outside traditional technical roles.

Whether the domain is:

HR
Finance
Supply chain
Sustainability

The core principle remains:
Systems thinking reduces complexity before technology reduces effort.

Final Thought

Enterprise efficiency is rarely limited by tools, it’s limited by architecture. And architecture exists far beyond code.

Connect with me
Via LinkedIn: https://www.linkedin.com/in/fadydesokysaeedabdelaziz
Via GitHub: https://github.com/fadydesoky

[Boost]

Fady Desoky Saeed Abdelaziz — Thu, 22 Jan 2026 12:58:05 +0000

Fady Desoky Saeed Abdelaziz

Jan 22

Modern Systems Don’t Fix Missing History

#digitaltransformation #softwareengineering #processesoptimization #careerdevelopment

2 min read