Mohammed Alaa Mohsen

Python Backend Developer — Django & DRF· AI-augmented Full-Stack delivery

I build the whole product: a Django REST Framework API, a React/TypeScript interface built with AI tools and integrated by me, and the Linux server it all runs on. Three-plus years of Python; one product in production.

StoryHub — the landing page
Live in production

StoryHub

A quiet place to write stories and read them.

A bilingual writing platform with a social layer — a DRF API and a React app on a VPS I set up and operate.

storyhubapp.comchecking Open StoryHub ↗
7backend apps
41API endpoints
85automated tests
24interface pages
Sep 2026live since
How the product is put together
APIDjango REST Frameworkbuilt by me
InterfaceReact 19 · TypeScriptbuilt with AI tools · integrated by me
ServerNginx · systemd · PostgreSQLset up and run by me
Working stack
PythonDjangoDjango REST FrameworkRESTful API DesignPostgreSQLRedisCeleryJWT / OAuth 2.0React 19PythonDjangoDjango REST FrameworkRESTful API DesignPostgreSQLRedisCeleryJWT / OAuth 2.0React 19
TypeScriptViteTailwind CSSNginxsystemdLinuxGitHub ActionsOpenAPIPWATypeScriptViteTailwind CSSNginxsystemdLinuxGitHub ActionsOpenAPIPWA
Availability
Based inGaza, Palestine
LanguagesArabic · English
Open toRemote backend & full-stack work
Hire me onBrightGaza ↗
GitHubCI passing

7 self-built projects

Django applications, a DRF reference lab, and a flagship with tests running on every push.

github.com/MohammedAMohsen
About

Computer Science graduate based in Gaza. I build backend systems that reach production — and the interfaces around them.

I graduated from the Islamic University of Gaza in 2025 and have worked with Python for more than three years. I started with the language itself and Google’s IT Automation with Python certificate, then relational databases, then a first backend in Flask before settling on Django. Today I ship complete products: a Django REST Framework API, a React interface built with AI tools, and a Linux server I set up and operate myself.

The part of a system I care most about is the part that has to be right: the data model, who is allowed to see what, and the queries that decide whether a page is fast. I write the reasoning behind every decision into docstrings, READMEs and runbooks, so whoever picks the project up next can understand it without asking.

The path so far
  1. Python
  2. Advanced Python
  3. Google certificate
  4. Databases
  5. First backend — Flask
  6. Django & DRF
  7. Complete products
  8. Live on a VPS
Work

A live product, a complete store, and five more.

Every project is self-built and open on GitHub. StoryHub is in production, with real writers publishing on it.

Case study 01 · Flagship

StoryHub

A quiet place to write stories and read them.

A long-form writing platform with a social layer — following, likes, threaded comments, bookmarks and notifications — fully bilingual in Arabic and English with right-to-left layout, installable as a PWA. A Django REST Framework API and a React + TypeScript app, running on a Linux VPS I set up and operate.

Live since 14 Sep 2026 7 apps 41 endpoints 85 tests 24 pages EN / AR · RTL PWA
BackendDesigned and built by me

The data model, all seven apps, every endpoint, authentication, Celery, caching — and the 85 tests.

InterfaceBuilt with AI tools, integrated by me

Designed with an AI design tool and coded with AI coding tools — no other developers involved. The integration with the API — contract, auth flow, data shapes — is my work.

ProductionSet up and operated by me

Server, Nginx, systemd, PostgreSQL, backups with a rehearsed restore, and the SEO layer.

Engineering highlights

Six things in StoryHub that show how I work — open any of them; where there is code, it is right there.

01 Authorization One rule decides who can read a story

Feeds, writer pages, direct links, likes, comments, bookmarks and the sitemap all ask the same queryset method, visible_to(). Adding followers-only stories meant changing one place, not seven.

backend/apps/stories/models.py
class StoryQuerySet(models.QuerySet):
    """The one place that knows who may read a story."""

    def visible_to(self, user, *, with_own_unpublished=False):
        published = Q(status=Story.StatusChoices.PUBLISHED)
        public = Q(visibility=Story.VisibilityChoices.PUBLIC)
        if user is None or not user.is_authenticated:
            return self.filter(published & public)
        follows_author = Exists(
            Follow.objects.filter(follower=user, following=OuterRef("author_id"))
        )
        allowed = published & (public | Q(author=user) | Q(follows_author))
        if with_own_unpublished:
            allowed |= Q(author=user)
        return self.filter(allowed)
02 ORM & performance Interaction state computed by the database

Liked, saved and following are Exists/OuterRef annotations — one query per page instead of one per item. Follower counts use a Subquery after a joined Count inflated the numbers.

3 checks × every story → 1 query per page
03 Search & sharing A single-page app that Google and WhatsApp can read

Django serves the built shell with its <head> rewritten per route — title, Open Graph, canonical URL, JSON-LD — plus a sitemap that reuses the visibility rule, and an X-Robots-Tag middleware instead of blocking the API in robots.txt.

backend/config/robots.py
# Crawlers must be allowed to *fetch* the API; what they
# must not do is list its JSON as pages.
NOINDEX_PREFIXES = ("/api/", "/auth/", "/admin/")

class NoIndexApiMiddleware:
    def __call__(self, request):
        response = self.get_response(request)
        if request.path.startswith(NOINDEX_PREFIXES):
            response["X-Robots-Tag"] = "noindex, nofollow"
        return response
04 Security HTML sanitised once, on write

Story bodies are cleaned against an allow-list (nh3) before they are stored, so no read path — API, admin, a future export — has to remember to escape anything.

16 tags allowed · script, style, iframe dropped with their content
05 Authentication Google sign-in verified on the server

ID tokens are checked with google-auth, a verified email is required, usernames are generated on collision, and Google-only accounts get a set password flow instead of change password.

has_usable_password → “Set password” vs “Change password”
06 Operations A deploy script that can’t break itself

deploy.sh runs as one bash function called on its last line — because git pull once replaced the running script midway and a step was silently skipped.

deploy/deploy.sh
# A function is parsed whole before it runs, so the copy
# in memory is the one that finishes — even if `git pull`
# replaces this file midway.
set -euo pipefail

deploy() {
    $RUN_AS git -C "$APP" pull --ff-only
    $RUN_AS bash -c "cd '$APP/backend' && .venv/bin/python manage.py migrate"
    $RUN_AS bash -c "cd '$APP/frontend' && npm ci && npm run build"
    systemctl restart storyhub-web storyhub-worker
}

deploy "$@"
In production

One server, one domain, every service accounted for.

Nginx serves the built frontend and static files and proxies the API to Gunicorn; PostgreSQL, Redis and a Celery worker run beside it as sandboxed systemd units. A nightly backup is mirrored off-site, and the restore was rehearsed before launch. CI runs the tests and the build on every push; the deploy itself is a one-command script over SSH — deliberately manual at this scale.

  • Nginxserves the app, proxies the API
  • Gunicornruns Django
  • PostgreSQLthe database
  • Rediscache and Celery broker
  • Celeryemail off the request path
  • systemdsandboxed units, dependency order
  • Let’s EncryptTLS, HSTS, security headers
  • Backblaze B2nightly off-site backups
  • Resendemail with SPF, DKIM, DMARC
  • UptimeRobotpolled every five minutes
  • GitHub Actions85 tests + frontend build, every push
The interface

Designed with Google Stitch and rebuilt with Claude, then integrated with the API by me: a token-based light and dark theme, right-to-left layout handled as data, optimistic updates kept in sync across every list, a Tiptap editor with inline image upload, Arabic and English via i18next, and a service worker for installability.

Stack
Django 6DRF 3.17DjoserSimpleJWTCeleryRedisPostgreSQLnh3drf-spectacularReact 19TypeScriptViteTailwind v4TanStack QueryZustandRadix UITiptapi18next
Case study 02 · E-commerce

GreatCart

A complete online store, server-rendered.

A catalogue with colour and size variations, a cart that works before and after sign-in, checkout with tax, a simulated wallet payment, orders and inventory, verified-purchase reviews, an emailed invoice and a customer dashboard — classical Django: templates, forms, sessions.

5 apps12 modelsDjango templates + BootstrapSQLiteSMTP invoices

The guest cart survives sign-in

Visitors get a session-keyed cart; signing in merges it into the user’s cart. Items are matched by their exact set of variations, so a blue shirt in Large and the same shirt in Medium stay separate lines — no collapsing, no duplicates.

Guest cart · sessionShirt · Blue · LShirt · Blue · M
+
User cartShirt · Blue · L
merged by variation setShirt · Blue · L ×2Shirt · Blue · M ×1two lines, no duplicates

An order lifecycle that can’t double-charge or oversell

Stock is validated before payment and decremented after; a paid order can’t be paid twice; a pending order can be resumed; variations are frozen into the order as a JSON snapshot so later catalogue edits don’t rewrite history; an HTML invoice goes out by email.

  1. 1Cart
  2. 2Checkout + tax
  3. 3Stock check
  4. 4Payment (simulated)
  5. 5Stock decrement
  6. 6Invoice by email

Reviews only from people who bought

A customer can review a product only after an order containing it; one review each, editable; the average rating is an aggregate, not a stored counter.

Ordered this product?
✓one review, editable
✕read only
rating = ReviewRating.objects.filter(product=p).aggregate(Avg("rating"))

Also in the project: a custom user model written from scratch — AbstractBaseUser and a manager with create_user/create_superuser — and hand-built email activation with urlsafe_base64_encode and Django’s token generator.

!The payment gateway is simulated — a demo wallet driven by a JSON request. The flow is real; the money isn’t.

More work

Three applications and two learning labs.

The labs are studies of a framework rather than products, and are labelled as such. StoryHub’s authentication layer grew out of them.

Applications Learning labs
Skills

Deep on the backend, capable across the stack.

Django and Django REST Framework are where I go deepest. The rest is what lets me deliver a complete product rather than an API alone.

Backend & APIs
DjangoDjango REST FrameworkRESTful API DesignOpenAPI / SwaggerCeleryRedisTransactional EmailQuery Optimization
Auth & Data
JWT / OAuth 2.0DjoserPostgreSQLMySQLSQLiteCustom Permissions
API Craft
Filtering & SearchPaginationCaching StrategiesThrottlingQuery Profiling (Silk)Testing · pytest
Full-Stack Deliverywith AI tools
React 19TypeScriptViteTailwind CSSTanStack QueryZustandi18n & RTLPWA
Production & Tooling
GitGitHub Actions (CI)LinuxNginxsystemdTLSBackups & RestoreTechnical SEODocker — in training
Education & certificates

A degree and certificates — every one verifiable.

AI tools are part of my working day; the certificate below comes from the company that builds Claude.

How I work

Data model first, contracts second, checks before every release.

01

I start from the data model

Before any endpoint exists, the schema and the access rules are decided: relations, constraints enforced in the database, and one place that answers who is allowed to see what. Everything else is built on top of that.

02

APIs are designed as contracts

Resources, status codes, pagination, filtering and rate limits are decided up front, and the OpenAPI schema is generated from the code — so the frontend, and any other client, builds against a real document rather than guesswork.

03

Nothing ships without tests and checks

A test suite focused on authentication, permissions and visibility; manage.py check --deploy with zero warnings; CI running the tests and the frontend build on every push; deployment from a documented script; backups with a restore that has actually been rehearsed.

04

The interface is built with AI tools — the integration by hand

I design screens with an AI design tool and build the frontend with AI coding tools; no other developers are involved. What can’t be delegated is mine: the API contract, the authentication flow and the data shapes. The AI help is stated openly in every README.

05

Everything important is written down

Decisions, trade-offs and runbooks are documented in Arabic or English, clearly enough that a teammate can pick the project up without a call. I work best asynchronously and in writing. Currently adding Docker to the toolbox.

Contact

Let’s build the whole product.

Available for remote backend and full-stack work. Reach out without hesitation — language won’t be a barrier between us.

dev.albasha@gmail.com ↗