Ahmed Mustafa — Software Engineer | Flutter | Next.js | SaaS. Building scalable mobile apps, web platforms and SaaS products.Building |

Radar - Financial Analytics Platform

Flutter App · SaaS Platform · Web App · Backend & API · AI & LLM · Data & Analytics · UI/UX Design

Category: Financial Analytics · Trading Journal · Risk Management Focus: Egyptian Stock Exchange · Data Analysis · AI OCR · Portfolio Analytics · Offline-first Radar is a financial analytics and trading-journal platform built specifically for the Egyptian Stock Exchange. It combines market liquidity data, trade journaling, position sizing, risk management, performance analytics, and AI-powered extraction into a single system designed around one question: Was this trade actually a good decision? The product is intentionally not a trading platform and does not provide buy/sell recommendations. Instead, it helps investors understand what happened in the market, what they decided, how much they risked, and whether they followed their own plan. The problem Most retail investors remember their winning trades. They don't always remember: Why they entered. Why they exited. How much they actually risked. Whether the position size was appropriate. Which type of setups consistently work for them. Which recommendation sources actually perform. Whether a losing trade was a bad decision or simply a normal loss. A simple transaction history cannot answer these questions. Radar was designed to turn individual trades into structured, measurable data that can be analyzed over time. Market Intelligence Following the money One of Radar's core features is tracking investor flows in the Egyptian Stock Exchange. The platform organizes every session across six investor categories: Egyptian Institutions Egyptian Individuals Arab Institutions Arab Individuals Foreign Institutions Foreign Individuals This allows users to see where buying and selling pressure is coming from and how liquidity is moving between institutions and individuals. The underlying figures are based on published Egyptian Exchange data rather than being presented as proprietary predictions. The important distinction is that Radar separates: Market facts → User interpretation It shows what happened rather than pretending to predict what happens next. Risk Management Before the Trade Radar treats risk management as something that happens before entering a position, not after the loss. The position-sizing engine takes: Capital Maximum allowed risk Entry price Stop-loss Target and calculates: Recommended number of shares Position value Maximum monetary loss Potential profit Risk percentage R-Multiple For example, a trade can be evaluated as: 2.46R before the user commits capital. The system also explicitly flags positions that exceed the user's predefined risk limit instead of leaving the calculation to mental arithmetic. The Trade Is More Than Entry & Exit Radar maintains a complete timeline for each position. A trade can contain: Entry Stop Target Position size Notes Historical decisions Partial exits Stop movements Chart screenshots Trade classification Recommendation source This turns the platform from a basic portfolio tracker into a decision journal. Measuring Discipline Instead of Luck One of the product's central ideas is the Discipline Score. Every trade receives a score from 0–100 based on four controllable behaviors: Pre-trade checklist completed Risk within the allowed limit Stop-loss defined correctly Reason for the trade documented The score deliberately ignores the trade's financial outcome. A losing trade can receive 100/100 if it followed the plan. A profitable trade can receive a low score if it was taken recklessly. This separates: Decision quality ≠ Outcome That distinction is fundamental to making the analytics useful rather than simply rewarding profitable results. Performance Analytics Once enough trades are recorded, Radar turns the journal into measurable performance data. The platform analyzes metrics such as: Mathematical expectancy Profit factor Average R Median R Maximum winning streak Maximum losing streak Best trading day Worst trading day Best month Worst month Average holding duration Performance by trade classification Performance by recommendation source Equity curve This allows the user to answer questions such as: "Do my breakout trades actually outperform my swing trades?" or: "Which recommendation source is actually making me money?" rather than relying on memory. AI-Powered Recommendation Extraction Radar also contains an AI OCR workflow for extracting trading information from recommendation screenshots. The user can upload a recommendation image and Radar extracts relevant prices and trade information using Gemini. A deliberate privacy decision was made here: The user provides their own Gemini API key. The key is stored locally on the user's device/browser. The image is sent to Google only when the feature is used. The image is not stored on Radar's server. Without a configured key, the feature remains disabled. This keeps the AI feature useful without turning Radar into a repository of users' private trading screenshots. Offline-first Radar was designed with offline usage in mind. After authentication, the mobile application can continue operating without an internet connection for: Recording trades Managing positions Calculating analytics Managing account settings Internet connectivity is only required for operations that genuinely depend on external services, such as market closing prices, backups, and AI image processing. This creates a fundamentally different architecture from a simple cloud-only dashboard. Data Privacy Privacy is treated as part of the product architecture rather than a marketing statement. Users' trading records are protected through account-level access controls, while locally stored information remains on the user's device. The system also allows users to delete their account and associated data. Radar deliberately avoids: Advertising Trading execution Broker integration Investment recommendations The platform's role is to record, calculate, analyze and educate through the user's own data. Financial Goal Planning Radar also includes a financial goal calculator. Users can define: Target amount Investment period Expected annual return Current capital Monthly contribution The system calculates the required contribution and separates the amount contributed by the user from the amount generated through assumed compounding. Importantly, the return is explicitly treated as a user-provided assumption, not a prediction or guarantee. One Product, 12 Tools Radar brings together 12 focused tools covering the entire trade lifecycle: Before entering Position Size Calculator Pre-trade Checklist Watchlist AI Recommendation Reader While holding Today's Decisions Closing Prices Trade Timeline Chart Attachments After closing Discipline Score Equity Curve Performance by Classification Performance by Source The architecture is organized around the complete lifecycle: Plan → Enter → Manage → Exit → Analyze → Learn. Engineering Philosophy The most important engineering decision in Radar is that the product is not trying to predict the market. It is trying to make the user's own decisions measurable. That leads to a very different product architecture: Market Data ↓ Structured Financial Data ↓ Trade Planning ↓ Risk Calculation ↓ Trade Execution Record ↓ Performance Metrics ↓ Behavior / Discipline Analysis ↓ Better Future Decisions AI is used where it adds real value — such as extracting structured information from unstructured recommendation images — while deterministic financial calculations remain deterministic. That separation is important in a financial application. Product Status Radar is currently available as a web application and is in an early product stage. The current version focuses on: Egyptian Stock Exchange Long positions Trade journaling Investor-flow data Risk management Performance analytics AI recommendation extraction An Android application is also part of the product roadmap.

Ather

Athar Category: Flutter App Tech stack: Flutter · Dart · Cubit · GetIt · gorouter · Kotlin · Shorebird Athar is a production Islamic companion app on Google Play, built around a single constraint that shaped almost every decision in it: it has to work with no internet, and it has to collect nothing about the person using it. Most apps in this category are thin clients. They fetch prayer times from a server, stream the Quran from someone else's CDN, and carry an analytics SDK that knows more about the user's day than the user does. Athar computes what it can, downloads only what it must, and ships no telemetry of any kind. The engineering below is mostly the cost of holding that line. The problem that set the direction The app originally fetched prayer times from a REST API. A user reported it plainly: "when I'm away from home, the prayer times don't work." The times worked on wifi and failed on a journey — which is precisely when someone most needs to know when to pray. Prayer times are solar geometry. They are computable to the minute from coordinates and a date, and needing a server for them was never anything but a dependency I had not removed yet. I moved the whole calculation on-device, with twelve calculation conventions (Umm al-Qura, Muslim World League, Karachi, Diyanet and others), both madhhabs, and per-prayer minute corrections so a user can align the app to the mosque they actually pray in. The calculation is pinned by tests against the published output of AlAdhan for six cities, two solstices and both madhhabs — because "I rewrote the maths and it looks about right" is not something to ship into someone's prayer times. Architecture Feature-first Clean Architecture across 25 features and roughly 430 Dart files, with data, domain and presentation separated per feature and dartz's Either carrying failures across boundaries instead of exceptions crossing them. Repository pattern over every source: prayer times, the Quran text and its page geometry, six tafsirs, the recitation catalogue, an endowment library, hadith, bookmarks, reading progress. Cubit for state, with locator-held singletons for anything that outlives a screen — the reader's position, the tasbeeh tally, the notification schedule — and per-screen instances where state must not leak between views. gorouter stateful shell so each tab keeps its own navigation stack. The native layer Eleven Kotlin classes, because parts of this cannot be done from Dart: An exact-alarm scheduler that arms several days ahead, re-arms itself when one fires, and rebuilds the chain after a reboot. Android's Doze mode batches inexact alarms, which is why reminders used to arrive four at a time an hour late — a bug that only exists on a real device, left idle, overnight. A foreground media service for the adhan, so it plays with lock-screen controls and can be stopped from the notification shade. Three home screen widgets — prayer times, an ayah, a du'a. A vibration channel. Flutter's HapticFeedback routes through View.performHapticFeedback, which Android silently drops whenever the system's touch-feedback setting is off — the default on several skins. The tasbeeh counter buzzed on some phones and not others, and raising the impact strength changed nothing, because the strength was never the problem: the call was not arriving. Talking to the vibrator directly fixed it. Size, and what it costs to be complete The Madinah mushaf renders from 604 fonts — one per page, about 67 MB. Bundling them is the obvious approach and it puts 67 MB into every install, including for the majority who never open the mushaf view. They are fetched per page on first view and cached, alongside the same treatment for tafsirs, hadith and the library. The user's download went from 85 MB to 21 MB, and the app still contains all of it. The largest of those is an endowment library of 63,433 books, browsable and readable in-app, downloaded per book with a checksum — because a truncated download is still a file, and without a digest it sits on the shelf looking installed and opens to half a book. Privacy as an enforced constraint No Firebase. No analytics. No crash reporting. No advertising SDK. No account, no login, no server of my own that user data could reach. This is enforced rather than intended: cleartext traffic is disabled app-wide with a single documented exception, every URL parser rejects a non-https scheme, and a test reads the published privacy policy and checks it against the app's own constants — so the policy cannot drift away from what the code does. It had drifted once: the policy still described sending coordinates to a third party months after the calculation moved on-device, which is an overstatement, but a policy that does not describe the app is a broken policy in either direction. What it does Quran — the Madinah mushaf, ayah-by-ayah reading, six attributed tafsirs, 241 reciters across 20 riwayat, verse-level audio timing that highlights the ayah as it is recited, bookmarks, khatma plans, and a memorisation mode that hides the verse until you have recited it. Prayer & adhan — on-device times, a month table, twelve conventions, per-prayer sounds, a pre-prayer notice, an iqama offset, and a sahih hadith attached to every prayer notification with its grade and source. Library — 63,433 books, searchable, with multi-volume works handled as one download. Daily — azkar with a configurable typeface and size, du'a, the full ruqya, hadith, seerah, prophets' stories, a Ramadan section, qibla by compass, a tasbeeh counter, a deeds tracker, user-written reminders, and Quran radio. Engineering practice 731 tests, and the interesting thing about them is not the number. Most were written against one specific failure, and several assert that the bug still reproduces without the fix — so the test cannot quietly pass for its own reasons. Some are structural, and each exists because that class of bug shipped once: one reads every assets/ path in the source and demands pubspec.yaml declare it — after a JSON file sat in the repo undeclared for months, so a whole feature had never once worked; one rejects any context.read() in a screen that cannot reach a provider — after a settings toggle threw on every tap, saved the preference, swallowed the error, and did nothing; one refuses to offer a font in a picker that the app does not actually bundle — after two fonts were referenced, credited and licensed without ever being shipped. Every release carries a changelog entry, enforced by a test, and written for a user of the last published build rather than for me — a fix to something no one has run yet is development history, not news. Delivery uses Shorebird code push for Dart-only fixes and Play In-App Updates for the rest, so a correctness bug can reach users in minutes instead of a review cycle. Status Published on Google Play and in active development. The store build is an early version; 42 versions of work sit ahead of it — offline prayer times, the library, the media catalogue, the native alarm layer, the support page — now going through a device-testing and bug-fixing cycle before a single large release. Next: publishing that release, then a licensed adhan recording set, and a recitation-checking mode using on-device speech recognition.

Torjoman

Torjoman is a cross-platform enterprise ecosystem engineered to fully digitize organization workflows, management, and live broadcasting. This end-to-end solution bridges the gap between administrators, field managers, speakers, and end-users by orchestrating a production-ready backend with 5 dedicated web and mobile applications. Ecosystem Tech Stack Backend Core: NestJS v11 (Monorepo Architecture) | PostgreSQL 16 | Prisma ORM Context & Security: nestjs-cls (AsyncLocalStorage) | JWT | Global Guards Real-time & Delivery: Socket.io Gateways | Production-Ready Docker Infrastructure Client Apps (Web & Mobile): Flutter | Clean Architecture | BLoC / Cubit State Management | Shared UI Core (torjomancore) The 5-App Ecosystem Architecture The system is engineered as a unified codebase that powers 5 distinct client-side applications tailored for specific user roles: Torjoman Owner (Web): Global platform dashboard for SaaS subscription tracking, resource monitoring, and multi-organization provisioning. Torjoman Admin (Web): Super Admin control panel for single organizations to manage internal roles, managers, and regional settings. Torjoman Manager (Mobile/Web): Operational app for field managers to handle real-time location mapping (coordinates), site-specific setups, and speaker assignments. Torjoman Studio (Mobile): A dedicated mobile streaming app for speakers to initiate live sessions, broadcast audio, and generate on-the-fly transcriptions. Torjoman Live (Mobile/Web): The consumer-facing application allowing users to discover live locations, stream real-time audio, read live transcriptions, and save favorites. Key Engineering & Architectural Solutions Hybrid Multi-Tenancy Engine: Built to natively support both Shared-DB SaaS Mode (commercial multi-tenancy) and Enterprise Dedicated Deployments (private on-premise installation for government ministries) without codebase forking. Automated Data Isolation Layer: Integrated a custom PrismaQueryExtension that automatically intercepts all database transactions to inject organizationId filters dynamically. This guarantees hard logical data isolation between clients and eliminates human-error leaks. Edge Speech-to-Text (STT) Pipeline: Utilizes Device-Side Speech-to-Text on the mobile client apps to process live speech directly into text. This architectural choice bypasses massive audio server storage costs and drastically optimizes network bandwidth. Dynamic Regional Mapping: Supports optional hierarchical data partitioning (useRegions) that can be activated for large-scale state structures or disabled for flat corporate clients. Current Status Core & Network: 100% operational across the multi-tenant backend architecture, Prisma isolation layers, and cross-app communication protocols. Deployment: Fully dockerized, security-hardened, and optimized for end-to-end production environments.

Bella Cosmetics

Bella Cosmetics Category: E-commerce Web Application Focus: Online Store · Product Management · Shopping Cart · WhatsApp Ordering · Responsive UI Bella Cosmetics is a modern e-commerce platform built for a natural personal-care brand, providing customers with a simple way to discover products, browse categories, view offers, and prepare their purchases for ordering. The platform is designed around a straightforward commercial goal: turn a product catalogue into a simple purchasing experience without unnecessary complexity. The problem Small beauty and personal-care businesses often depend heavily on social media and direct messaging to display products and receive orders. That creates several problems: Products are difficult to browse systematically. Prices and offers can become scattered across posts. Customers have no central product catalogue. Finding a specific product takes unnecessary effort. The business has limited control over how its products are presented. Bella Cosmetics was built to provide a dedicated digital storefront where products, categories, pricing, offers, and ordering are organized in one place. Product catalogue The store organizes products into clear categories, including: Skin Care Hair Care The current catalogue includes products such as hyaluronic-acid serum, vitamin C serum, shampoo, body butter, natural oil mixes, lip balm, deodorant cream, and body splash products. Each product is presented with its category, name, description/details where available, and price. Offers & promotions The homepage includes a dedicated offers section for products with limited-time discounts. For example, the current store highlights a hair-care cream with a discounted price compared with its original price. This creates a dedicated commercial space for promotions instead of relying on social-media posts alone. Shopping experience The application provides a shopping-cart experience that allows users to add products while browsing and review their selected items before proceeding with the order. The interface is intentionally simple: the customer can move from: Browse → Product → Cart → Order without going through unnecessary steps. WhatsApp ordering Instead of forcing the business into a complicated payment and shipping infrastructure, the platform integrates the existing customer communication workflow through WhatsApp. Customers can use the WhatsApp contact option to communicate with the business regarding orders and inquiries. This approach is particularly suitable for a growing business that wants an online storefront while keeping order confirmation and customer communication human and flexible. Content & brand experience The website also communicates the brand story rather than functioning as a product grid only. The "Our Story" section presents Bella Cosmetics as a handmade personal-care brand focused on natural and organic ingredients and describes the quality-control process used for its products. This gives the storefront a stronger connection between product discovery and brand identity. Responsive experience The interface is designed as a responsive web experience so customers can browse the catalogue, view products, and manage their cart across different screen sizes. The structure prioritizes: Clear product discovery Simple navigation Category filtering Visible pricing Promotional products Shopping cart access Direct customer communication What I built The project involved developing the storefront experience and connecting the different parts of the shopping journey: Home → Categories → Products → Product Details → Cart → WhatsApp The goal was not simply to create a visually attractive cosmetics website, but to build a practical digital storefront that could support an actual small-business sales workflow. Business outcome Bella Cosmetics transforms a traditional product catalogue into a structured digital storefront where customers can: Discover products. Browse by category. Compare prices. Find current offers. Add products to a cart. Contact the business directly through WhatsApp. The architecture also leaves room for future expansion into more advanced e-commerce capabilities such as online payments, order management, customer accounts, inventory management, delivery tracking, and analytics.

Remontada

Remontada is an interactive, gamified sports trivia application built for a client via Upwork using Flutter. Inspired by popular football challenge shows on YouTube, the game tests users' sports knowledge by displaying dynamic player visual cards alongside contextual textual hints, requiring opponents or single players to strategically guess and reveal the correct football player. 🛠️ Technical Tech Stack Framework: Flutter (Dart) State Management: BLoC / Cubit Pattern (To strictly decouple game progression, timers, and score scoring logic) Architecture: Modular, Clean Architecture (Tailored for seamless addition of new quiz packs) Assets & Performance: High-performance local caching for image assets to minimize rendering latency during fast-paced rounds ⚡ Key Features & Engineering Architecture Dynamic Game State Controller: Engineered a highly responsive state machine using BLoC to handle real-time game flows, managing active rounds, score multiplication, instant feedback loops for correct/incorrect answers, and transition timers. Hint Injection & Image Masking Subsystem: Developed an asynchronous widget structure that seamlessly pairs high-resolution player graphics with specific textual hint strings, managing asset loading smoothly to maintain a constant 60 FPS. Scalable Content Architecture: Structured the codebase utilizing abstract data repositories, allowing the client to easily scale the game by injecting new player packages, seasonal challenges, or multi-category questions via local configuration files. Production-Grade Delivery: Successfully delivered the project on an agile timeline under Upwork's client specifications, ensuring zero UI memory leaks and achieving full cross-platform responsiveness across both iOS and Android platforms. 🚦 Project Status Core Status: 100% Completed, verified, and delivered to the Upwork client. Core quiz pipelines, scoring systems, and asset rendering engines are production-ready.

Prompt Score

Prompt Score is an innovative, web-based utility tool engineered to evaluate, benchmark, and optimize Artificial Intelligence prompts. It provides developers and prompt engineers with a structured, data-driven environment to refine their generative AI inputs, ensuring higher reliability, cost-efficiency, and predictable LLM outputs. 🛠️ Technical Tech Stack Frontend Architecture: Next.js / React (Deployed on Vercel) Styling & UI: Tailwind CSS (Optimized for modern, responsive dashboards) Localization: Built-in Internationalization (i18n) supporting multilingual interfaces (English/Arabic) API Integration: Serverless functions interacting with generative AI scoring models and evaluation metrics ⚡ Key Features & Engineering Impact Automated Prompt Benchmarking: Implements analytical scoring algorithms to grade prompt effectiveness, clarity, and structural constraints before deployment to production LLM pipelines. Token & Cost Optimization: Analyzes prompt length and token efficiency, helping developers reduce unnecessary overhead costs when executing large-scale API requests. Dynamic i18n Subsystem: Features a decoupled, configuration-driven localization architecture that handles seamless locale switching (/en and /ar) without breaking application state or layout. Micro-Frontend/Serverless Deployment: Fully optimized for low-latency delivery using Vercel's edge network, achieving near-instantaneous page loads and fast serverless execution. 🚦 Project Status Production Status: Live, fully operational, and accessible via web. Next Iteration: Integrating an automated multi-model sandbox to test and score a single prompt across various LLMs simultaneously.