AyhamAshram

I take an idea and ship it as a complete system: clean, scalable, and used by thousands.

Full-stack engineer with 5+ years in Node.js, PostgreSQL, Next.js and React Native. I build multi-tenant SaaS end to end, from database schema to mobile app.

View work Get in touch

Ayham Ashram in a black suit and oxblood tie, arms crossed, against warm city lights.

// role: Full stack, end to endDatabase, API, dashboard, mobile, deploy
// users: 11,000+students on Markazstatus: live
// tenants: 4 facultiesone tenant each, data isolated

Stack, from database to mobile: postgresqlnode.jsnext.jsreact-native

Scroll

One stack, three kinds of work.

Every product I ship sits on the same four layers. The lines show how far up each kind of work runs, starting from the database.

SaaS platforms

Multi-tenant products on one shared core, where each client keeps its own isolated data, roles and dashboard.

Markaz
SaaS Institute Platform
korrasat.ai

Mobile apps

React Native apps on APIs I design myself, with chat, notifications and releases on Google Play.

Markaz app
AM Arena
Ya Suria

System architecture

Layered codebases, schemas that take new features without touching existing data, and CI/CD that keeps every change safe.

Term-based archiving
Extensible game schema
GitHub to Azure pipeline

SaaS platforms
Multi-tenant products on one shared core, where each client keeps its own isolated data, roles and dashboard.
Runs through: database, api, dashboard.
- Markaz
- SaaS Institute Platform
- korrasat.ai
Mobile apps
React Native apps on APIs I design myself, with chat, notifications and releases on Google Play.
Runs through: database, api, mobile.
- Markaz app
- AM Arena
- Ya Suria
System architecture
Layered codebases, schemas that take new features without touching existing data, and CI/CD that keeps every change safe.
Runs through: database, api, dashboard, mobile.
- Term-based archiving
- Extensible game schema
- GitHub to Azure pipeline

// case 1 of 2

Markaz

A multi-tenant library platform for university faculties. I founded it, designed it and run it, from the database to the mobile app students use every day.

role: Founder and lead engineer: architecture, backend, dashboard, mobile app, deployment
product: Multi-tenant SaaS with a backend, a web dashboard per library and a student mobile app
model: Subscription plus a revenue share for every library that joins
status: live

// problem

Four libraries, no system.

The libraries of the faculties of Education, Pharmacy, Science and Arts handed out lectures and ran student services by hand. Each worked on its own, with nothing shared behind it.

fig. 1 Before: four libraries, each working by hand

// solution

One core, four tenants.

Every library is a tenant with its own isolated data, running on one shared core. Students get lectures and services in a mobile app, and each library runs its side from its own dashboard. Adding a library means adding a tenant, not building a new system.

fig. 2 Each request is routed to its own tenant's data

// challenge

Every term archived, nothing slowed down.

Each period, a term or a year, is moved into its own archive with advanced SQL. Periods never overlap, and old records never weigh on the live database, so the current term stays fast however many years pile up.

fig. 3 Past periods move to the archive; live queries see only the current one

fig. 1 Before: four libraries, each working by hand

11,000+

students using the app

faculty libraries onboarded

Profitable

subscription plus revenue share, not just code

Markaz admin dashboard in Arabic, showing mobile app releases with the active version and its download count. — Platform dashboard

// stack

Node.js
TypeORM
PostgreSQL
React Native
Dashboard framework: to confirm

// links

The backend source is private. Hiring teams can request access.

// case 2 of 2

AM Arena

An esports platform for streamers and tournaments. I built every part of it alone, from the database schema to the mobile app to the pipeline that ships it.

role: Solo: architecture, backend, mobile app, admin dashboard, CI/CD
product: React Native app, Node.js and PostgreSQL backend, and an admin dashboard
delivery: CI/CD from GitHub to an Azure server, on its own domain

// scope

A tournament sets everything in motion.

Creating a tournament opens its own channel automatically, with chat, tournament voting and notifications wired in. Around it sit titles and badges, friends, reels and public votes, all managed from one admin dashboard.

fig. 1 One tournament, and the channel, chat, vote and notifications that follow it

// architecture

New games, no damage to old data.

The schema was designed so a new game can be added without touching anything already stored. The logic is split into layers, so each new feature lands in one place instead of everywhere.

fig. 2 Adding a game leaves every existing table untouched

// delivery

From a branch to production, the same way every time.

Changes move through branches and reviews, then GitHub Actions deploys them to an Azure server behind the platform's own domain. Shipping is a routine, not an event.

fig. 3 Branch, review, build, deploy, live

fig. 1 One tournament, and the channel, chat, vote and notifications that follow it

engineer behind every layer

surfaces: mobile app, backend, admin dashboard

feature systems: titles, notifications, channels, chat, friends, reels, voting

AM Arena home screen with live tournaments, registrations, XP rewards and a hall of fame leaderboard. — Mobile app

Screenshot or clip coming soon

Admin dashboard

// stack

React Native
Expo
Node.js
PostgreSQL
GitHub Actions
Azure

// links

More work.

My own products, client systems and company work. Open a row for the details.

How I think about systems.

Five habits behind every project above. None of them is clever. Together they keep a product easy to change long after launch.

modules/lectures/

1lectures.controller.ts   // http in, http out2lectures.service.ts      // business rules3lectures.repository.ts   // typeorm queries4lectures.entity.ts       // the table56controller -> service -> repository -> postgresql

// sketch of the pattern, not production code

Controllers speak HTTP, services hold the business rules, repositories talk to the database. A change in one layer stays in that layer, so features grow without everything shifting at once.

// seen in: Markaz, AM Arena, SaaS Institute Platform

Layers with one job each
Controllers speak HTTP, services hold the business rules, repositories talk to the database. A change in one layer stays in that layer, so features grow without everything shifting at once.
// seen in: Markaz, AM Arena, SaaS Institute Platform
modules/lectures/
```
1lectures.controller.ts   // http in, http out2lectures.service.ts      // business rules3lectures.repository.ts   // typeorm queries4lectures.entity.ts       // the table56controller -> service -> repository -> postgresql
```
// sketch of the pattern, not production code
Tenancy decided on day one
In a multi-tenant product, every request should know whose data it may touch before it reaches a query. That is far cheaper to design in from the start than to retrofit after the second client signs.
// seen in: Markaz, korrasat.ai, SaaS Institute Platform
request lifecycle
```
1request            // from a library's app or dashboard2  -> resolve tenant  // which library is this?3  -> service         // rules, unaware of other tenants4  -> repository      // reads and writes for that tenant only
```
// sketch of the pattern, not production code
Schemas that expect change
I design tables for the features that will come next, not only the ones on the board today. In AM Arena a new game is added without touching a single stored row.
// seen in: AM Arena
schema
```
1games          // one row per game2  tournaments  // belongs to a game3  titles       // belongs to a game4  votes        // belongs to a tournament56new game -> one new row, existing rows untouched
```
// sketch of the pattern, not production code
Old data out of the hot path
Records that are only read should not slow down the ones being written. Markaz moves each finished term into its own archive, so the live database stays as small as the current term.
// seen in: Markaz
periods
```
1live      current term      -- read and write2archive   term 1            -- read-only3archive   term 2            -- read-only4archive   term 3            -- read-only
```
// sketch of the pattern, not production code
Interfaces built from parts
On the frontend I separate layers too, and build components as small parts that compose, so a screen can change shape without being rewritten. This site is built the same way.
// seen in: korrasat.ai, this portfolio
ProjectRegistry.tsx
```
1<Registry.Root columns={columns}>2  <Registry.Item project={project}>3    <Registry.Trigger />   // the row4    <Registry.Panel />     // the details5  </Registry.Item>6</Registry.Root>
```
// from this site's own source

The goal is a codebase the next engineer can change without fear.

Experience.

My own product, the companies I worked with, and client work.

// 5+ years in the field

Layers: mobile, dashboard, api, database
Markaz
Founder and lead engineer
Built and run a multi-tenant library platform used by 11,000+ students across 4 faculties.
- Own the whole product: architecture, backend, dashboard, mobile app and deployment.
- Run it as a business, on subscriptions plus a revenue share for every library.
- Markaz case study
Layers: mobile, dashboard, api, database
ISS Group
Full-stack developer
Built management and accounting systems for Al-Ulama and Al-Manara institutes in Aleppo.
- Each system shipped with an Android app for parents and students, and one for teachers.
- Institute systems
Layers: dashboard, api, database
ITM
Full-stack developer
Worked on ITM Core, the company's CRM and point-of-sale platform.
- ITM Core
Layers: dashboard, api, database
Micro Beaver
Full-stack developer
Worked on korrasat.ai, an AI platform that generates artistic presentations.
- Built complex multi-tenant services.
- Applied layered architecture and the compound component pattern on the frontend.
- Where I moved from writing code that works to engineering systems that scale.
- korrasat.ai
Layers: api, database
Freelance
Backend developer
Designed and built client backends from scratch with Node.js and TypeORM.
- Ya Suria: a B2B real-estate app, live on Google Play.
- MyCar: a platform for selling and renting cars.
- Ya Suria
- MyCar

Lab.

Small studies in interface and 3D, made to learn.

These are personal design exercises. Damac and Apple are unofficial studies, not client work, and not affiliated with either brand.

Stack.

The tools I reach for, grouped by where they sit in a system.

// backend: Node.js
TypeORM
PostgreSQL
MySQL
REST APIs
Auth, roles and permissions
Real-time chat and notifications
// frontend: React
Next.js
Framer Motion
Three.js
Compound components
Layered architecture
// mobile: React Native
Expo
Google Play releases
// devops: CI/CD with GitHub Actions
Azure
Vercel
Domains and deployment
// architecture: Multi-tenant SaaS
Extensible schema design
Period-based archiving
Clean layering

Certifications

IBM
Back-End DevelopmentProfessional certificate, CourseraCredential link to confirm
Meta
Front-End Developer (React)Professional certificate, CourseraCredential link to confirm

Bring the idea. I'll ship the system.

Hiring an engineer, or building a product that needs one? Write to me and I'll reply.

Email meayhamam10ashram@gmail.com

// case 2 of 2

AM Arena

An esports platform for streamers and tournaments. I built every part of it alone, from the database schema to the mobile app to the pipeline that ships it.

role: Solo: architecture, backend, mobile app, admin dashboard, CI/CD
product: React Native app, Node.js and PostgreSQL backend, and an admin dashboard
delivery: CI/CD from GitHub to an Azure server, on its own domain

// scope

A tournament sets everything in motion.

fig. 1 One tournament, and the channel, chat, vote and notifications that follow it

// architecture

New games, no damage to old data.

The schema was designed so a new game can be added without touching anything already stored. The logic is split into layers, so each new feature lands in one place instead of everywhere.

fig. 2 Adding a game leaves every existing table untouched

// delivery

From a branch to production, the same way every time.

Changes move through branches and reviews, then GitHub Actions deploys them to an Azure server behind the platform's own domain. Shipping is a routine, not an event.

fig. 3 Branch, review, build, deploy, live

fig. 1 One tournament, and the channel, chat, vote and notifications that follow it

engineer behind every layer

surfaces: mobile app, backend, admin dashboard

feature systems: titles, notifications, channels, chat, friends, reels, voting

Screenshot or clip coming soon

Admin dashboard

// stack

React Native
Expo
Node.js
PostgreSQL
GitHub Actions
Azure

AyhamAshram