Mohamed BardouniProduct Engineer

Your partner from a complex idea to a product that works and grows.

I'm Mohamed Bardouni. I clarify the goal, uncover weaknesses, then design and build the product — from architecture and backend to interface, AI, and launch.

I do not start with code. I start with the question that prevents the wrong decision.

Product Engineer · Web · Mobile · AIMorocco — working worldwideAvailable for new projects

A builder, not just a coder

I'm a software developer with 8+ years of experience shipping complete solutions for individuals and companies. My journey started with desktop systems (VB.NET, C#) and evolved with every technology wave — today I build modern web platforms, Flutter mobile apps, and AI-powered automation.

What clients value most: I explain technical things in simple language, I deliver on time, and I treat your project like my own product — from idea to launch and beyond.

Arctic Code Vault Contributor — part of my code is archived in GitHub's historical vault.

End-to-End

Backend + Frontend + Mobile + DB + AI + Deployment — one person, full product.

Clear Communication

Technical solutions explained in simple words for non-technical clients.

Disciplined

Public reviews linked to their sources, with written scope and milestones before work starts.

Partnership

I advise, suggest improvements, and support you after delivery.

Read the full CV

Selected case studies

Ten projects. The first three in full — the problem, the weakness I found, the constraints, the architecture, the decisions and their trade-offs. The rest as a card each, with a case study behind it.

Beldify — multi-vendor commerce platform

Problem
A live Moroccan marketplace for kaftans and djellabas from trusted ateliers. Three different roles — buyer, seller, and platform administration — all working on the same products, orders, and accounts.
Weakness found
The initial ask was "a storefront". Built literally, seller operations and admin permissions would have lived in the same code, which makes every change to the buying experience a risk to the admin panel.
Engineering detail
Constraints
A private server with no operations team, a setup that has to be repeatable rather than undocumented manual steps, and full Arabic support with correct RTL direction.
My role
Architecture, the backend and API, the storefront, the separation of seller and admin permissions, and the deployment setup.
Architecture
A Laravel backend owns products, accounts, and order workflows and exposes them over an API. A Next.js storefront handles search, categories, product discovery, cart, and checkout. Seller and administration areas carry separate responsibilities and permissions. Docker containers deploy it on a private server.
Decisions and trade-offs
Separating the storefront from backend logic lets the buyer experience evolve without mixing it into administration concerns. Role separation limits each participant to the data and actions relevant to them. Container deployment makes service setup repeatable. The trade-off: two deployables instead of one — higher deployment cost in exchange for clearer isolation and lower-risk changes.
Stack
Laravel · Next.js · Docker
Supported result
The product is live and publicly inspectable at beldify.com. I publish no sales figures, seller counts, or conversion rates — the available evidence is the product itself.

Uplevel X — AI leadership development

Problem
A platform for managers and executives combining AI conversations, behavioural assessments, practical tools, progress tracking, and payments in a single experience.
Weakness found
The pieces would have read as unrelated features with no clear starting point. Someone opening the app after a difficult meeting is not looking for a tool menu — they are looking for the next step in their situation.
Engineering detail
Constraints
One app in Arabic and English with correct text direction in both, payments through Tap, and subscription logic that has to stay understandable to the user.
My role
The Flutter application, Firebase and Tap Payments integration, and structuring the experience around situations rather than features.
Architecture
A Flutter app for iOS and Android from one codebase, on Firebase, with tools organised around recognizable leadership situations, plus assessments, progress, badges, and a weekly report inside the same experience.
Decisions and trade-offs
Organising tools by leadership situation makes the next action obvious instead of presenting a feature list. RTL support was treated as interface design, not text translation. Progress and badges were tied to useful behaviour rather than abstract points. The trade-off: a slightly deeper navigation structure in exchange for an understandable starting point.
Stack
Flutter · Firebase · Tap Payments
Supported result
The app is published on Google Play, and the public store listing documents the features, Arabic and English support, and publisher details. I publish no coaching impact or active-user counts.

Aqvioo — AI video and image creation

Problem
An app that turns a text prompt or a photo into a promotional video or image, for users with no editing experience.
Weakness found
The ask was "generate", with no review point. AI is part of the product but does not replace an understandable flow: without a preview before saving, the user spends credit on a result they never approved.
Engineering detail
Constraints
Generation is expensive and its consumption has to be visible, users have no editing experience, and Arabic and English both need correct text direction.
My role
The Flutter application, the generation integrations for text and image input, and the credit, subscription, and in-app purchase flows.
Architecture
A Flutter app with a guided path: text or image input, then generation, then a preview before saving or sharing. Generation integrations support both inputs, alongside credit, subscription, and in-app purchases.
Decisions and trade-offs
The guided path reduces choice overload for a user with no editing experience. Preview before saving gives a review point before the result is consumed. Visible credit makes consumption legible inside the product instead of a surprise on the bill. The trade-off: one extra step in the path in exchange for higher confidence and less wasted credit.
Stack
Flutter · AI APIs · In-app purchases
Supported result
The app is published on Google Play, and the public evidence is the store listing with its features, developer details, and privacy disclosures. I do not repeat popularity wording the listing itself does not support.

Other work

Client work, published products, and public repositories. Each has a page describing the architecture and the decisions — and stating plainly what cannot be verified publicly.

Sanad Therapy

A Flutter app published on Google Play for mental health: booking video sessions with therapists, chat, mood tracking, and a private journal.

  • Flutter
  • Riverpod
  • ZegoCloud
  • Firebase

ClinicQu

A clinic appointment platform: a Flutter app where a patient books and follows their position in the queue, and a Laravel backend the clinic runs from a dashboard.

  • No public source

Bastaoui Parfums

A storefront for a Moroccan perfume brand: a catalogue, product pages, and an order flow that ends in a prefilled WhatsApp message instead of a checkout page.

  • Next.js 14
  • Tailwind
  • GSAP
  • i18n

Ubuntu Bags

An e-commerce store for luxury handbags: product catalogue, cart, wishlist, reviews, and editorial content about the artisans, with an admin panel and a separate backend.

  • Next.js 14
  • Laravel 12
  • Filament
  • Stripe
  • No public source

CharityApp

A native Android app written in Java that connects donors with people in need through categories of goods rather than sums of money. The repository is public and the code can be read directly.

    PharmacyInv

    A VB.NET desktop application that manages pharmacy stock and selling at the counter, with reports rendered on the machine itself.

      Credibility and evidence policy

      I do not publish client sales, conversion, or growth figures. Where no public source exists, I show the technical evidence and state the limit plainly.

      Where the engineering depth is

      Four domains. Everything under them is backed by real work, code, or a documented architectural decision — not a tool list and not a percentage bar.

      Product Engineering

      Turning a business goal into written scope, milestones, and decisions you can check. Finding the weakness before the code, and naming what we will not build as clearly as what we will.

      • Problem framing
      • Scope and milestones
      • Written trade-offs
      • Definition of success

      Backend and Systems

      System design and data modeling, queues, retries and idempotent operations, authentication and authorization, API security, and observability that surfaces a fault before your customer reports it.

      • System design
      • Data modeling
      • Queues and retries
      • Idempotency
      • AuthZ and API security
      • Observability

      AI Engineering

      Integrating models inside a real product: evaluating output, routing a request to the right model, managing cost and latency, and drawing explicit limits on what a model is never left to decide.

      • Model integration
      • Output evaluation
      • Model routing
      • Cost and latency
      • Decision boundaries

      Mobile, Cloud and Delivery

      Flutter for two platforms from one codebase and store releases, Docker containers, private-server deployment and CI/CD, and design that assumes failures happen and prepares a recovery path.

      • Flutter, two platforms
      • Docker
      • Deployment and CI/CD
      • Incident-aware design

      The engineering path

      Eight years from desktop to mobile to full-product delivery — each stage built on the one before it.

      1. 2022 — Present

        Senior Flutter & Full-Stack Developer

        Freelance

        Cross-platform Flutter apps with complex state management (BLoC, Riverpod) on clean architecture. Firebase for real-time features, Laravel/Node.js back ends feeding the front ends over REST, CI/CD with GitHub Actions, and 3 apps shipped to Google Play.

      2. 2020 — 2022

        Flutter & Mobile Developer

        Moved from native Android to Flutter. Migrating existing apps cut the codebase by roughly 60% at feature parity, alongside reusable component libraries and custom painters for bespoke UI.

      3. 2018 — 2020

        Android & Web Developer

        Native Android in Java and Kotlin — the platform-internals depth that still pays off whenever Flutter needs platform channels.

      4. 2016 — 2018

        Desktop Systems

        VB.NET · C#

        Inventory systems, POS and administrative tools. Where the software-architecture fundamentals I still rely on came from.

      One architectural decision, in full

      This is the Beldify architecture as it runs in production. The diagram is for the founder; the explanation under it is for the engineer.

      Beldify architectureThe buyer reaches a Next.js storefront; sellers and administrators reach their own panels. Both talk to a Laravel backend over an API, and that backend alone owns the database. Every service runs in Docker containers on a private server.BuyerbrowserSellerdashboardPlatform adminadminDocker · private serverNext.jsstorefrontRole panelsseller · adminLaravel APIproducts, orders, permissionsDatabasesingle owner
      Buyer, seller, and admin all pass through the Laravel API, and it alone touches the database.

      What would have failed if the request had been implemented literally?

      The ask was "a storefront". Built that way, seller operations and admin permissions would have lived in the same code and templates. Every change to a product page then becomes a possible change to the admin panel, and testing a release costs more than building it.

      Which decision changed the outcome?

      Making Laravel the single owner of the data, and making every interface — storefront, seller panel, admin — a client of the same API with different permissions. Authorization is enforced in one place instead of being repeated in each interface.

      Which trade-off did I choose, and why?

      Two deployables instead of one: higher running cost and an extra deployment step. I chose it because the isolation lets the buying experience ship weekly without touching administration, and containers make that cost fixed and repeatable rather than a set of undocumented manual steps.

      The diagram describes a structure that is publicly deployed at beldify.com. It contains no client data and no private metrics.

      Human judgment and AI

      AI is fast. Experience knows which problem is worth solving.

      What AI speeds up for me

      • Exploring a new library or API before committing to it.
      • Generating first drafts of repetitive code, then reviewing them line by line.
      • Reading legacy codebases and summarising what they actually do.
      • Drafting additional test cases after I have written the core one myself.

      What stays my responsibility alone

      • Framing the problem and deciding what should not be built.
      • Architecture, system boundaries, and the data model.
      • Security, permissions, and how user data is handled.
      • Cost, latency, and what actually reaches production.
      • Verification: nothing ships because a model said it was correct.

      I do not hide that I use AI, and I do not sell it as a feature. It is an accelerator; framing, architecture, verification, security, cost, and quality remain my responsibility to you.

      Verified 5.0/5 — in their words

      Read client excerpts here, then inspect my Mostaql profile as the current public source.

      "المهندس محمد من الاشخاص المتميزين الذين تعاملت معهم، فعلاً أنه محترف وبارع ومحترم وخلوق جداً، شخص تشرفت بالعمل معه وسوف أتعامل معه في مشاريعي القادمة. أنصح وبشدة بالتعامل معه."
      Youssef G.AI Mobile App · Mostaql ✓
      "الأستاذ محمد من الأشخاص الطيبين، ويصعب عليّ عدم تكرار التعامل معه، لما يتمتع به من أمانة وتعاون وحرص على خدمة العمل. لم يقصّر معنا إطلاقًا، بل قام بتطوير النظام بشكل كبير."
      حسن ا.CodeIgniter System Upgrades · Mostaql ✓
      "رائع جداً واحترافي وممتاز بالتعامل، متمكن ولديه خبرة وشغف. سأكرر التعامل معه كثيراً جداً، ولديه اهتمام عالي بالمشروع."
      مصطفى م.WordPress + GPT Integration · Mostaql ✓
      "تعامل راقي. أظهر خبرة عالية في البرمجة وفهمًا دقيقًا لمتطلبات المشروع، وقدّم اقتراحات مفيدة. الجودة النهائية ممتازة والكود منظم ونظيف."
      Cherif C.Flutter Debts App + SMS · Mostaql ✓
      "ياجماعة هذا الرجل من أروع المستقلين الذين عرفت — أمانة وصدق وتعاون. باختصار يجعل للمشروع ولاءً عنده، ولن أتردد بالطلب منه مرة أخرى."
      ابوسلطان ا.AI Report Maker · Mostaql ✓
      "أشكر الأستاذ محمد على حسن تعامله وإتقانه البارع في عمله وخبرته في تصميم المواقع. تابع معي كل مراحل التنفيذ خطوة بخطوة حتى ظهر المشروع بشكل مميز."
      محمد ب.Café Website · Mostaql ✓
      "الاستاذ محمد متقن لعمله بإخلاص ومبدع."
      عبدالله م.Telegram Bot + ChatGPT · Mostaql ✓
      "ممتاز ولديه أمانة وثقة كبيرة."
      Mohamed S.AI Video & Image Platform · Mostaql ✓
      "تعامل وعمل ممتاز وواضح."
      Ahmed I.Full-Stack Deploy · Google Cloud · Mostaql ✓

      Join the community

      A group for Moroccan developers: questions, code review, and every live announced before it starts.

      Questions answered

      Ask in the group and get an answer from working developers.

      Code review

      Share your code and get practical feedback.

      Live sessions

      Sessions announced before they start — follow along and join in.

      Read past questions

      From the idea to the next improvement

      01

      Discovery

      20–30 minutes on the problem, who will use it, and what success means to you. I am not selling at this stage — I am understanding. You get a written statement of the problem as I understood it.

      your call: is this the right problem?
      02

      Architecture

      I write the scope in and out, the system structure, and the decisions with their trade-offs in language you can check. You get a scope document, an architecture diagram, and a fixed price.

      your call: approve the structure and the price
      03

      Build

      Every milestone ships something you can open and try, not a status report. Regular updates, and change requests welcome inside the agreed scope.

      your call: accept each milestone
      04

      Validate

      Tests, code review, access and permission checks, and performance on real devices. You get the test results and the list of what was checked.

      your call: is this ready to launch?
      05

      Ship

      Deployment to your server or mine, with the code, the documentation and the deploy process. Full ownership, no lock-in to me.

      your call: when it goes live
      06

      Improve

      I stay reachable for questions and fixes after handover, and I flag improvements I see — with their impact and cost, not as an upsell.

      your call: what earns the next round

      What problem are you trying to solve?

      Tell me three things: what the problem is, where you are stuck now, and what success looks like to you. I reply within hours, and the first call is free.

      I usually reply within hours. First consultation is free.

      [email protected]