Discuss a project

01Closeflow — backend & systems engineering

We build systems that have to work.

Backend systems, AI products and integrations for problems that templates, no-code tools and fragile prototypes can no longer handle. From architecture and implementation through to reliable production operation.

Discuss a project See the work

Terms

  • Contract
  • NDA
  • Fixed scope / monthly
  • Team of 2–3
  • Remote
pgvectorN.01INPUTwebhooks · forms · eventsN.02APIauth · limits · contractsN.03PROCESSINGqueues · workers · retriesN.04DATAPostgreSQL · RedisN.05AILLM · RAG · embeddingsN.06RESULTCRM · report · action
fig. 1A typical pipeline. Every node is a failure point that has to be designed for up front.

02When to bring us in

When it makes sense
to bring in Closeflow

  1. Your backend can no longer keep up with growth.

    latency · concurrency · storage · queues

    We find the bottlenecks, separate hot paths from heavy ones and move long-running work onto queues — without a rewrite.

  2. Disconnected services keep breaking your processes.

    API · webhooks · CRM · marketplaces · payments

    Contracts, queues, retries and reconciliation instead of scripts that fail silently.

  3. An AI prototype needs to become a production system.

    RAG · LLM · GPU · observability

    Retrieval with sources, memory and context, cost and latency control, fallback models for when a provider goes down.

  4. The problem doesn’t fit inside a web framework.

    C++ · native software · CAD / BIM · performance

    Native applications, rendering, integrations with engineering software, and domains governed by formal constraints.

  5. Manual work has started to cost real money.

    workers · ETL · schedulers

    Exports, reconciliations and copy-paste between systems become scheduled jobs with error reports.

  6. Your team needs a senior engineer for a specific project.

    contract · module ownership · subcontract

    We join your team or agency for the length of the project — owning a module or working white-label.

03Projects

Projects, written up as engineering dossiers

Problem, architecture, engineering decisions and current state. Open-source work links to the code; commercial work is described without client names or details. No metrics you can’t verify.

Problem

An AI product in a demo and an AI product under load are different systems. Model providers go down and change their prices, conversations lose context, image generation needs GPUs, and every extra thousand tokens is a direct cost.

Architecture

Not a wrapper around one LLM API, but a platform. Go backend, Next.js and React front end, streaming chat over WebSocket and SSE. A single gateway across several LLM providers: smart routing by model and cost, circuit breakers, fallback routes, token counting and billing. On top of it — memory and a semantic cache on pgvector, a node-based workflow editor with its own execution engine, and eval harnesses. A separate pipeline handles LoRA training for SDXL and FLUX and generation through ComfyUI on rented GPUs.

Engineering decisions

  1. Routing between providers: model choice by task and cost, circuit breakers that cut off a failing provider, retries and fallback routes — one model going down doesn’t take the product with it.
  2. Three-layer memory: short-term context in Redis, structured facts in PostgreSQL, semantic retrieval in pgvector — with confidence weighting. Prompts are assembled against a token budget.
  3. A semantic response cache and an eval harness with an LLM judge: quality and cost are measured, not guessed; A/B experiments on real scenarios.
  4. Billing integrity: balance holds in Redis and a background worker that reconciles payments. Safety and persona guards before and after generation.
  5. A node-based workflow engine: a graph editor in the UI and server-side step execution, with observability per node.
  6. A separate GPU pipeline: LoRA training, ComfyUI generation and character consistency across generations, on capacity rented from RunPod and Vast.ai.
  7. Observability and load testing: Prometheus and Grafana metrics, k6 load testing, zero-downtime migrations, backups and CI / CD.

Outcome

Systems built from architecture through release and the operational layer, with billing, monitoring and fallback paths. Client details are under NDA — what’s described here is the engineering, not a specific implementation.

Diagram: Client, API · Go, Memory, LLM gateway, Generation, Providers, GPUClientWebSocket · SSEAPI · Gosessions · billingMemoryRedis · pgvectorLLM gatewayrouting · cacheGenerationjob queueProvidersbreaker · fallbackGPUComfyUI · LoRA
fig. The gateway picks a provider and builds the prompt from three memory layers within a token budget. Image generation runs on its own GPU queue.

Problem

Full-featured PDF editors are either subscription products or Electron apps: slow to start, hundreds of megabytes of memory, sluggish on large documents. The goal is a native editor that runs locally, starts fast and needs no account.

Architecture

A layered system of statically linked libraries: core, render, editor, ui, a platform layer and a PDF engine adapter. PDFium sits behind Rivet’s own interfaces and AppKit behind platform ones. A custom retained-mode UI — no GUI framework and no browser inside.

Engineering decisions

  1. Tile-based rendering with bounded caches: smooth scrolling and zoom without re-rendering whole pages or letting memory grow unchecked.
  2. Serialized per-document access: the PDF engine isn’t thread-safe, and the UI must never wait on it.
  3. Stable page identity underpins undo / redo for reordering, rotation, cropping, annotations and content edits.
  4. Real PDF content editing: moving objects, retyping existing text in place, replacing images.
  5. Background saves with atomic file replacement, so a crash never corrupts the document. PDF JavaScript and XFA are disabled; key decisions are recorded as ADRs.
  6. CI builds and tests the portable layers on macOS and Linux; performance tests catch rendering regressions before release.

Outcome

macOS build: viewing, search, page management, annotations, text and image editing. The core layers are platform-independent; native Windows and Linux shells are the next stage.

Diagram: Action, rivet_app, platform, rivet_editor, save, rivet_render, rivet_pdf, rivet_pdfium, PDFiumActionclick, type, scrollrivet_appshell · controllersplatformAppKit · CoreTextrivet_editorcommands · undosavetmp + renamerivet_rendertiles · cacherivet_pdfinterfacesrivet_pdfiumadapterPDFiumJS · XFA off
fig. Dependencies point strictly downward. The engine and the platform are isolated behind adapters.

Problem

An inbound lead passes through forms, mailboxes, messengers, telephony, the CRM and ad accounts. First response is slow, follow-ups are manual, and tying revenue back to the lead source is close to impossible because the data is spread across a dozen systems.

Architecture

A multi-tenant modular monolith on Java 21 and Spring Boot 3, with modules communicating through events over Kafka. Lead intake and normalization, first response, follow-up sequences, routing, SLA escalation, attribution and ROI reporting. Next.js on the front end; PostgreSQL and Redis for storage.

Engineering decisions

  1. A modular monolith rather than a sprawl of services: one build and one deployment, but strict module boundaries and communication through events only.
  2. Sequences stop the moment a prospect replies: inbound mail and messages are matched to their sequence across every mailbox and channel.
  3. Connectors for CRMs, ad platforms, forms, mail, messengers and telephony. One failing integration never stalls the rest.
  4. Billing, observability and an AI support assistant are modules of the same platform — not side spreadsheets and scripts.

Current state

The core technical system and MVP were implemented: lead intake and normalization, integrations, routing, automated sequences, SLAs, attribution, billing and observability. Further development was paused pending a review of parts of the business logic and the go-to-market model.

Product takeaway

A working architecture is not a validated business model. Further engineering investment is on hold until the product and its distribution channels have been reworked.

Diagram: Channels, CRM · Ads, Intake, Connectors, Kafka, Sequences, Routing, Attribution, PostgreSQLmodular monolithChannelsforms · mail · callsCRM · Adsexternal APIsIntakenormalize · dedupConnectorslimits · retriesKafkamodule eventsSequencesreply · follow-upRoutingSLA · escalationAttributionsource → revenuePostgreSQLtenants · reports
fig. Every channel feeds one event stream. Modules never call each other directly.

Problem

Early building layouts are slow, manual work: a developer’s requirements have to be reconciled with planning constraints and building codes, and the result then redrawn in CAD. Every iteration starts over by hand.

Architecture

An AI agent drafts building layouts from the developer’s requirements and planning constraints. Regulatory rules, including Russian GOST standards, live in a separate, updatable knowledge layer. Output goes into AutoCAD and Revit as structured data, not as a picture.

Engineering decisions

  1. Regulations are data, not code: when the rules change, the knowledge layer is updated — not the agent’s logic.
  2. Constraints are formalized, so layouts are generated within the rules rather than on the model’s best guess.
  3. AutoCAD and Revit integration: planning data lands in the designer’s own tools, where the work continues.
  4. AI beyond the chatbot: the model is one component of an engineering system, alongside geometry, rules and CAD integrations.

Outcome

The system produced early-stage draft layouts and handed them over to CAD / BIM workflows. Client and implementation details are under NDA.

Diagram: Requirements, Regulations, Core · C++, Knowledge, AI agent, AutoCAD, RevitRequirementsdeveloper · siteRegulationsGOST · rulesCore · C++geometry · limitsKnowledgeupdatable layerAI agentdraft layoutsAutoCADdrawingsRevitBIM model
fig. Regulations live in their own knowledge layer. The agent works within them and hands CAD a structure, not a picture.

Further work

Problem

A multi-application rental platform spanning guest search and booking, mobile, host operations, PMS integrations, payments and owner reporting. Dozens of backend modules · hundreds of versioned migrations · extensive background and scheduled processing.

Architecture

Backend — a multi-domain Django core covering bookings, payments, PMS synchronization, background processing, WebSocket communication and APIs for several client applications; PostgreSQL / PostGIS, Redis, Celery. Web — a public client and cabinets in Vue 3: search, property pages, booking, host and organization cabinets, a standalone booking widget and custom prerendering for SEO. Mobile — a cross-platform Flutter application for iOS and Android covering guest and host flows: search and booking, maps, trips, QR login, push notifications, deep links, biometrics and Sign in with Apple (Flutter · Dart · bloc · dio · OneSignal · Yandex MapKit · Codemagic · fastlane). Internal tools — two separate React / Express systems: a host operations cabinet and an owner financial-reporting hub.

Engineering decisions

  1. Integrations: PMS and booking channels, payment acquiring, messengers, push, Google Sheets, maps and geocoding.
  2. Reliability: background queues, retries and idempotency, booking and payment reconciliation, data-quality checks, tracing and monitoring.
  3. One backend serves guests, hosts and owners through the web, the mobile app and internal cabinets.
  4. Observability and delivery: OpenTelemetry, Prometheus, Grafana, Docker, GitHub Actions.

Outcome

Led the technical side: architecture, code review, release process; worked on the backend, the Vue client, the Flutter app and two Node.js systems.

Problem

A client retries after a timeout. The broker redelivers a message. A worker crashes after charging a card but before committing. Exactly-once delivery doesn’t exist in a distributed system — yet a charge, an order or an email must happen exactly once.

Architecture

A Node.js gateway accepts an event only with an Idempotency-Key and writes it to an outbox in the same transaction. A Java / Spring Boot relay ships the outbox to Kafka (Redpanda in the test bench) with retries and rate limiting. A Java consumer deduplicates through an inbox table and applies the business effect in the same transaction that marks the event as processed.

Engineering decisions

  1. At-least-once delivery plus idempotent intake gives an exactly-once business effect. The guarantee rests on database invariants, not hope.
  2. A retry with the same key returns the same response; a concurrent duplicate sees “processing” instead of creating a second record.
  3. Redis serves as a fast response cache and rate limiter. If it goes down, the gateway falls back to PostgreSQL instead of failing.
  4. Load profiles with 30% duplicates and failure scenarios are reproducible in docker compose, driven by a Python load generator.

Outcome

An open reference project: database schema, services, load generator and documented experiments. The same approach — outbox, inbox, idempotency keys — applies to payments, orders and integrations.

Diagram: HTTP, Gateway, Redis, PostgreSQL, Metrics, Relay · Java, Redpanda, Consumer, Effecttransaction 1transaction 2HTTPIdempotency-KeyGatewayNode · dedupRediscache · limitsPostgreSQLevent + outboxMetricsPrometheus · logsRelay · Javaretry · backoffRedpandaat-least-onceConsumerJava · inbox dedupEffectinbox + effect · tx
fig. Two transaction boundaries. Anything between them can fail — the effect still happens once.

Problem

Products that accept crypto shouldn’t need their own logic for watching chains, finalizing payments, redelivering events and reconciling money. A bug in that code costs money, not just convenience.

Architecture

A standalone multi-project payment gateway: the application creates a payment order, and the gateway watches the networks, records incoming funds, keeps a financial ledger and reports the outcome through signed webhooks. One adapter per chain — TRON, EVM, Bitcoin and Solana; clients integrate only through an HTTP API and webhooks, with Go and TypeScript SDKs. Go backend, SQLite storage with migrations.

Engineering decisions

  1. A double-entry ledger: every journal balances, and financial and audit tables are append-only, enforced in the database.
  2. Transactional outbox: the event and its outbox record commit in one transaction, so “paid” is never lost to a crash.
  3. An idempotent API and HMAC-signed webhooks: delivery is retried with backoff until the client explicitly acknowledges (ACK).
  4. Reconciliation: scheduled checks surface unacknowledged events and stuck refunds.
  5. Persistent chain cursors with finality and reorg handling; underpayment, overpayment and late payment are handled explicitly.
  6. Key isolation: the gateway holds no private keys — signing lives in a separate service; refunds fail closed and derive the destination only from on-chain evidence.

Current state

The gateway and multi-chain watching are implemented. The project stands as independent infrastructure work; no production metrics are claimed.

Diagram: Application, API · Go, Watchers, Ledger, Signer, Outbox, Webhookone transactionApplicationorder · keyAPI · Goprojects · keysWatcherschains · cursorsLedgerjournalsSignerkeys kept apartOutboxevent · txWebhookHMAC · to ACK
fig. The event and its outbox record commit in one transaction. Whatever fails afterwards, the webhook is delivered until acknowledged.

04Capabilities

Six disciplines that make up a working system

node / svc

Backend

Services and APIs that hold up under load, retries and changing requirements — without a rewrite.

  • Go
  • Python · Django
  • Java · Spring Boot
  • Node.js · TypeScript
  • C# / .NET
  • REST · WebSocket · SSE
  • queues · background processing

In projects01 Production AI Systems03 Inbound Revenue Operations Platform05 Reho2407 Multi-chain Crypto Payment Gateway

More on this discipline: Backend engineering

node / db

Data

Schemas, transactions and invariants you can rely on. Event streams that neither lose nor duplicate.

  • PostgreSQL · PostGIS
  • Redis
  • MySQL
  • MinIO / S3
  • Kafka · Redpanda
  • ETL / ELT
  • ledger · reconciliation · outbox

In projects06 Execute-once03 Inbound Revenue Operations Platform05 Reho2407 Multi-chain Crypto Payment Gateway

node / ai

AI & ML

LLM features grounded in your data: with sources, memory, predictable cost and a fallback when a provider fails.

  • LLM gateways · routing
  • RAG · agents · memory
  • embeddings · pgvector
  • evals · workflow engines
  • SDXL · FLUX · LoRA
  • ComfyUI
  • TTS / STT

In projects01 Production AI Systems04 AI for CAD / BIM

More on this discipline: AI/LLM engineering

node / sys

Systems

Native, performance-sensitive software where a web framework won’t do: rendering, editors, engineering tools.

  • C++23 · CMake
  • PDFium
  • native desktop
  • CAD / BIM
  • AutoCAD · Revit
  • Flutter · Dart · iOS / Android
  • bloc · dio · push · deep links
  • Codemagic · fastlane

In projects02 Rivet04 AI for CAD / BIM05 Reho24

node / api

Integrations

External APIs, each with its own limits and failure modes, tied into one predictable system.

  • CRM
  • marketplaces · procurement
  • payments · webhooks: HMAC · ACK
  • PMS
  • mail · messaging · telephony
  • business APIs
  • Web3 APIs

In projects03 Inbound Revenue Operations Platform05 Reho2407 Multi-chain Crypto Payment Gateway

node / ops

Infrastructure

An environment where the system can be deployed, observed and fixed without heroics.

  • Docker · Linux · Nginx
  • GitHub Actions · CI / CD
  • Prometheus · Grafana
  • OpenTelemetry
  • k6
  • GPU: RunPod · Vast.ai

In projects01 Production AI Systems06 Execute-once02 Rivet

05Process

From system review to a clean handover

  1. 01 —

    Understand the system

    Data, constraints, dependencies, business rules and points of failure.

    outputsystem and risk map

  2. 02 —

    Settle the architecture

    Interfaces, storage, data flows, ownership boundaries and risks.

    outputADRs · API contracts · data schema

  3. 03 —

    Build a working slice

    First, a production-grade vertical slice through the whole system. Then breadth.

    outputworking end-to-end slice

  4. 04 —

    Test how it fails

    Retries, duplicates, degraded dependencies, observability and alerting.

    outputfailure scenarios · alerts

  5. 05 —

    Launch and hand over

    Deployment, documentation and clear ownership — with no dependency on the original author.

    outputrunbook · docs · deployment

06Working models

Four ways to work together. Chosen to fit the problem, not the other way round.

ModelWhat it isA good fit when
F.01ProjectA defined system or module built to an agreed scope, from architecture to launch.The goal is clear and you need an outcome, not hours.
F.02ContractA senior engineer embedded in your team for a few months — your processes, your repository, your reviews.You have a team but need more backend depth.
F.03SubcontractWhite-label backend, integration or AI work for agencies and integrators. The client stays yours.You’ve won a project that reaches beyond your in-house expertise.
F.04TeamA small engineering team of 2–3 people assembled for the job, with one engineer accountable for the architecture.The timeline or scope is more than one engineer can carry.
Paperwork
  • Contract
  • Invoicing
  • NDA
  • Remote

Happy to sign an NDA before we get into details.

07Principles

Why Closeflow — four engineering choices

  1. Not: Technology for its own sake

    Architecture sized to the problem

    You don’t need Kafka where a PostgreSQL table will do. Complexity is added only when load or risk justifies it.

  2. Not: A fragile demo dressed up as production

    Failure modes from day one

    Retries, timeouts, duplicates and unavailable dependencies are designed for before release, not after the first incident.

  3. Not: Framework loyalty

    Constraints choose the stack

    Go, Python, Java, C# or C++ — chosen on latency, team, ecosystem and maintenance cost, not on fashion.

  4. Not: Vanishing after release

    A system you can understand and hand over

    Documentation, ADRs, runbooks and code that makes sense without its author.

08Experience

From applied backend work to systems where a bug costs money

  1. Foundation

    Backend development and integrations

    Started with applied backend work: APIs, databases, integrations and automation of clients’ internal processes. That layer still underpins most of the systems we build.

    APIs · databases · integrations · automation

  2. Product systems

    From individual services to a whole ecosystem

    On Reho24 the scope grew to a product ecosystem: a shared backend, a public web client, a Flutter app, internal React / Node.js systems, payments, PMS integrations and the operations layer.

    Django · Vue 3 · Flutter · React · Celery · PostgreSQL / PostGIS

  3. AI platforms

    Not an LLM API call — the platform around it

    AI products came next: routing between providers, memory and embeddings, eval harnesses, billing, workflow engines, fault tolerance and observability. Built from architecture through release and the operational layer.

    Go · pgvector · LLM gateway · evals · workflows

  4. Systems engineering

    Native software and concurrent access

    Systems work ran alongside: C++23, PDFium, coordinated concurrent access, rendering, caching and a native desktop layer.

    C++23 · PDFium · AppKit · tile cache

  5. Payment infrastructure

    Correct state matters more than speed

    In payment systems the focus shifted to correctness of state: a double-entry ledger, transactional outbox, idempotency, acknowledged webhook delivery, reconciliation and key isolation.

    Go · ledger · outbox · HMAC · multi-chain

Common to every layer: data state, ownership boundaries, behaviour under failure

09About

Backend / Systems / AI Engineer · Founder of Closeflow

Kirill Zalizky

Experience spans the full stack of complex products: backend systems and integrations, web and mobile clients, AI platforms, payment infrastructure and native software.

The work typically covers architecture, implementation, reliability and operational handoff rather than isolated features. When the scope calls for it, a small team of 2–3 engineers joins.

github.com/Husqvarnalox
Experience
6+ years in production software, including 1.5+ years in applied AI
Languages
Go · Python · TypeScript / JavaScript · Java · C# / .NET · C++23 · Dart
Systems
PostgreSQL · Redis · Kafka / Redpanda · Docker · observability · payment infrastructure: ledger, outbox, reconciliation · GPU infrastructure
Also
Web3 on Solana: wallets, transaction lifecycle, blockchain event ingestion · cross-platform mobile development with Flutter · technical project management, API contracts, documentation

10Contact

Tell us what
has to work.

Describe the problem, your current system and its constraints. If it’s a good fit, we’ll suggest a next step — usually a short call about data, integrations and timelines.

brief.form4 fields · 2 minutes

Budget optional