Skip to main content
Ahmed Salama

Consulting

Work with me

I help teams design systems that survive growth, and just as often help them avoid building something they do not need yet. Engagements are remote-first and scoped to the decision in front of you, whether you are a startup, an SME, an enterprise or an agency, in MENA or anywhere else.

Consulting and freelance engagements are not published as case studies. The case studies under Work all come from full-time roles, and only from the ones confidentiality lets me publish.

What I do

Seven engagements. Most work is a combination of two or three of them rather than one in isolation.

Software architecture

Designing systems that stay maintainable as they grow: service boundaries, data flow, and the honest choice between a modular monolith and a distributed system.

Most architecture problems are not technology problems. They are boundary problems: the wrong seam in the wrong place, defended for two years because moving it looks expensive. I work on where the seams go, what each side owns, and what the system does when one side fails.

What you end up with

  • Target architecture with the trade-offs written down
  • Service and data boundaries, and what crosses them
  • A sequenced path from where the system is to where it should be

Evidence: Architecture & System Design

System design & scalability

APIs, data models, caching, queues and infrastructure designed for the load the business actually expects rather than a hypothetical one.

Scaling is mostly a question of finding the real constraint. It is rarely the layer people assume. I profile before prescribing, then design around what the measurement shows: read paths, write paths, what can be asynchronous, what must be consistent, and where the money is best spent.

What you end up with

  • Capacity and load model for the expected growth
  • Caching, queueing and read/write strategy
  • The failure modes, and what happens in each

Evidence: Architecture & System Design

Architecture & code review

A structured read of an existing system: technical debt, performance limits, security exposure, scalability ceilings and the decisions that will cost you later.

A review is only useful if it is specific and ranked. I look at the codebase and the architecture together, then report what will hurt, when it will hurt, and what to do about it, separated into what is urgent, what is important, and what is merely untidy.

What you end up with

  • Ranked findings with severity and likely timeline
  • Concrete remediation for each, sized by effort
  • What is fine as it is (usually the most reassuring part)

Evidence: Engineering Leadership

Technical consulting

A second opinion on a decision that is hard to reverse: a rewrite, a platform migration, a build-versus-buy call, a technology choice with a long tail.

Some decisions deserve an outside reader who has no stake in the answer. I take the context, the constraints and the options already on the table, and give a recommendation with the reasoning exposed so you can disagree with the reasoning rather than the conclusion.

What you end up with

  • A written recommendation with the trade-offs stated
  • What would have to be true for the other option to win
  • The decision recorded so the next team knows why

Evidence: Architecture & System Design

Engineering leadership

Helping teams get predictable: delivery process, architecture standards, review culture and how technical decisions actually get made.

When a team ships unpredictably, the shortage is rarely talent. What is missing is agreement: on what "done" means, on who decides, on what gets reviewed and how. That is fixable, and it is usually faster to fix than the codebase.

What you end up with

  • Delivery and release process that survives a busy month
  • Architecture standards and a review practice people use
  • A decision-making model with clear ownership

Evidence: Engineering Leadership

Technical mentorship

Working with engineers on the step that is hardest to self-teach: moving from writing code well to designing systems and owning decisions.

The move from senior engineer to architect has little to do with syntax. It means learning to hold a whole system in your head, to reason about trade-offs you cannot measure yet, and to defend a decision to people who will live with it. You learn that by doing it with someone who has, and mentorship is a permanent part of how I work.

What you end up with

  • System design and architecture practice on real problems
  • Code review that teaches rather than only corrects
  • Interview and progression preparation where it is wanted

Evidence: Engineering Leadership

AI engineering

Where LLMs and AI agents genuinely improve a product or a workflow, and just as often, where they do not.

AI features fail for ordinary engineering reasons: no evaluation, no guardrails, unbounded cost, and no plan for the cases where the model is confidently wrong. I treat an AI feature the way I treat any other production subsystem, with boundaries, tests, observability and a rollback.

What you end up with

  • An honest read on where AI helps and where it is theatre
  • Integration design: boundaries, fallbacks, cost and latency
  • An evaluation approach, before anything ships

Evidence: AI Systems & Orchestration

How the work runs

The full delivery lifecycle from discovery to monitoring, in order, each stage with the condition that tells you it is finished. Without exit conditions a process is just good intentions.

  1. Discovery

    What problem is worth solving, for whom, and what success would look like, before anyone opens an editor.

    I talk to the people who own the problem and the people who live with it. Most projects that fail were shaped wrong here: the goal was a feature list rather than an outcome.

    Done whenA problem statement the stakeholders recognise as their own.

  2. Business Analysis

    Requirements gathered and the current process mapped, so the ambiguity comes out before it becomes rework.

    Requirements become user stories with acceptance criteria, because no one can deliver a requirement that cannot be tested. The process map is what surfaces the edge cases everyone forgot to mention.

    Done whenUser stories with acceptance criteria, testable before anything is built.

  3. UX & Solution Design

    The user journeys and the system architecture, designed together, because each constrains the other.

    Flows, data models and service boundaries take shape here, with the trade-offs written down rather than implied. If the team cannot ship it on schedule, it is not a good design.

    Done whenThe team can walk a user journey and a data flow end to end without hand-waving.

  4. Backlog & Sprint Planning

    Scope becomes a prioritised backlog; the backlog becomes sprints and a release plan the team believes.

    I would rather scope honestly than optimistically. Risks get named while they are cheap, dependencies get sequenced, and the first release is cut small enough to learn from.

    Done whenA sprint plan the team committed to, with the risks written next to it.

  5. Development

    Building in increments behind review, shared standards and CI, rather than one large merge at the end.

    I stay close to the code: writing the hard parts, reviewing the rest, and adjusting the design when implementation shows it was wrong. I measure progress in working software rather than in tickets moved.

    Done whenIncrements land continuously behind review and CI, releasable at any point.

  6. Quality Assurance

    A test plan weighted by risk: manual, API and regression testing where the damage would be worst.

    Quality gets planned in from the start rather than added at the end. Risk-based test planning puts the effort where failure is expensive, and regression coverage makes sure yesterday's features still work after today's changes.

    Done whenThe test plan finds the defects before users do.

  7. User Acceptance Testing

    The people who asked for the product confirm it does what they asked, against the criteria from stage 02.

    UAT is where business analysis pays for itself: acceptance criteria written up front turn sign-off from an argument into a checklist. Surprises here mean an earlier stage was skipped.

    Done whenStakeholder sign-off against the acceptance criteria rather than a demo.

  8. Release

    Automated, repeatable deployment through CI/CD, so a release is a routine event instead of a ceremony.

    A release should be boring: pipelined, reversible and small. That discipline makes it safe to ship often, and shipping often keeps the feedback loop short.

    Done whenA release is routine: repeatable, reversible and uneventful.

  9. Monitoring

    Production is watched: reliability, performance and usage feed the next round of discovery.

    Delivery does not end at deployment. Monitoring and observability answer whether the system is healthy and whether the product is working, and what they surface becomes the input to the next cycle.

    Done whenThe system reports problems before users do, and what we learn feeds the roadmap.

Starting a conversation

The most useful first message describes the decision you are facing and what makes it hard. If it is not something I can help with, I will say so. That is a faster answer than a proposal.

Open to technical leadership, product delivery and senior engineering roles, and available for architecture consulting, technical reviews and mentorship. Engagements run as project-based work, contracts, consulting, freelance engagements, remote collaboration and long-term partnerships, so the shape of the work follows the problem rather than a fixed retainer.

Based in Cairo, Egypt, working remotely with clients across the MENA region and internationally.

[email protected]How I think about systems