What services does Siraj AL Zahran offer?

Siraj AL Zahran offers web development, mobile app development (iOS & Android), AI agents & assistants, AI model training, AI integration, backend engineering, database engineering, software architecture, UI/UX design, cloud solutions, and security & authentication services.

What technologies does Siraj AL Zahran work with?

Siraj works with React, Next.js, TypeScript, React Native, Flutter, Laravel, .NET, Node.js, Express, NestJS, PostgreSQL, MongoDB, MySQL, Firebase, Docker, AWS, GraphQL, Prisma, and many more modern technologies.

How can I hire Siraj AL Zahran for a project?

You can reach out through the contact form on the portfolio website at sirajalzahran.com, or connect via GitHub (github.com/sirajalzahran) or LinkedIn (linkedin.com/in/sirajalzahran). Project inquiries can also be sent via WhatsApp through the contact section.

What is the Tech Shelf on Siraj AL Zahran's portfolio?

The Tech Shelf is a curated developer resource hub within the Lab section, featuring hand-picked tools, packages, roadmaps, and resources for software engineers at all levels.

Thought Process | Lab – Siraj AL Zahran

Welcome to Lab

A space where I share how I think, the decisions behind my architecture, and the tools I trust. Explore deep dives into real-world engineering topics, browse curated resources and roadmaps on the Tech Shelf, or go behind the scenes on API design, auth, testing, and more. Interested in collaborating? The Tech Shelf is community-driven and contributions are welcome.

Thought Process Behind Scenes Deep Dives Tech Shelf

Understand the Real Problem

When something doesn't work, whether it’s a broken UI, a failed fetch, or just odd behavior, I don't jump straight into code. I pause and try to understand the problem deeply . That means reproducing it myself, thinking through what should’ve happened, and narrowing down which layer is actually misbehaving.

Is it visual? A layout glitch, animation hiccup, or UI that doesn’t respond right. I check styles, states, transitions, or component structure.
Is it functional? GET returns 500? POST fails silently? I dig through the network tab, inspect headers, payloads, and backend responses.
Is it logical? Conditions misfiring, state out of sync, a hook triggering twice? I log smartly and walk through the logic like a stack trace in my head.

If I can’t reproduce it reliably, I don’t fix it yet. I keep digging until the failure is predictable. Every issue has a cause. Once I see it, the fix is fast and focused.

Understanding is half the fix.

Map the Flow & Edge Cases

When I get a feature to build, I don’t start coding right away. First, I just sit with it and imagine the whole thing in my head. What the user sees, what should happen, where things could break. That’s how I start.

I mentally walk through it: like I’m the user. From opening the page, to clicking, waiting, errors, confirmations, all of it.
Sometimes I jot things down: in Notion or a notebook, nothing fancy. Just steps, edge cases, missing data, and stuff I know might cause bugs later.
I cover the real stuff: loading skeletons, what if the API is slow or fails, toast messages, retries, empty states, unauthorized access, all the stuff users actually hit.
I think about the backend too: what data do I really need? Should this be paginated? Does this need auth? How should errors look? I try to make the API make sense, not just exist.
And the UI polish: responsiveness, dark mode, translation keys, conditional rendering, that little stuff that makes things feel complete.

Honestly, by the time I start building, I’ve already debugged half the problems in my head. It’s faster, smoother, and just feels better to code when you already know the map.

I don’t just build features; I walk through them before I touch the keyboard.

Break Into Reusable Units

Once I know how the flow works, I start thinking in blocks, small, self-contained units that work on their own, but fit together without friction.

Frontend and backend are separate by design: two folders, two clear roles. They only connect through APIs — simple, scalable, and easy to maintain.
Each block is isolated: a hook, component, or layout should stand alone. If I need to touch five files to fix one thing, something's wrong.
I reuse early: shared buttons, cards, or empty states aren’t afterthoughts; they're part of the plan.
Logic stays portable: I keep fetches, conditions, and side effects separate so the UI stays clean and focused.
Tight coupling is a red flag: if two pieces rely on each other too much, I decouple them with clear boundaries.
I comment to future-me: I leave short, meaningful comments near logic or decisions that might be unclear later. Six months from now, those notes are gold.

I don’t just want code that works; I want code I can trust and grow with.

I don’t build stacked code; I build stable blocks.

Implement & Iterate Fast

I move fast, but every push is thought through. If a feature is scoped, I start building and ship a thin working slice as soon as it runs end-to-end.

Each feature lives on its own branch: no mixed work. Even if features are related, I separate them for clarity and reviewability.
Commits are scoped: backend logic, UI behavior, and styling don’t belong in the same commit. I split by purpose because it's easier to read, test, and roll back.
Clear names matter: feature/user-reset, fix/slow-spinner — clarity before code.
Sync with dev before pushing: I always pull fresh changes before pushing or merging. Conflicts are less stressful when handled early.
I push walking skeletons: if something runs, even without final styling or edge cases, I push. Then I build up.
Time-boxed tasks & progress tracking: I set clear time limits for each feature, from small fixes to larger epics, and track them using tools like Jira or Linear. This helps me stay accountable, measure my real delivery speed, and reflect on what slowed me down or went smoothly. Progress isn’t just about done/not done; I monitor how I improve over time.
Unfinished? I stash or shelve it safely: if priority shifts mid-task, I either stash the work or push it to a branch without opening a merge request. That way, I don’t lose progress, and the main repo stays clean.
I avoid gold-plating: I write code to last, but I don’t over-optimize on the first pass. Clean, not flashy.

Implementation isn’t a straight line, but if each commit tells a clear story, I know I’m moving right.

Speed isn’t chaos. It’s clean steps, small pushes, and focused progress.

Debug, Refactor, and Review

Debugging and refinement are part of the build cycle, not an afterthought. Once something works, I shift focus toward making it solid and safe to ship.

I test where it matters: whether it's development, staging, or local builds, I debug in the right environment. Nothing ships without going through real-world context.
I trace every flow: using logs, browser Network tab, and Postman, I follow the request, check the payloads, and verify backend responses. I debug both the output and the intent.
I test multiple states: not just success. I hit error paths, edge cases, unauthorized access, everything users will actually see.
I refactor post-fix: if a bug taught me something, I go back and polish the code. I remove duplication, clarify conditions, or split logic for readability.
I comment where it helps: especially if a section required deeper thought or workaround, I leave short notes for future context. It’s not for me now, it’s for me six months from now.
I version before merging: I always treat my main branch as production-ready. Development branches are tested, reviewed, and merged only when they’re ready to live in the real world.
I review my own PRs first: if I can’t explain a line, I rewrite it. Clean commits make the team’s job easier.

Testing and debugging aren’t separate phases; they're baked into how I finish a feature. A clean commit history and safe deploy matter as much as working code.

A solid fix is more than a patch; it's a promise the next version will be better.