Adis Fetibegović,
.NET backend engineer.

Six years on production .NET systems, continuously since 2020. I build ASP.NET Core services, author the shared .NET platform a set of services sits on, and move old systems to modern .NET without a rewrite. This page is my CV, written as the thing I spend my days on: an API reference.

Executed, not proposed

• mediator library -> in-house CQRS abstraction
• one message bus -> another, live
• SQL Server -> PostgreSQL

All three on systems that stayed in service the whole time. No maintenance weekend, no big-bang cutover.

Engineer

AF

Adis Fetibegović

.NET backend engineer. Enschede, Netherlands.

adis_0411@hotmail.com

Track record

Six years on production .NET systems, continuously since 2020, at four Dutch engineering and software firms: MyPoi World, Sigmax, Tauw and Strukton Systems.

BSc Computer Science, Saxion. PSM I (Scrum.org, 2023).

How to read this

Every section is an endpoint. The profile and the employment history come first, then the three kinds of work I do, then the stack, the integrations and the conventions, all of it taken from what I have actually shipped.

$ curl \
    https://sanaengineering.net/v1/engineer \
    -H "Accept: application/json"

{
  "engineer": "Adis Fetibegović",
  "title": "Senior .NET Backend Developer",
  "experience_years": 6,
  "based_in": "Enschede, Netherlands",
  "specialisations": [
    "ASP.NET Core services & API contracts",
    "Reusable .NET platform & libraries",
    "Legacy modernisation & platform migrations"
  ],
  "certifications": [
        "PSM I, Scrum.org, 2023"
  ],
  "languages": ["nl", "bs", "en", "de"],
  "contact": "adis_0411@hotmail.com"
}

POST /v1/apis

Design and build ASP.NET Core services, and own the contract everyone else generates against.

Vertical-slice feature modules on a clean four-layer boundary: API to Application to Domain, with persistence implementing the application's contracts and nothing leaking back the other way. CQRS with validation pipelines and typed results, rather than exceptions used as control flow. Thin controllers, sealed handlers, records for every DTO. And a rich domain layer, so entities, value objects, domain events and business invariants stay out of the transport and persistence code.

The boundary is held by the build, not by a code review. Architecture test suites fail CI on layer, naming or visibility violations, so the design is still the design a year later, whoever happens to be working on it by then. Decisions get recorded as ADRs, with diagrams generated from the codebase instead of drawn once and left to rot.

The OpenAPI specification is generated from the service, linted in CI, and published as the single source of truth for whichever teams generate clients against it. That includes versioning and breaking-change discipline, plus separate specs per consumer surface when one API serves more than one kind of client.

{
  "api": "ASP.NET Core",
  "delivers": [
    "Vertical-slice modules, four-layer boundary",
    "CQRS, validation pipeline, typed results",
    "Rich domain: entities, value objects, events",
    "EF Core on PostgreSQL or SQL Server",
    "OpenAPI spec, linted and versioned in CI",
    "Architecture tests that fail the build",
    "Integration tests on real DB and broker",
    "ADRs with generated diagrams"
  ],
  "boundary_enforced_by": "the build",
  "runs_in": "the team's repository and pipeline"
}

POST /v1/platform

Authoring the shared .NET platform a set of services stands on, so each one stops reinventing it.

Any organisation past its second service has the same quiet problem. Each one solved validation, caching, auth, audit and persistence a little differently, and now none of it can be changed. The answer is an internal platform rather than a wiki page: a CQRS abstraction, a validation pipeline, EF Core and spatial persistence integration, identity-provider integration, mail, storage, localisation. Published as versioned packages with changelogs on the organisation's own registry, so a project mounts a capability instead of copying it.

It ships with an architecture-test kit, so a service that takes the platform inherits the rules that keep it coherent. And with a template repository, so a new service starts standardised instead of being standardised later. Drop-in feature modules (feature flags, users, AI chat) arrive with migrations for every database the platform supports.

This is the work I have done most of, and the work I see offered least. Four services with four different ways of validating a request is the situation it exists for.

{
  "distribution": "Versioned NuGet packages",
  "packages": [
    "CQRS abstraction & validation pipeline",
    "EF Core + spatial persistence integration",
    "Identity-provider integration",
    "Mail, storage, localisation, caching"
  ],
  "comes_with": [
    "Reusable architecture-test kit",
    "Drop-in feature modules with migrations",
    "Changelogs on an in-house registry"
  ],
  "projects_mount_not_copy": true,
  "published_to": "an in-house registry and CI"
}

PATCH /v1/legacy

Move an old estate to modern .NET incrementally. PATCH, not PUT. The platform pieces get replaced one at a time.

A rewrite sounds like the decisive answer. It's also the one that most often runs long and lands late. The alternative is unglamorous: put a façade in front of the old application, move one bounded slice at a time behind it, and keep both halves shippable at every step. Every migration has a slice you can move this month and a slice you shouldn't touch for a year. The first job is telling them apart.

I work both ends of the age range at once. A .NET Framework 4.7.2 codebase on EF6 and MSBuild in one window, greenfield modern .NET in the other. And I've executed platform-wide migrations, not just proposed them. A mediator library replaced by an in-house CQRS abstraction. One message bus swapped for another. SQL Server moved to PostgreSQL. All of it on systems that stayed in service throughout.

{
  "strategy": "strangler fig, slice by slice",
  "steps": [
    "Tests that pin down current behaviour",
    "Reverse-proxy façade in front of the old host",
    "Port one bounded slice to modern .NET",
    "Shift traffic, verify, repeat",
    "Retire the old host last"
  ],
  "big_bang_cutover": false,
  "shippable_at_every_step": true
}

GET /v1/practice

The things held in place by machinery rather than by good intentions.

Standards written in a document decay the week after they're written. Standards a pipeline refuses to merge don't. Everything below fails a build instead of appearing as a comment on a pull request, and that's the only version of a standard that survives a busy quarter and a change of staff.

$ git push && # the pipeline decides

ok build            warnings = errors
ok architecture     layers, naming
ok unit             substitutes
ok integration      real db + broker
ok spec lint        openapi
ok quality gate     static analysis

{ "merge": true }

GET /v1/ai-tooling

AI-assisted engineering, committed to the repository as tooling, so a team's standards outlive the people who set them.

Alongside the architecture tests and the CI gates, I check a team's conventions in as tooling that actually runs. Concretely: Claude Code skills that scaffold a complete vertical slice (entity, database configuration, migration, commands, queries, controller) already conforming to the architecture. Specialised AI review agents for architecture, query performance, correctness and test quality. Path-scoped rule files. And MCP server definitions versioned alongside the code they serve.

The point isn't novelty, and it isn't that AI writes the code. It's that a new developer's first pull request looks like the codebase's tenth, and a reviewer's attention goes to the domain instead of to layer violations and naming. A generated slice is a starting point a human then owns, and every one of those agents produces a recommendation a person accepts or rejects.

Most of this is easier to show than to describe, so it is the part I would rather walk through in a repository than write down. It is also the clearest example of a wider habit: I would rather encode a convention once than repeat it in twenty reviews.

{
  "committed_tooling": [
    "Claude Code skills: slice scaffolding",
    "AI review agents (architecture, tests)",
    "Path-scoped convention rules",
    "MCP server definitions, in-repo"
  ],
  "generated_slice": [
    "entity", "configuration",
    "migration", "commands",
    "queries", "controller"
  ],
  "reviewed_by_a_human": true
}