DB Dan Burdetsky Start a project
Menu

Services

Five practices, one engineering discipline.

AI systems, automation, production platform work, software development and digital systems. The same habits run through all five: expect failure, make it visible, design the way back, and hand it over so somebody else can run it.

Not sure which one you need?

Pick the line that sounds most like your week.

The five practices

Same discipline, five shapes of problem.

Capabilities first, tools last. The tools change every few years and the capability is what you are actually buying.

01

AI Systems & Agents

Agents that take multi-step action, and production AI systems around them. The model proposes. A check decides.

  • Agentic workflows
  • Tool use / function calling
  • RAG / knowledge systems
  • Document & image understanding
  • Structured outputs
  • Validation gates
  • Guardrails
  • On-device / local inference

Selected stackOpenAI · Gemini · MCP · Claude Code · Codex · Cursor
02

Automation & Integration Engineering

Systems, people and data connected into workflows that survive real operational inputs.

  • Workflow architecture
  • Idempotency & deduplication
  • Retries & backoff
  • Quota-safe writes
  • Failure detection & alerting
  • Backup & recovery
  • Human-in-the-loop
  • Data migration & backfill

Selected stackn8n · REST APIs · Webhooks · Slack · Trello · Google Workspace · WhatsApp
03

Platform, Cloud & Reliability

Production infrastructure, delivery and observability built for failure, recovery and clear ownership.

  • Infrastructure as Code
  • Container orchestration
  • Cloud & hybrid architecture
  • CI/CD & release engineering
  • Observability
  • Incident response
  • Disaster recovery
  • 24/7 production operations

Selected stackAWS · Kubernetes · Terraform / OpenTofu · Docker · GitHub Actions · Prometheus · Grafana · Datadog
04

Software Development & Feature Engineering

Features in software you already run, and the applications and checks around it. Written to be handed back.

  • Feature development on existing systems
  • Taking over inherited systems
  • Custom application development
  • Desktop applications
  • Automated checks in CI
  • Review discipline on AI-written code
  • Handover & documentation

Selected stackTypeScript · React · Python · Rust · Tauri · GitHub Actions
05

Digital Systems & Product Engineering

Websites, internal tools and portals built as part of the business behind them.

  • Information architecture
  • Multilingual & localisation architecture
  • SharePoint solutions
  • Performance & accessibility
  • SEO foundations
  • Owner-controlled hosting & handover

Selected stackSharePoint Online · SPFx · React · TypeScript

Ways to work together

Advice, the build, or somebody watching it after.

Project-based and advisory engagements. You do not need to arrive with a finished specification: I can review what you already have, work out where the cost actually sits, design the approach, lead the build, or keep an eye on it afterwards.

01

Architecture & advisory

Review the system you already have, find the real constraint rather than the loudest symptom, and design the approach. Sometimes the answer is that you do not need the build.

02

Build & delivery

Own the implementation from architecture through production handover: the workflows, the code around them, the failure handling, the documentation and the accounts in your name.

03

Support & maintenance

Scoped separately, after handover, for a system that wants somebody watching it. Declining it is a real option and costs you nothing: the handover is complete either way, and nothing in the build depends on me being reachable.

Consulting is how I enter any of the five practices above. It is not a sixth thing on the list, and if a conversation ends with me saying the build is not worth doing, that was a useful conversation.

How a project usually runs

Five steps, and none of them is a surprise.

You approve a written scope and a fixed quote before anything is built, and you own every account at the end of it.

  1. 01

    A short message

    You tell me what exists and where it hurts. I tell you whether I would build anything at all, and what I would look at first.

  2. 02

    Discovery

    I map the real system with the people who run it, including the parts that only exist in somebody’s head. You come out of it with a written scope, the assumptions behind it, and a fixed quote.

  3. 03

    Build

    The smallest useful version first, tested against messy inputs rather than clean ones. You see it running before it touches anything real.

  4. 04

    Handover

    Documentation, a walkthrough, and every account in your name. The system should not become a black box the moment I stop touching it.

  5. 05

    After

    Ongoing support can be scoped separately if you want it. If you do not, it still runs and you still own it.

How big a first project is

What every project includes

The parts that are not negotiable.

DELIVERY STANDARD08 ITEMS
  • 01 A written scope, with its assumptions, before anything gets built ALWAYS
  • 02 Accounts in your name, scoped credentials, no shared logins ALWAYS
  • 03 Failure handling: retries where safe, deduplication, alerts ALWAYS
  • 04 A human review path for anything uncertain or hard to undo ALWAYS
  • 05 Backups and a way back, designed at the start ALWAYS
  • 06 Documentation and a handover walkthrough ALWAYS
  • 07 Review discipline on anything AI helped write ALWAYS
  • 08 No lock-in, everything needed to take it in-house ALWAYS

I use AI coding tools every day. Nothing they produce reaches a real account without being read line by line, tested against safe fake data, and dry-run first.

Start with what exists

Not sure which of the five it is?

Describe what exists today and where it hurts. Working out which practice it belongs to is my job, not yours.

Message Dan on WhatsApp

or email dan@burdetsky.xyz

Start a project