Ahmad Kouider — Full-Stack Developer & IT Consultant in Dortmund

// in plain terms

What Full-Stack Development Means Here

One person, every layer — from the interface you click to the server that keeps it running.

Full-stack development is the practice of building a web product end to end: the interface people use, the application logic behind it, the database that stores the data, and the server that serves it all. On this site that means a single person is responsible for every layer, so nothing gets lost between separate teams, and fixes happen in one place instead of three.

Concretely, that covers:

• Front end — responsive interfaces in JavaScript, TypeScript, Angular, React and VueJS that stay usable on a phone.
• Back end — PHP and Laravel services, REST APIs and the business logic that connects everything.
• Data — schema design, migrations and tuning in MySQL, PostgreSQL and MongoDB.
• Infrastructure — Linux servers, Docker, Nginx, SSL and CI/CD pipelines that deploy without surprises.
• Automation — Raspberry Pi and ESP8266 devices, C++ firmware and browser automation for repetitive work.

Who is this work for?

It fits teams and founders who need a working product rather than a slide deck: a company site that finally loads fast, an internal tool that replaces a spreadsheet, a shop that takes payments, or infrastructure that someone actually maintains. If you already have an in-house team, I work alongside them on the parts nobody has time for.

What does a typical engagement look like?

Most projects start with a short written brief and a call, then a fixed scope with milestones. You get reviewable increments rather than one big reveal, and you own the code and the servers at the end. Small changes are usually delivered within days; a full site build runs for a few weeks.

// process

How a Project Runs, Step by Step

// case studies

Selected Client Work

Real projects, delivered on GNU/Linux with Nginx, SSL and WordPress or Laravel underneath.

// comparison

Self-Hosted vs Managed

One decision comes up in almost every conversation: should the site run on a managed platform or on a root server you control? Compared to a managed plan, self-hosting on a German root server costs less per month, removes plugin limits and keeps every byte of data in one jurisdiction — and that is the setup I use for my own projects.

• Self-hosted — full control over Nginx, PHP versions, caching and backups; no per-seat or per-plugin pricing; you need someone who maintains the machine (I do, including monitoring and updates).
• Managed — the provider handles infrastructure and updates; you trade flexibility and data location for convenience, and heavy plugins are often restricted.

On the other hand, managed hosting is the better answer when nobody wants to own a server: if you have no technical contact person and your site is a brochure that rarely changes, paying a monthly fee for someone else’s uptime beats maintaining a machine you never log into. The right choice depends on who answers the phone when something breaks — and that, not the price tag, is the deciding factor.

// numbers

Numbers I Can Stand Behind

Everything below comes from systems I run myself, which is the only kind of data I am willing to quote:

• 3,000+ mailboxes — a MailCow mail platform I operate, with a custom Laravel and Angular control plane managing users through the MailCow API.
• 15+ containers — an LXC/LXD homelab running on a private Tailscale network, including self-hosted GitLab, private NPM and Docker registries.
• 2 CI runners — a self-hosted GitLab instance with two runners using different build strategies for Linux and container builds.
• Since 2017 — building and running production systems from Dortmund, Germany, for clients in Germany and abroad.

Public benchmarks are useful for context, with the sources linked so you can check them: WordPress is used by 40.3% of all websites, a content management system market share of 58.8%, according to W3Techs. Google defines “good” Core Web Vitals as Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1, measured at the 75th percentile of real visits (web.dev) — the budgets I use when optimising a build.

“WordPress is used by 40.3% of all the websites, that is a content management system market share of 58.8%.”

— W3Techs, usage statistics and market share of WordPress, September 2026

// faq

Frequently Asked Questions

// verdict

The Honest Verdict

If you want one accountable person for a build that has to work in production — a corporate site, a shop, an internal tool, or the Linux machinery underneath it — that is exactly what this site exists to show, and the case studies above are the evidence. If you need a large team working in parallel, a purely design-led brand exercise, or the cheapest possible template, an agency or a marketplace will serve you better, and I will say so rather than take the project.

Three things you should do before hiring anyone, including me:

• Ask who maintains the server after launch. A site that nobody patches becomes a liability within a year.
• Request the performance numbers, not the design mockup. Treat the Core Web Vitals thresholds above as the minimum bar.
• Insist on owning the code and the credentials. Repositories and access belong to you, in your accounts, from day one.

If that matches how you want to work, the fastest next step is a short message: describe the goal in a few sentences and you will get an answer with a realistic scope and timeline.

// about

Who Writes This Site

Ahmad Kouider is a full-stack developer and IT consultant based in Dortmund, Germany, working in IT professionally since 2017. The claims on this page are backed by infrastructure you can inspect: a self-hosted GitLab with two CI runners, a MailCow platform carrying 3,000+ mailboxes managed by a custom Laravel and Angular application, the offline-first HabitOrbit habit tracker, and an LXC/LXD homelab with 15+ containers on a private Tailscale network. Client work, technical write-ups and open-source experiments are published on this site rather than described in marketing language.

Client work has been delivered for businesses in Germany and abroad — trusted by agency partners, trades businesses and corporate teams that needed one accountable developer instead of a hand-off chain. References from the projects above are available on request, and every figure quoted on this page can be traced back to a public link or a running system.

Profiles and code: GitHub, GitLab and LinkedIn. The resume lists the full history, and the portfolio holds the projects behind each claim.