Peter Pokoraczki YTBsoftEmail me

I build the AI feature, the cloud platform under it, and the pipeline that keeps it safe.

Peter Pokoraczki, senior freelance engineer in Bratislava. One person for the three jobs that usually need three hires: getting a model into a product, designing the cloud it runs on, and making delivery fast and auditable. Building on Azure and AWS since 2014. Available for contract work and senior full-time roles, remote first across the EU and on site in Bratislava when it matters.

Email me How an engagement runs
Diagram: an AI feature running on a cloud platform (AWS and Azure), both fed by a delivery pipeline with scan and sign gates.AI featureRetrievalModelToolsCloud platformAWScomputedataidentityAzurecomputedataidentityruns onPipelinecommitbuildscansigndeploy

Every engagement runs these six steps in this order. Each one is explained further down.

  1. 01Discoverdone
  2. 02Designdone
  3. 03Builddone
  4. 04Shipdone
  5. 05Hardendone
  6. 06Hand overdone

AI engineer

LLM features that survive contact with production.

DocsIndexModelToolsEvals in CI

I take language-model work past the demo. That means choosing the model and where it runs (Azure OpenAI, Amazon Bedrock, Azure AI Foundry, or open weights on your own compute) for the constraint that actually matters to you, wiring it into your existing TypeScript, Python, or Go services, and building the retrieval, tool calls, and guardrails around it.

Every feature ships with an eval set and tracing, so a prompt or model change can be judged before users do the judging. Costs are budgeted per request, not discovered on the invoice.

What you get

  • A feature in your product, not a notebook: typed contracts, retries, timeouts, and token budgets.
  • Retrieval that is measured. Chunking, ranking, and hybrid search chosen against your documents, with a test set we keep.
  • Agents with limits: scoped tool permissions, human checkpoints, and an audit trail of every action.
  • Evals and traces in CI, so a regression is caught on the pull request.

Stack

  • TypeScript
  • Python
  • LangGraph
  • pgvector
  • Azure OpenAI
  • Amazon Bedrock
  • Azure AI Foundry
  • Azure AI Search
  • OpenTelemetry
  • Prompt and eval harnesses
  • Semantic Kernel
  • C# / .NET

Cloud architect

Cloud platforms a small team can actually run.

Landing zoneIdentityNetworkPolicyProdDevShared

I design and build the platform your systems live on: account and subscription structure, landing zones, networking and identity, the compute choice (containers, serverless, or a managed app service) and the data tier behind it. AWS and Azure are my specialties; I also work with GCP where a client is already there. Everything is code from day one, in Terraform, Bicep, or CDK, so environments are reproducible and the bill is explainable.

I have moved systems between data centres and clouds, split monoliths into services, and merged services back into a monolith when that was the right call. The target is the simplest system that meets the load, the recovery objectives, and the budget, with the trade-offs written down.

What you get

  • A reviewed target architecture with the decisions and their reasons recorded, not only a diagram.
  • Landing zone, accounts or subscriptions, and environments as code, with policy, IAM or RBAC, and private networking applied from the start.
  • Reliability work: queues, idempotent handlers, health checks, failover across zones or regions where it pays for itself, and load tests before go-live.
  • A migration plan with cutover steps and rollback when you are moving between providers or out of a data centre.
  • A cost model, plus the tags, budgets, and rightsizing that keep it honest month to month.

Stack

  • AWS
  • Azure
  • GCP (secondary)
  • Terraform / OpenTofu
  • CDK / Pulumi (TypeScript)
  • Bicep
  • Go for tooling
  • EKS / AKS
  • ECS / Container Apps
  • Lambda / Functions
  • App Service
  • SQS / Service Bus
  • DynamoDB / Cosmos DB
  • RDS / Azure SQL
  • PostgreSQL
  • Redis
  • IAM / Entra ID
  • CloudFront / Front Door

DevSecOps engineer

Delivery you can audit, from commit to production.

commitbuildscansigndeployobservealerts and traces feed the next change

I build the path from pull request to production, then harden it. Pipelines in GitHub Actions or Azure DevOps that authenticate with workload identity instead of stored credentials. SBOMs, signed images, and dependency scanning as gates rather than reports. Secrets in Key Vault or Secrets Manager reached through workload identity, never in pipeline variables.

Then the run side: containers built from minimal bases, Kubernetes (AKS or EKS) with admission policies and network rules, and logs, metrics, and traces that answer the question being asked at three in the morning.

What you get

  • CI/CD that is fast, reproducible, and reviewable, with the same promotion path for every environment.
  • A supply chain you can show an auditor: SBOM, signatures, provenance, and scan results per release.
  • Identity and secrets done once, properly, across pipelines and workloads.
  • Dashboards and alerts tied to service objectives, with runbooks for the alerts that page someone.

Stack

  • GitHub Actions
  • Azure DevOps
  • Terraform / OpenTofu
  • Go (operators, CLIs)
  • Docker
  • Kubernetes (AKS / EKS)
  • Helm
  • Trivy
  • Cosign / Sigstore
  • SBOM / SLSA
  • Key Vault / Secrets Manager
  • Entra ID / IAM (OIDC)
  • OPA Gatekeeper
  • OpenTelemetry
  • Azure Monitor / CloudWatch
  • Grafana
  • Defender / GuardDuty

Selected work

Most of this work sits under NDA, so clients are not named here. Ask on a call and I will walk you through any of them in detail.

  • AI engineer

    Document intelligence for an insurance back office

    Claims and policy documents classified and extracted by an LLM pipeline, with a 400-document eval set kept in CI. Manual triage time roughly halved.

    Azure OpenAI, Azure AI Search, Python evals, C# / .NET

  • AI engineer

    Support assistant for a B2B SaaS product

    Retrieval over product docs and past tickets, tool calls into the account API, and a human checkpoint before any change to a customer account.

    Amazon Bedrock, pgvector, TypeScript, LangGraph

  • Cloud architect

    Data centre exit for a logistics platform

    A monolith estate moved into Azure: subscriptions, networking, identity, and every environment defined in Terraform, with a rehearsed cutover and rollback.

    Azure, Terraform, AKS, Service Bus, Go migration tooling

  • Cloud architect

    Multi-account AWS platform for a fintech start-up

    Account structure, IAM boundaries, and a platform on ECS and RDS defined in Terraform, with a cost model the founders could read without help.

    AWS, Terraform, ECS, RDS, CloudFront, TypeScript

  • DevSecOps engineer

    Supply-chain hardening for a regulated healthcare product

    GitHub Actions with OIDC, signed images, an SBOM per release, and admission policies on Kubernetes. Passed an external audit without findings.

    GitHub Actions, Cosign, Trivy, OPA Gatekeeper, Go tooling

  • DevSecOps engineer

    Observability and on-call for a payments service

    Traces, service objectives, and alert runbooks in place of a wall of dashboards. Pages per week down by two thirds.

    OpenTelemetry, Grafana, CloudWatch, Go

How I work: the same six steps, every time.

Most engagements run this order whether the job is an AI feature, a platform, or a pipeline. Steps can be short, but none are skipped: the ones that get skipped are the ones that come back as incidents.

  1. Discover

    A call, then a written brief: the problem, the constraints, what "done" means, and what I would need from your team.

    one to two days, no charge

  2. Design

    Target architecture and a plan with options and their trade-offs, an estimate, and the risks named up front.

    a fixed-price week for larger work

  3. Build

    Small pull requests into your repository, reviewed by your team, with a working demo at the end of every week.

    your repo, your standards

  4. Ship

    To production early and behind flags, so feedback comes from real use rather than a final big-bang release.

    production before the end of the first month

  5. Harden

    Security review, load test, cost review, and the monitoring and alerts that let you sleep after I leave.

    a written report with findings and fixes

  6. Hand over

    Documentation, runbooks, and a session with your engineers. Your team owns it; I stay available for questions.

    no lock-in, no retainer required
Engagement
Contract, part-time advisory, or senior full-time role
Location
Remote first, EU time zones; on site in Bratislava and Vienna when it matters
Typical length
Six to twelve months, extendable
Rates
Day rate on request; fixed price for scoped design work
Portrait of Peter Pokoraczki in a navy blazer

Hello, I am Poki.

I started as a .NET developer, followed the work into browser applications when single-page apps arrived, and then into the cloud, Azure first and AWS after it, as clients moved there. These days I write TypeScript and Go by preference, Python where the AI tooling lives, and I design and run the AWS and Azure platforms underneath. The last few years have been about making language-model features work inside real products, which turned out to need all three roles on this page at once: the model work, the platform under it, and the delivery around it.

I have worked as an independent contractor under my own company, YTBsoft, since 2014, mostly remote, with product teams in Slovakia and Austria and across the EU. I prefer small teams, direct conversations, and code that the next engineer can read.

Off the clock: books, a properly cooked steak, and more Apple hardware than one person needs.

Name
Peter Pokoraczki
Based in
Bratislava, Slovakia
Works
Remote, EU time zones
Company
YTBsoft
Works in
TypeScript, Go, Python, C# / .NET
Working since
2014
Languages
English, Slovak
LinkedIn
linkedin.com/in/peter-pokoraczki

Tell me about the system, the stack, and the timeline.

pokoraczki.ytbsoft@gmail.com

A few lines are enough. I reply within one working day, and if it sounds like a fit I will suggest a short call and send a written brief after it.