• Exact problem: Manual paper-and-pen finance tracking leads to forgotten entries, lost data, and high mental friction — while global finance apps ignore Moroccan categories, informal lending (Sallaf), household sharing (Dar), and multi-unit money (MAD, Centimes, Rial).
• Business impact: Users abandon tracking when network drops (“Recharge”) or when UX feels foreign, so balances stay unreliable and savings/debt goals never stick.
• Technical / operational hurdles: Deliver offline-first sync to Supabase, concurrent multi-user safety with RLS, premium shared household wallets, bill/SMS parsing paths, reliable server-side reminders, and a premium UX (haptics, Lottie, optimistic UI) without leaking raw backend errors.

Architecture & frameworks. Beztami is a cross-platform Flutter app (iOS & Android) using BLoC for state, go_router for navigation, get_it for DI, and Supabase (PostgreSQL) as the secure backend. An offline-first workflow caches transactions locally and syncs automatically when connectivity returns — critical for Moroccan network conditions.

Development process & quality. Core shell: Dashboard (balance in MAD/USD/Centimes/Rial, monthly insights, wallet ledger), Budgeting, central quick-action (+ Expense / Income / Sallaf / Savings), Goals (Savings + Debts toggle), and Settings. Auth covers email/phone/Google, password recovery, profile edit, and permanent account deletion. Quality is enforced through form rules (disabled submit until valid, live validation, password checklists), skeleton/optimistic loading, human-centered errors (“Something went wrong” + clear next steps), and premium micro-interactions (scale presses, staggered lists, semantic haptics, shared-element transitions).

APIs, security & data handling. Financial records live in relational Supabase tables with encryption and strict Row-Level Security so users cannot access each other’s data. Critical reminders (debt due dates, utilities) use Supabase Edge Functions + Cron for reliable push delivery. Premium paths include shared household wallets and automated Factures parsing (SMS/PDF from Lydec, Maroc Telecom, etc.). Onboarding explicitly communicates privacy: data is never sold or shared.

• Product outcome: Capstone-grade Morocco-localized fintech wallet covering tracking, budgeting, Sallaf debts, savings goals, multi-currency display, and offline sync.
• Localization signal: Pre-built categories (L'kra, Hanout, Factures, Dar, Eid/Ramadan) and French/English + Darija hybrid language toggles differentiate Beztami from global alternatives.
• Security & reliability: RLS isolation, encrypted financial records, and hybrid server-side notification architecture for reminders that survive device sleep.
• Reception: Featured ISGI Khouribga capstone demonstrating production-minded architecture and digital strategy (public store ratings/downloads not published yet).

• Exact problem: Cinema apps often feel incomplete when discovery is disconnected from booking — users can browse titles but cannot finish a believable ticket purchase flow in one product.
• Business impact: Without a unified path from browsing to booking, engagement drops after trailers or details, and the product fails to demonstrate real cinema value.
• Technical / operational hurdles: Keep Clean Architecture while using GetX for routing, DI, and reactive UI; integrate live TMDB remote data with local bookmarks and ticket storage; design an interactive seat map and mock checkout that still feel trustworthy.

Architecture & frameworks. Movify uses Clean Architecture with GetX limited to the presentation layer. Pages and controllers call use cases, which reach repositories and data sources (remote TMDB via Dio, local persistence via get_storage). That separation keeps API concerns out of UI widgets and makes discovery vs booking features independently maintainable.

Development process & quality. Key features include a home hero carousel (now playing, upcoming, popular, top-rated), movie details with cast/crew/genres and in-app YouTube trailers, search for movies and actors, bookmarks, an interactive seat map with aisle layout, mock checkout, and a My Tickets tab with QR codes. Problem-solving focused on clear layer boundaries and shimmer loading states so remote latency never feels broken. Quality was reinforced through consistent theming, predictable navigation (Home, Theatre, Tickets, Search), and a domain-first data flow.

APIs & data handling. TMDB API keys are loaded via flutter_dotenv (not hardcoded in UI). Remote calls go through Dio datasources; bookmarks and tickets stay on-device with get_storage. No sensitive payment credentials are stored — checkout is intentionally mocked for demo safety while still exercising the full booking UX.

• Delivered outcome: End-to-end cinema flow — discover → trailer → bookmark → book → pay (mock) → QR ticket — on Android, iOS, Windows, Linux, and Web.
• Product quality signal: Live TMDB catalogs keep content current; local tickets persist across sessions for repeat demo use.
• Architecture result: Presentation stays thin; remote and local data concerns remain testable through use cases and repositories.
• Reception: Built as a portfolio showcase of cinema UX and Clean Architecture discipline (public store ratings/downloads not published yet).

• Exact problem: People lose track of expiry dates and waste products; most utilities either skip auth UX polish or make sign-in feel disconnected from the product story.
• Business impact: If onboarding and account recovery feel incomplete, users abandon before they ever add items — the core value never gets a chance.
• Technical / operational hurdles: Support Google, Apple, guest, and email paths in one cohesive flow; design a full forgot-password journey; keep UI brand-consistent (panda illustrations) without complicating future item-tracking features.

Architecture & frameworks. Koby is Flutter-based with Firebase Auth, flutter_bloc for predictable state, and go_router for explicit navigation between onboarding, login, register, and recovery screens. Feature-first presentation screens sit on a shared core (theme, routing) so item tracking can extend the same shell later.

Development process & quality. Shipped a complete entry experience: welcome with social/guest options, email login and registration, forgot password → new password → success confirmation. Problem-solving focused on making every auth screen feel like one product. Quality was ensured through consistent purple-accent UI, readable forms, clear success states, and BLoC-driven transitions that avoid dead-end routes.

APIs, auth & security. Authentication is handled by Firebase Auth with Google Sign-In and Sign in with Apple. Password recovery uses Firebase’s secure reset path rather than custom credential storage. Session and auth errors surface clearly so users are never left without a recovery path.

• Delivered outcome: Complete auth and recovery funnel ready to support the expiration-tracking product.
• UX signal: Branded panda illustrations and shared visual language across onboarding and auth reduce drop-off between entry screens.
• Foundation result: BLoC + go_router shell is ready for home/item tracking and local expiry notifications.
• Reception: Personal showcase of auth UX craft (public ratings/download metrics not published yet).

• Exact problem: Studio operators relied on slow, error-prone manual Photoshop workflows to circle irises, remove flash, color-correct, and generate framed artwork from templates.
• Business impact: Manual steps slowed delivery, increased rework risk, and made session resume unreliable — hurting turnaround time and consistency for client artwork.
• Technical / operational hurdles: Coordinate a long desktop pipeline (temp files, Hive session state, queue locking, partial edits, heavy Photoshop jobs, Dropbox PSD templates) without losing progress or leaving orphan files; enforce resume rules across Image Prep and Art Studio; support desktop UX (drag-drop, window management) on Windows.

Architecture & frameworks. Built with Flutter desktop (Windows), flutter_bloc, go_router, get_it, and Hive. Feature-oriented structure: Core (router, DI, Dropbox/OAuth, Photoshop JSX services) plus Onboarding, Project Hub, Iris Editor, and Art Studio. BLoC keeps long-running jobs observable; GoRouter session guards route users back to the correct step based on stored paths.

Development process & quality. Key features: client intake with 24h session history; Image Prep with drag-drop and format checks; Iris Editor queue (ellipse circling via Photoshop crop, brush flash removal, color matrix/local masks); Art Studio layouts (solo/duo, square/column/row/rectangle), Dropbox template sync, cancellable generation, print/email handoff. Problem-solving centered on clear resume rules, centralized storage services, and async overlays with cancel/resume awareness. Quality came from gated editor steps, human-readable failure dialogs, temp path hygiene, and dimension-cached artwork history.

APIs, integrations & data security. Dropbox OAuth downloads PSD templates over Dio; Photoshop automation runs through controlled JSX services rather than ad-hoc desktop scripts. Session and artwork metadata live in Hive locally; sensitive OAuth handling stays in dedicated services. Client emails and personalization fields are used only for configured handoff flows — not exposed in UI dumps.

• Operational impact: Delivered a production desktop tool with a repeatable iris-to-print workflow instead of fragile manual Photoshop steps.
• Client outcome: Soulireye reported the app “works just amazing,” that vision was executed as expected, and that Hiba stayed involved at every step with professional solutions.
• Follow-on success: The same client commissioned a second product (Receipt Generation App), reflecting trust and satisfaction with delivery quality.
• User review (Mustapha Kh, Soulireye): “Hiba is an ambitious developer… she loves what she does and works very hard… she is the one I will recommend to every person.”

• Exact problem: Many e-commerce prototypes collapse auth, catalog, and UI into one overloaded stack — making them hard to test, scale, or hand off.
• Business impact: Without clear boundaries, adding checkout, inventory, or new modules becomes slow and risky, delaying any path to store release.
• Technical / operational hurdles: Implement Feature-First Clean Architecture from day one; unify email and Google Sign-In into one session model; map Firestore documents to domain entities with reliable loading/empty states; keep navigation and DI testable.

Architecture & frameworks. Shoply uses Feature-First Clean Architecture in Flutter: each feature (Auth, Products, etc.) owns data, domain, and presentation folders, with a shared core for GetIt DI and go_router. flutter_bloc drives predictable UI state; dartz/equatable support safer domain modeling; Hive supports local caching where useful.

Development process & quality. Built secure email & Google authentication, Firestore-backed product discovery, and retail-focused UI (large imagery, readable product lines). Problem-solving emphasized modularity so presentation widgets never become accidental databases. Quality was reinforced by explicit routing, honest constructors via GetIt, and event-driven BLoC transitions that avoid dead-end auth routes.

APIs, auth & data security. Firebase Auth handles credentials and Google Sign-In; Cloud Firestore serves the catalog. Auth failures communicate clearly; session state is centralized. Firestore reads are shaped for list/detail screens to avoid duplicate requests and flicker. No custom password storage — security relies on Firebase’s managed auth.

• Delivered outcome: Maintainable, test-shaped layers per feature instead of a single overloaded UI stack.
• Engineering signal: Faster path to future collaborators or store-release work thanks to feature folders and shared core utilities.
• Product readiness: Credible storefront prototype organized like a production-bound app (auth + catalog collaborating as services).
• Reception: Open-source showcase on GitHub; public store ratings/download metrics not published yet.