Home

Résumé

Contact Me

Staff-level help for difficult backend and cloud systems.

I help engineering teams untangle systems that have become slow, fragile, expensive, risky, or difficult to evolve safely.

Production APIs • Platform engineering • Data systems • Cloud architecture • Reliability • Performance

See ways to work together

You do not need to know which engagement model you need before the call. Start by telling me what is happening.

Typical reasons companies bring me in

Most backend and platform problems do not begin as neatly scoped architecture projects. They show up as delivery drag, operational risk, unpredictable performance, unclear ownership, or teams avoiding changes because the blast radius is difficult to reason about.

  • Slow or unreliable production systems

    Critical APIs, queries, or workflows have become slow, unpredictable, or difficult to diagnose under real usage.

  • Fragile data and integration flows

    Data movement works, but it is difficult to observe, extend, replay, or change without creating downstream risk.

  • Cloud and operational friction

    Deployments, environments, infrastructure cost, observability, or operational ownership are slowing the engineering team down.

  • Architecture and ownership that slow delivery

    Responsibilities have blurred across services, packages, APIs, and teams, making ordinary changes larger and riskier than they should be.

  • Not enough senior technical bandwidth

    The team needs Staff-level judgment for architecture, sequencing, trade-offs, and critical execution without adding another full-time senior hire.

Engagements start with the problem, not the service label.

Every engagement begins with a free introductory call about what is currently blocking the team: performance, reliability, architecture, delivery speed, infrastructure, data flow, or technical decision-making. You do not need to select an engagement model beforehand. If there is a useful fit, we decide whether the next step is a proposal, a deeper scoping conversation, or one of the three engagement paths below.

Ways to work together

01 · Audit

Architecture Audit

Best for teams that need clarity before committing to a major technical decision or engineering investment.

A focused, fixed-scope review of one important backend, platform, data, or cloud problem. The goal is to identify the highest-risk bottlenecks, clarify the relevant trade-offs, and give the team a prioritized path forward.

Possible use cases
  • A backend or data workflow is slow but the bottleneck is unclear
  • Planning a migration, service split, or architectural change
  • Cloud or platform works but feels fragile, costly, or operationally difficult
  • Leadership needs an external senior review before committing capacity
Possible review areas
  • Architecture, boundaries, and dependency structure
  • Data paths, database behavior, and performance
  • Cloud infrastructure, deployment, and operational reliability
  • Observability and incident readiness
  • Security, access control, and compliance considerations where relevant
Typical outputs
  • Architecture and dependency map
  • Risk and bottleneck analysis
  • Prioritized findings
  • Recommended target state
  • Remediation and sequencing roadmap
  • Technical readout and optional implementation plan

Investment

$6,000

Fixed scope · usually two weeks

Exact review areas depend on agreed scope. A two-week audit does not assess an entire organization or platform in full, and may require repository review, stakeholder interviews, logs, schemas, or infrastructure access. It is a paid diagnosis and decision-making engagement, not just a written checklist.

Discuss an architecture audit

02 · Fractional

Fractional Staff Engineer

Best for teams that need recurring senior technical direction without adding a full-time Staff Engineer.

Ongoing, hands-on Staff-level support for teams navigating backend, platform, cloud, or data-system complexity. I work with technical leadership and engineering teams to clarify architecture, review important decisions, sequence work, reduce ambiguity, and unblock execution.

Typical involvement
  • Architecture reviews and RFC feedback
  • Technical planning and sequencing
  • Backend and platform design
  • Service boundary and API design
  • Critical-path code review
  • Hands-on implementation where useful
  • Mentoring and technical alignment
  • Reliability, observability, and deployment strategy
  • Cross-team technical coordination
  • Technical investigation of ambiguous production problems
  • Helping leadership distinguish urgent symptoms from structural issues

Recurring part-time support, usually structured as a monthly engagement with defined weekly capacity.

This is hands-on, senior-level technical involvement for an existing team — not generic advisory consulting, executive coaching, passive availability, ordinary staff augmentation, or an outsourced CTO role.

Discuss fractional support

03 · Execution

Milestone Execution

Best for teams that need a senior engineer to design and deliver a specific backend, platform, cloud, or data-system outcome.

Hands-on delivery for scoped work where architecture and implementation cannot be cleanly separated. I take ownership of a defined technical milestone and work with the existing team to establish the design, constraints, delivery path, and production-ready implementation.

Typical work
  • Performance optimization
  • Backend redesign or refactoring
  • Service extraction
  • API and data-model changes
  • Data pipeline or ingestion redesign
  • Platform migrations
  • Infrastructure modernization
  • Caching and query strategy
  • Production hardening
  • Reliability and observability improvements
  • Delivery of a defined backend or platform capability

Scoped around an agreed outcome, constraints, and delivery path rather than generic hourly freelancing.

Work may include design, RFCs or architecture notes, implementation, tests, infrastructure changes, rollout planning, documentation, and handoff. Not every engagement includes every deliverable.

Discuss a delivery engagement

Experience where correctness and traceability matter

A significant part of my recent work has involved healthcare, biotech, and data-heavy platforms where backend decisions need to account for auditability, security, data provenance, access control, tenant isolation, and operational reliability.

  • Healthcare and biotech backend systems
  • EHR and clinical-workflow architecture
  • Data-heavy APIs and internal platforms
  • ETL, ingestion, and orchestration systems
  • Auditability and data provenance
  • Access control and tenant isolation
  • Encryption and secure service boundaries
  • Compliance-aware architecture
  • Data residency considerations
  • Systems where correctness and traceability are part of the trust boundary

This experience informs how I approach architecture, implementation, and risk in systems where backend behavior affects more than product convenience.

Selected systems impact

I am most useful where backend, cloud, data, and product constraints overlap. The work often involves turning an ambiguous production problem into clearer architecture, a safer implementation path, and a measurable result.

  • ~70% faster end to end

    Re-architected a biotech platform's core data path

    Redesigned ingestion and retrieval across the platform's core data pipeline, cutting end-to-end processing time by roughly 70%.

    See related experience

  • Billions of production events

    Defined the primitives and contracts behind an integrations platform

    Designed the shared stream, queue, and workflow primitives—and the source and target contract conventions—underpinning a platform handling billions of production events.

    Validated across 16+ source and target integrations, including GitHub and Shopify.

    See related experience

  • Cross-service platform conventions

    Established service boundaries across a multi-service Python platform

    Defined service ownership and API contract conventions across backend APIs, ETL and ML pipelines, monitoring, and CLI surfaces, reducing integration friction and making cross-team changes safer to coordinate.

    See related experience

  • Beyond previous load ceilings

    Led a backend beyond its previous architectural ceiling

    Architected the migration from a monolithic Elixir backend to service-oriented components and replaced a synchronous request path with distributed processing, allowing the platform to move beyond its previous load ceilings.

    See related experience

What people say about working with me

“ A fantastic job done by Houssem, as always! ”

Daniel Spataro

Daniel Spataro

CEO at IntegrationOS

“ Houssem is a great developer and a great person to work with. He showed himself like a real professional. He helped us to understand those nuances [in our system] and find a way to handle them. ”

Tom Goedhart

Tom Goedhart

Co-Founder at Barbaard Management

“ He is a professional engineer with a great deal of experience and a will to jump into fixing any problem. ”

Lucas Gozalvez

Lucas Gozalvez

CTO at FelixSmart Inc.

“ His technical skills and attention to detail were impressive. What stood out even more was his exceptional communication throughout the project. ”

Nina Rezec

Nina Rezec

Founder at Global Consultancy UAE

How the process works

  1. 01 Free intro call We spend up to 30 minutes discussing the company, the system, what is currently happening, why it matters, and what the team has already tried.
  2. 02 Fit and next step We decide whether I am the right person to help and whether the situation is clear enough for a proposal or needs deeper scoping.
  3. 03 Recommended path If there is a useful fit, I recommend the appropriate next step: an architecture audit, fractional support, milestone execution, a follow-up scoping conversation, or a full-time hiring discussion.
  4. 04 Proposal and work Once the scope, commercial model, and expected outcomes are clear, I provide the relevant proposal or continue through the company's hiring process. Paid work begins only after both sides agree on the path.

Some straightforward engagements can be agreed after the first call. More complex work may require a follow-up discussion or a paid audit before implementation is scoped.

Frequently asked questions

Do I need to choose an engagement model before booking?

No. Start by describing what is happening. The introductory call is used to determine whether there is a useful fit and whether an audit, fractional support, milestone execution, deeper scoping, or another path makes sense.

What happens during the introductory call?

We discuss the company, the system, the problem, its impact, what the team has already tried, and the constraints around solving it. The call is for mutual fit and next-step selection; it is not a free architecture review.

When should I choose an Architecture Audit?

An audit is appropriate when the problem is important but the correct technical path is still unclear. This commonly applies before a migration, architectural change, optimization effort, infrastructure investment, or significant engineering commitment.

When does Fractional Staff Engineer support make sense?

Fractional support is useful when the team needs recurring senior technical judgment, architecture review, sequencing, mentoring, critical code review, or hands-on support but does not need another full-time Staff Engineer.

When is Milestone Execution the right model?

Milestone execution fits when the desired technical outcome is reasonably clear and the team needs senior hands-on ownership to design, implement, harden, and deliver it safely.

Can you work with our existing engineering team?

Yes. These engagements are designed to strengthen existing teams, not replace them. I can work with founders, CTOs, engineering managers, technical leads, and individual contributors depending on the situation.

Do you only work with healthcare or biotech companies?

No. Healthcare and biotech are areas of specialized experience, but the core work also applies to SaaS products, data-heavy platforms, infrastructure-heavy systems, and teams with difficult backend or operational constraints.

Can the engagement be fully remote?

Yes. The work is designed for remote collaboration using focused calls, clear written communication, code and architecture review, and asynchronous technical artifacts where useful.

What should I provide before the call?

A short description is enough: what the company or product does, what is not working, why it matters now, and whether there is a specific deadline or milestone. Do not send confidential source code, credentials, customer data, or sensitive production information through the initial form.

Can we discuss a full-time role?

Yes. I am open to relevant Staff-level backend and platform opportunities. Use the same introductory call or contact route and indicate that the conversation concerns a full-time role.

Tell me what is blocking your engineering team.

You do not need to arrive with a solution or choose an engagement model. Describe what is slow, fragile, risky, expensive, or difficult to change, and we will determine whether there is a useful path forward.

Send a message

The first call is free and focused on understanding the situation, mutual fit, and the right next step.

Houssem Eddine Zerrad

Staff Software Engineer & Cloud Architect · © 2026