DEV Community: Mohamed Ali

Know Someone Who Struggles With Medical Reports and Care Plans? Meet NipCure.

Mohamed Ali — Mon, 05 Oct 2026 01:08:11 +0000

I Built NipCure for My Grandparents 🩺

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

When I saw the Build for a Friend challenge, I immediately thought about my grandparents and how difficult medical reports can be to navigate when you're not familiar with medical terminology.

A medical report can contain medications, instructions, warnings, follow-up appointments, dietary information, and other important details spread across several pages. The problem isn't necessarily accessing the report. It's understanding what information matters, what needs attention, and what should be remembered afterward.

So I decided to build something around that problem.

That project became NipCure.

Meet NipCure

NipCure is a healthcare assistant designed with older adults in mind. The main idea is simple: the user uploads a medical report, and NipCure transforms the information already contained in that document into a structured Care Plan that is easier to read and follow.

I wanted the interface to stay simple enough for someone who isn't very comfortable with technology. That influenced the layout, typography, navigation, and the number of actions presented on each screen.

The user can create an account and provide some information about themselves.

The profile can include information such as age, allergies, dietary restrictions, food preferences, and additional notes. This information provides context for personalization, but it does not replace the medical report. The report remains the primary source of medical information.

Demo

Here is a short walkthrough of NipCure, showing the main flow from uploading a medical report to generating and reviewing the Care Plan.

Watch the NipCure Demo

The demo focuses on the actual application workflow: creating a profile, uploading a medical report, processing it with the local AI pipeline, reviewing the generated Care Plan, exploring educational resources, and using voice assistance.

Turning a Medical Report Into a Care Plan

The main workflow starts with a PDF. The user uploads their medical report directly into NipCure.

The backend extracts the text from the document and sends it through the AI pipeline. This is where Gemma 3 becomes the core of the application.

I'm running Gemma 3 locally through Ollama, rather than relying on a proprietary cloud LLM for the core medical-document processing.

The workflow looks like this:

Medical Report
      ↓
   PDF Text
      ↓
   Gemma 3
      ↓
Structured Medical Plan
      ↓
Profile Comparison
      ↓
   Care Plan

The goal isn't simply to summarize the PDF into another paragraph. I wanted the result to be structured around information that is actually useful to the person reading the report.

The Care Plan can organize medications mentioned in the report, instructions, important warnings, dietary information, follow-up appointments or tests, and questions that may be worth discussing with a doctor.

Instead of searching through several pages of medical terminology, the user gets a clearer view of the information already contained in the original document.

An important design constraint is that NipCure should not invent medical information. The medical report remains the source, while the AI organizes the information into a more accessible format.

Personalization Without Changing the Source

The patient profile becomes useful when the information in it needs to be compared with the report.

For example, a profile may contain an allergy or dietary restriction that appears to conflict with something mentioned in the medical document. I didn't want the AI to simply decide which information was correct and silently modify the result.

Instead, NipCure can identify the potential conflict and mark it as Needs verification.

The report remains the primary source, while the profile provides additional context. The AI can therefore surface something that deserves attention without making the medical decision itself.

The principle is straightforward:

Medical Report = Source
Patient Profile = Context
AI = Organizer
Uncertainty = Visible

This keeps the system focused on document understanding and personalization rather than autonomous medical decision-making.

Why Gemma 3 Runs Locally

One of the main technical decisions behind NipCure was running Gemma 3 locally through Ollama.

Medical reports can contain sensitive personal information, so I wanted the core AI workflow to be capable of running directly on the user's machine instead of making the application dependent on a proprietary cloud LLM.

The architecture is straightforward:

PDF
 ↓
FastAPI
 ↓
Ollama
 ↓
Gemma 3
 ↓
Structured Care Plan

This is also where the open-weight nature of Gemma becomes particularly useful. With Gemma 3 + Ollama, I can control where inference happens and how the model is integrated into the application.

Instead of treating the model as a remote API that receives a document and returns an answer, the model becomes part of the application's local architecture.

For NipCure, that was an important design choice because the application is built around personal documents.

Voice Assistance with ElevenLabs

Another part of the project is making the generated information easier to access.

NipCure includes voice assistance so that the Care Plan can be listened to instead of relying entirely on the visual interface. The application uses ElevenLabs for text-to-speech, with a browser speech fallback when the external service is unavailable.

This fits into the accessibility goal of the project: the Care Plan should not only be structured clearly, but should also be available through more than one interaction method.

Educational Resources with SerpApi

The Care Plan isn't always the end of the user's journey. Someone may want to learn more about a medical topic mentioned in their report.

For this, NipCure includes an educational resources section.

I use SerpApi to retrieve relevant educational search results. These results are intended for learning and exploration and are kept separate from the medical-plan generation process.

In other words, a search result doesn't get to rewrite the medical report or modify the Care Plan generated from it.

This separation helps keep the medical document as the primary source while still giving the user a way to explore related information.

What's Under the Hood?

NipCure combines a local AI stack with a few external services.

The frontend is built with HTML, CSS, and JavaScript, while the backend uses Python and FastAPI. PostgreSQL stores users, profiles, and reports, with JWT-based authentication handling access to user-specific data.

The AI layer is built around Gemma 3 and Ollama. For additional functionality, ElevenLabs provides voice generation and SerpApi provides educational resource discovery.

The overall architecture looks like this:

                         NipCure
                            │
             ┌──────────────┴──────────────┐
             │                             │
         Frontend                       FastAPI
             │                             │
             │                 ┌───────────┼───────────┐
             │                 │           │           │
             │             PostgreSQL   PDF Text    Ollama
             │                                         │
             │                                      Gemma 3
             │
             ├── Care Plan
             ├── Voice → ElevenLabs
             └── Resources → SerpApi

I also added structured output validation around the AI response so that the frontend doesn't simply trust whatever format the model happens to return. The model output needs to match the structure expected by the application before it becomes part of the Care Plan.

Why Open Innovation Matters

For me, the value of open innovation isn't simply being able to say that I used an open model. It's the control it provides during development.

With Gemma 3 and Ollama, I can run the core model locally, experiment with the inference setup, and integrate the model directly into the backend without making the entire application dependent on a proprietary LLM API.

That changes the architecture from simply consuming an AI service to actually integrating an AI model into the application.

For a project involving personal documents, having that choice is particularly useful.

A Few Important Boundaries

NipCure is a document understanding and personalization assistant, not a doctor and not a replacement for professional medical advice.

The application should not invent medications, dosages, diagnoses, or warnings. It should not silently change information from the medical report, and external search results should not be treated as medical advice.

The medical report remains the primary source, the patient profile provides additional context, and potential conflicts are surfaced as Needs verification rather than automatically resolved.

For development and testing, the project should use synthetic or properly de-identified medical documents.

🏆 Prize Categories

Best Use of Gemma

NipCure uses Gemma 3 locally through Ollama as the core AI model for understanding uploaded medical reports and generating the structured Care Plan.

Build for a Friend

NipCure was built with my grandparents in mind, with a focus on making medical information easier to understand and access for older adults.

Why "NipCure"?

The name comes from Nippur + Cure.

Nippur is associated with one of the oldest known medical texts, so I wanted the name to connect the history of recorded medical knowledge with a modern AI approach.

In a way, NipCure takes an ancient idea — recording and organizing medical knowledge — and gives it a 21st-century AI upgrade.

What's Next?

NipCure is still a project, and there is plenty of room to improve it. Better document understanding, stronger structured-output validation, additional accessibility features, multilingual support, and more robust conflict detection are some of the areas I would like to explore next.

The core idea, however, remains simple: take the medical information that a patient already has and make it easier to understand, navigate, and review.

Built for my grandparents. Built for a friend. 🩺

Code

NipCure is open source. The complete source code is available on my GitHub repository:

NipCure — GitHub: https://github.com/MohamedAli1937/NipCure

Looking for Teammates for NASA Space Apps Challenge 2026 | Europe / MENA / Worldwide

Mohamed Ali — Wed, 12 Aug 2026 08:15:38 +0000

Hey everyone! 👋

I’m Mohamed Ali, a Software Engineering student from Tunisia 🇹🇳, and I’m planning to participate in the NASA Space Apps Challenge 2026.
I’m currently looking for motivated teammates from Europe, MENA, or nearby time zones so communication and collaboration during the hackathon are easier. I’m also open to people from anywhere in the world if the team fit is good.

About me
🎓 Software Engineering student
🤖 Interested in AI/ML, Computer Vision & Data Science
🐍 Python, C++, Java, SQL
🧠 Experience with Machine Learning and Deep Learning projects
🌍 Interested in Space Tech, Earth Observation & scientific applications
🔗 Also interested in Blockchain/Web3
💻 Comfortable with Git/GitHub and collaborative development
🇹🇳 Based in Tunisia —CET / UTC+1

Looking for
I’d especially like to find people interested in:
AI / Machine Learning
Data Science
Satellite & Earth Observation data
Astronomy / Space Science
Backend / Full-stack development
UI/UX & data visualization
Scientific research

You don’t need to be an expert. I’m mainly looking for people who are motivated, communicative, and willing to actually build something during the challenge.

Ideally, we could form a small team before the event, discuss the challenges when they are released, choose one that fits our skills, and build a solid project together.

Preferred time zones: Europe / MENA / UTC±2–3, but everyone is welcome.

If you’re interested, comment below or DM me with:
Where you’re from / timezone
Your main skills
Any previous hackathon/project experience
What you’d like to contribute to the team

From Educational Shell to AI-Powered Terminal: Finishing My C++ Project with Local LLMs

Mohamed Ali — Sun, 07 Jun 2026 19:30:31 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built MyShell, a customizable command-line shell written in C++ for Windows that combines a Linux-style command experience with local AI-powered command translation.

This project started as a purely educational project. My goal was to understand how terminals and operating systems work behind the scenes by building a shell from scratch. Instead of only learning the theory, I wanted to explore command parsing, process creation, file system operations, and terminal interfaces by implementing them myself.

The shell originally provided basic commands such as directory navigation, file operations, and external command execution. It was a great way to learn how a terminal communicates with the operating system and how command interpreters are structured internally.

When I discovered the GitHub Finish-Up-A-Thon Challenge, I saw it as the perfect opportunity to revisit the project and push it much further than its original educational scope. Rather than leaving it as a learning experiment, I decided to transform it into a more complete and modern terminal experience by adding AI-powered features, safer command execution, and a cleaner architecture.

Today, MyShell supports built-in commands, external program execution, command chaining, file management, and natural language interaction powered by a local LLM.

One of the main goals of the project is to make command-line interfaces more approachable. Instead of memorizing commands, users can simply describe what they want to do and let the shell translate their request into executable commands.

Screenshot

Repository

GitHub Repository:

https://github.com/MohamedAli1937/Cpp-Shell

Features Demonstrated

Linux-style commands on Windows (ls, pwd, mkdir, touch, rm)
External program execution
Command chaining with &&
AI-powered natural language command translation
Safety previews and confirmation prompts for potentially dangerous operations
Local LLM integration through llama.cpp

Example

ai create folder src and a file main.cpp inside

Translated into:

mkdir src && cd src && touch main.cpp

The shell then analyzes the generated command, checks its risk level, shows a preview when necessary, and executes it after user confirmation.

Since the AI runs locally through llama.cpp, no cloud API is required and users can choose whichever GGUF model they prefer.

The Comeback Story

When I started this challenge, MyShell was already working but felt unfinished.

The original version included:

Basic command parsing
Directory navigation
File and folder operations
External command execution
Colored terminal output

It successfully achieved its educational purpose, but there were many ideas that I had never implemented.

The Finish-Up-A-Thon gave me the motivation to finally return to the project and build the features I had been postponing.

What I Added

🤖 AI Command Translation

The biggest addition was a local AI system that allows users to interact with the shell using natural language.

Instead of typing commands manually, users can now write:

ai show me all files

and the shell automatically translates it into:

ls

More complex requests can also be converted into multiple commands:

ai create folder src and a file main.cpp inside

↓

mkdir src && cd src && touch main.cpp

🛡️ Safety Layer

AI-generated commands can be powerful, but they can also be dangerous.

To make the feature safer, I implemented:

Command planning
Risk classification
Dangerous operation detection
Confirmation prompts before execution

This prevents accidental destructive operations while keeping the workflow simple.

🔗 Command Chaining

I added support for chained commands using &&, making it possible to execute complete workflows in a single instruction.

📁 Improved File Operations

The shell gained:

touch command support
Multiple file creation
Multiple folder creation
Recursive deletion support
Better command handling

🏗️ Better Architecture

To support future growth, I reorganized the project into dedicated AI modules:

AIManager
LLMInterface
CommandPlanner
SafetyChecker
Preview

This separation made the codebase cleaner and easier to maintain.

The project now feels much closer to the vision I originally had: a customizable shell that combines traditional command-line workflows with modern AI assistance.

My Experience with GitHub Copilot

GitHub Copilot played a significant role during the AI upgrade phase of this project.

One area where it helped a lot was building the communication layer between MyShell and the local llama.cpp server. Working with WinHTTP in C++ can be verbose, and Copilot frequently suggested the boilerplate required for HTTP requests, response handling, and error checking, which saved a considerable amount of time.

It was also useful when creating the new AI architecture. While designing classes such as AIManager, LLMInterface, CommandPlanner, and SafetyChecker, Copilot often completed repetitive class definitions, constructors, and method implementations, allowing me to focus more on the overall design of the system.

Another place where it helped was command-processing logic. When implementing command chaining, argument parsing, and safety checks, Copilot suggested code patterns that sped up development and helped reduce repetitive typing.

I still made all architectural decisions myself, but Copilot acted like a pair programmer that handled much of the boilerplate while I focused on the behavior and user experience of the shell.

For a project that combines systems programming, command parsing, and AI integration, that productivity boost was incredibly valuable.

What's Next?

MyShell is still evolving. Some features I would like to add next include:

Command piping (|)
I/O redirection (>, <)
Background process execution
Smarter context-aware AI command generation
Additional built-in commands
Cross-platform support
Better support for local AI models

This challenge helped me transform MyShell from a simple educational experiment into a much more complete project. More importantly, it gave me a reason to finally finish features that had been sitting in my backlog for months.

Thanks to GitHub and DEV for organizing the Finish-Up-A-Thon and motivating developers to bring unfinished projects back to life.

🚀 GitFlow Dashboard: From Paused Side Project to v1.0.0

Mohamed Ali — Thu, 04 Jun 2026 11:32:25 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

GitFlow Dashboard is a desktop application built with Electron, React, and TypeScript that helps developers visualize and manage their GitHub workflow in one place.

The idea started while I was contributing to open source projects and preparing GSoC applications. I found myself constantly switching between GitHub, Git, project boards, issues, pull requests, and local development tools.

To solve that problem, I started building GitFlow Dashboard: a unified workspace for managing the entire development pipeline.

The project began as a basic prototype with GitHub integration and a Kanban board. While the foundation was there, it was far from complete and lacked many of the features needed for a polished user experience.

The GitHub Finish-Up-A-Thon gave me the motivation to return to the project and finally turn it into something I could confidently release.

🎥 Demo

https://github.com/user-attachments/assets/e8f63577-7135-44d3-997e-246d6450c31c

Repository

https://github.com/MohamedAli1937/GitFlow-Dashboard

Download : Windows Installer (v1.0.0)

👉 GitFlow.Dashboard-Windows-1.0.0-Setup.exe

✨ Features

GitHub authentication
Login and signup flow
Multi-account support
Kanban board workflow management
Repository integration
Pull request tracking
Issue tracking
Branch visualization
Branch management view
GitHub account statistics
Quick "View on GitHub" actions
Integrated help guide
Improved UI/UX design
Desktop application packaging
Release management

📸 Screenshots

Login Page

Repository Dashboard

Contributions Dashboard

🔥 Before vs After

Before

The project existed before the challenge but was still an unfinished prototype.

What existed:

Basic GitHub integration
Early Kanban board
White theme UI
Limited workflow visibility
No authentication
No account management
No releases

After (Finish-Up-A-Thon Version)

What was added:

Modern dark theme redesign
Login & signup system
Multi-account support
Branch management
GitHub account statistics
Built-in help guide
Improved documentation
Production-ready packaging
Release v0.1.0
Release v1.0.0

🔄 The Comeback Story

GitFlow Dashboard started before the GitHub Finish-Up-A-Thon challenge.

I began building GitFlow Dashboard in early May 2026 and implemented the first core features, including GitHub integration and a Kanban board. However, university exams arrived, and I had to put the project on hold before it reached the level I originally envisioned.

When I discovered the GitHub Finish-Up-A-Thon challenge, I saw it as the perfect opportunity to return to the project and finally finish what I had started.

During the challenge, I redesigned the interface, added authentication, implemented multi-account support, introduced branch management features, added account statistics, created a help guide, improved documentation, prepared releases, and shipped the first stable version: v1.0.0.

What began as a paused side project became a complete desktop application that developers can actually use to manage their GitHub workflow.

🛠 Major Improvements

Authentication & Account Management

Added login and signup functionality
Added support for multiple GitHub accounts

User Experience

Redesigned the interface
Improved navigation and usability
Added a built-in help guide

GitHub Workflow Features

Added branch viewing and management
Added account statistics
Added quick links to open repositories directly on GitHub

Project Quality

Improved documentation
Expanded the README
Added demo content
Prepared production builds

Releases

Published a test release (v0.1.0)
Published the first stable release (v1.0.0)

🤖 My Experience with GitHub Copilot

GitHub Copilot played an important role throughout the finishing process.

I used Copilot to:

Accelerate UI development
Generate boilerplate code
Refactor components
Improve TypeScript typings
Debug implementation issues
Draft documentation and README improvements
Explore alternative implementation approaches

Rather than replacing development work, Copilot acted as a productivity partner that helped me move faster and spend more time refining the overall experience.

🚀 What's Next?

Although GitFlow Dashboard has now reached its first stable release, I plan to continue improving it with:

GitHub Actions integration
Enhanced analytics
Notifications and activity tracking
Additional workflow automation features

This challenge helped me finally finish a project that had been sitting unfinished during my university exam period and transform it into a real release that developers can use.

Thanks for reading!