
Denys Zaichenko
Forward Deployed Engineer
A maioria dos programadores pede uma especificação. Eu aprendo como o seu negócio realmente funciona.
Para um cliente, isso transformou um processo de 2–3 semanas em 2–3 minutos.
- Documentos imobiliáriosCertidões de imóveis em 2–3 minutos por EUR 99, e não em 2–3 semanas por EUR 200–300.Ver o caso
- Agência de viagensPreços de pacotes da concorrência, recolhidos cerca de duas vezes mais depressa.Ver o caso
- RadiodifusãoFalhas de áudio alertam os operadores no momento em que acontecem. Acabou a escuta manual.Ver o caso
Atividade recente
- contribuições
- 4724
- por dia útil
- 20
- Última entrega
- 14/10
4724 contribuições no último ano, 20 por dia útil
Selecione um dia para ver o que foi entregue.
25/09 · 60 contribuições
- Monitorização de áudio de emissão: Perfis de limites predefinidos para cada novo tenant
Entregas recentes
- O formulário Leeloo redireciona para o bot do Telegram após o envio
- Bounces encontrados na caixa de entrada, as cadeias correm sem espera
- Reverificar bounces durante uma execução e parar no limite
Como trabalho
Quatro regras que sigo em cada projeto.
Perceber primeiro o negócio
Começo pela forma como o trabalho é realmente feito e pelo custo de uma falha, não pelo ticket. Isso diz-me o que tem de ser fiável e o que pode continuar simples.
Encontrar a verdadeira limitação
A maioria dos processos lentos tem um único estrangulamento. Identifico-o antes de escrever código, para que a solução corrija a causa e não os sintomas.
Ponderar as opções às claras
Em cada decisão importante, vê o que escolhi, o que rejeitei e quanto custa cada escolha. Pode contestar antes de se construir seja o que for, e não depois.
Entregar algo que possa verificar
Cada projeto termina com uma prova que pode verificar pessoalmente: um número mensurável ou um teste executado em cada deploy.
Trabalho para clientes
Serviço de documentos imobiliários para vendas de imóveis
Certidões de imóveis em 2–3 minutos em vez de 2–3 semanas.
Antes
Os vendedores pagavam EUR 200–300 por cada certidão e esperavam 2–3 semanas enquanto alguém reunia os papéis à mão.
Depois
2–3 min
por certidão, em vez de 2–3 semanas
EUR 99
por certidão, em vez de EUR 200–300
95%
dos documentos concluídos no principal portal conhecido
Como funciona
O que construí
O serviço entra nas contas dos administradores, recolhe os dados e gera a certidão sozinho. Cinco verificações correm em cada documento antes da entrega; os portais desconhecidos vão para IA de visão.
- 1Pessoa:Cliente
Encomenda uma certidão de imóvel.
- 2Sistema:Script
Portal conhecido: entra na conta e recolhe os dados.
Sistema:IA de visãoPortal desconhecido: lê as páginas.
- 3Sistema:Serviço
Gera a certidão.
- 4Sistema:Serviço
Executa cinco verificações e envia depois a certidão ao cliente.
Sempre garantido
- Um passo falhado é repetido automaticamente.
- O operador vê cada job em tempo real.
- App do operador
- Next.js
- React
- Tailwind CSS
- Radix UI
- Zod
- Dados e jobs
- Supabase
- PostgreSQL
- Automação e IA
- Python
- Playwright
- Crawl4AI
- Docling
- Instructor
- Gemini
- Entrega
- Docker
- Vitest
- EU-hosted server
Controlo de qualidade de áudio em direto para uma equipa de operações de média
As falhas de áudio alertam agora no momento em que ocorrem; a verificação era manual.
Antes
A equipa verificava o áudio dos comentários à mão, pelo que uma falha não detetada podia chegar aos espectadores.
Depois
1 hora
de leituras guardadas na máquina local durante uma falha de rede; eventos durante 24 horas
Como funciona
O que construí
Um agente no local mede cada canal e envia as leituras para um serviço na cloud. Os operadores têm uma consola web com projetos, limiares e alertas.
- 1Sistema:Local do evento
Envia o áudio dos comentários em vários canais.
- 2Sistema:Agente local
Mede cada canal segundo as normas de loudness da EBU.
- 3Sistema:Agente local
Guarda as leituras em disco e reenvia-as após uma queda de rede.
- 4Sistema:Serviço cloud
Dispara um alerta quando uma falha dura o suficiente.
- 5Pessoa:Operador
Vê alertas e incidentes na consola web.
Sempre garantido
- A cloud ignora leituras duplicadas, por isso um reenvio nunca conta duas vezes.
- Agente local
- Python
- EBU R128 loudness
- ONNX Runtime
- PyTorch
- SpeechBrain
- Windows build
- API na cloud
- FastAPI
- SQLAlchemy
- Alembic
- PDF reports
- Dados
- TimescaleDB
- PostgreSQL 17
- Consola do operador
- Next.js
- React
- TanStack Query
- WebSockets
- uPlot
- Zustand
- Qualidade e entrega
- Docker Compose
- GitHub Actions
- uv
- Ruff
- mypy
- pytest
- Playwright
- axe
Benchmark de preços de pacotes de férias para agência de viagens, mercado da UE
Preços de pacotes da concorrência, recolhidos por agenda, em jobs que recuperam de falhas.
Antes
Comparar à mão os preços dos pacotes com a concorrência não escalava, e os jobs de recolha ficavam presos após cada falha.
Depois
~5×
mais datas recolhidas por minuto num site depois de dispensar o browser (8 → 43)
Como funciona
O que construí
Um agendador executa jobs de benchmark num pool de browsers com proxies rotativos. A equipa usa uma consola de administração, e o agente de IA do cliente também pode iniciar benchmarks.
- 1Pessoa:Equipa
Escolhe um pacote a comparar: cidade de partida, data, duração da estadia, ocupação.
- 2Sistema:Agendador
Inicia o job de benchmark.
- 3Sistema:Browsers
Recolhem os preços da concorrência atrás de proxies rotativos.
Sistema:Cliente HTTPLê a única fonte que não precisa de browser.
- 4Pessoa:Equipa
Vê a comparação de preços na consola de administração.
Sempre garantido
- Após uma falha, o pool de browsers repõe-se sozinho.
- O agente de IA do cliente também pode iniciar um benchmark.
- Recolha
- Python
- Camoufox
- Playwright
- curl_cffi
- Rotating proxies
- Apify
- API e dados
- FastAPI
- Supabase
- PostgreSQL
- Consolas de administração
- Next.js
- React
- Vite
- TanStack Query
- Chart.js
- Ligação ao agente de IA
- MCP server
- Qualidade
- GitHub Actions
- gitleaks
- Vitest
- pytest
Documentos, formulários e mapas de controlo para equipas de construção
Do Google Sheets e Docs para uma só plataforma onde trabalha toda a equipa de obra.
Antes
Documentos, formulários e relatórios de obra viviam em Google Sheets e Docs. As atualizações da obra chegavam tarde ao escritório.
Depois
Documentos, formulários, mapas de controlo e relatórios correm numa só plataforma com perfis. Os clientes acompanham o progresso no seu portal.
Como funciona
O que construí
Uma só plataforma com perfis impostos por regras da base de dados, relatórios com fotos e formulários vindos da obra, formulários convertidos em PDF, links de convite, autenticação de dois fatores, portal de partilha com clientes, registo de auditoria e faturação.
- 1Pessoa:Proprietário
Configura um projeto com secções, mapas de controlo e equipa.
- 2Pessoa:Gestor de projeto
Cria um formulário ou escolhe um modelo e envia-o para a obra.
- 3Pessoa:Equipa de campo
Preenche-o na obra, com fotos e assinatura. As respostas escritas sobrevivem à perda de sinal.
- 4Pessoa:Gestor de projeto
Aprova-o ou devolve-o.
Sistema:PlataformaConverte o formulário aprovado em PDF e atualiza o mapa de controlo.
- 5Sistema:Plataforma
Guarda os documentos em pastas com versões e exporta relatórios para PDF e Excel.
Pessoa:ClienteAcompanha pastas e mapas de controlo no seu próprio portal.
Sempre garantido
- Cada empresa vê apenas os seus próprios dados.
- Cada perfil vê apenas o que deve. A base de dados impõe-no.
- Os links de ficheiros expiram, por isso um link reencaminhado deixa de funcionar.
- Cada alteração fica no registo de auditoria.
- Aplicação
- Next.js
- React
- Tailwind CSS
- Radix UI
- Zod
- Dados e segurança
- Supabase
- PostgreSQL row-level security
- TOTP two-factor
- Signed file links
- Documentos
- React-PDF
- Resumable uploads (tus)
- ExcelJS
- E-signatures
- Faturação e email
- Stripe
- Resend
- Entrega
- Vercel
- GitHub Actions
- Vitest
- Playwright
Registo de horas de projetos e equipa para uma auditora
Registo de horas em que a base de dados, e não o ecrã, decide quem vê o quê.
Antes
Clientes, projetos e horas estavam num único sítio onde todos na firma podiam ver e alterar tudo.
Depois
87
caixas de permissões comprovadas na base de dados real para cada perfil; 30 não faziam nada e foram ocultadas
Como funciona
O que construí
Uma aplicação web de página única sobre Postgres gerido. Cada regra de acesso vive na base de dados e é comprovada por uma matriz automática de perfis antes de cada deploy.
- 1Pessoa:Proprietário
Cria perfis com caixas de seleção por área (clientes, projetos, horas, relatórios) para ver, criar, editar e eliminar.
- 2Pessoa:Colaborador
Regista horas num cliente, projeto e tarefa, ou marca férias e ausências.
Sistema:Aplicação webAvisa quem ainda tem a folha de horas vazia antes do prazo.
- 3Pessoa:Administrador de projeto
Aprova ou rejeita a folha de horas da semana da sua própria equipa de projeto.
- 4Sistema:Base de dados
Mostra a cada pessoa apenas o que o seu perfil permite: a equipa vê as suas próprias horas, os administradores de projeto a sua equipa, os proprietários todos os clientes.
- 5Pessoa:Proprietário
Consulta as horas por cliente, projeto e pessoa nos dashboards e relatórios.
Sempre garantido
- Antes, todos na firma podiam abrir todos os clientes e as horas de todos. Agora a base de dados recusa tudo o que um perfil não permite, mesmo que um ecrã o peça.
- Antes de cada push, cada perfil é testado numa cópia isolada da base de dados.
- Aplicação
- React
- Vite
- TanStack Router
- TanStack Query
- shadcn/ui
- Chart.js
- Dados e segurança
- Supabase
- PostgreSQL row-level security
- Edge Functions (Deno)
- Alojamento
- Cloudflare
- Qualidade
- GitHub Actions
- Role-matrix tests
- Vitest
- Property-based tests
- Accessibility tests
Preços e condições
- Faturação
- Subscrição mensal fixa
- Pausar ou cancelar
- A qualquer momento
- Reembolso
- Reembolso total se não ficar satisfeito na primeira semana
- Pedidos
- Por Slack ou Telegram
- Tempo de resposta
- Num dia útil, hora de Lisboa
Média de 5,0 com base em 5 avaliações no Upwork
Ver todas as avaliações no UpworkPerguntas frequentes
Usa IA para escrever o meu código?
Sim. As ferramentas de IA aceleram as partes rotineiras do trabalho. Sou programador sénior com mais de 8 anos de experiência e utilizador certificado de Claude Code. O critério, as decisões de arquitetura e as verificações de qualidade são meus.
Como comunicamos?
Trabalhamos de forma assíncrona, por Slack ou Telegram. O plano Builder inclui uma chamada de sincronização semanal de 30 minutos e o plano Partner uma chamada de estratégia mensal. Trabalho na hora de Lisboa (WET/WEST, UTC+0/+1), que coincide em tempo real com o Reino Unido, a Irlanda e a maior parte da Europa. As chamadas para a costa leste dos EUA são de manhã.
E se o meu código for complexo ou legado?
O ideal: projetos novos ou a evolução do que construímos em conjunto. Se já tem uma base de código, começamos com uma auditoria de código de uma semana para confirmar que conseguimos trabalhar nela em segurança. Depois decidimos juntos se continuamos.
E se não ficar satisfeito?
Se não ficar satisfeito na primeira semana, devolvo-lhe o valor na totalidade. Sem perguntas.
Posso pausar a minha subscrição?
Sim. Pode pausar quando quiser com uma só mensagem. Não há penalizações.
O que é um Forward Deployed Engineer?
Um Forward Deployed Engineer trabalha diretamente com a equipa do cliente e cria e publica software para os problemas dessa equipa, em vez de construir à distância um produto genérico. É assim que trabalho. Entro no seu Slack ou Telegram, recebo as tarefas de si e publico o que construo. Títulos como engenheiro de IA ou programador full-stack descrevem as minhas competências. Forward deployed descreve a forma como trabalho consigo.
O que conta como uma tarefa?
Uma tarefa é uma entrega com âmbito bem definido, como uma funcionalidade, uma correção de bug, uma integração ou uma página. Se algo for grande, dividimo-lo primeiro em tarefas mais pequenas. Sabe o que vai receber antes de eu começar.
Contacto
Diga-me o que precisa que eu desenvolva. Respondo no prazo de um dia útil, hora de Lisboa.
Blog
Notas sobre agentes de IA, automação e desenvolvimento web, a partir de projetos reais.