AI product & engineering tandem · remote

We turn GenAI concepts into products that survive real users.

A product lead and an AI systems architect working as one unit. One validates and cuts, the other designs and ships — with no handover in between.

Shipping log · last 12 months
Engram macOS · web
Tasks web · Telegram
VoiceGram Android
Investment Assistant Telegram
Conversation Analyzer Telegram
Advice & wellbeing bot Telegram
Ticket Hunter Telegram
Utility bots Telegram
8 services in production
4 platforms delivered on
Why a tandem

Two seats, one aircraft.

The usual way to build an AI product is to hire a product manager, then an engineer, then wait for them to learn how to work together. We have already spent a year building products side by side — so while one of us is validating a feature against real usage and killing the ones that do not earn their place, the other is already designing the system that will carry the ones that do.

Left seat

Product lead · AI platforms

Thirteen years of product ownership inside large banking groups — the last five owning an internal virtual-assistant and AI-agent platform used across the organisation: travel reports, leave processing, email summarisation, training, account management.

Background in systems analysis; eleven years managing teams of up to twenty-five. Owns discovery, validation, and the uncomfortable question of whether a feature should exist at all.

product ownership AI agent platforms process automation business analysis team leadership · 25+
Right seat

AI systems architect

Ten-plus years in engineering, formerly a server-side Java tech lead running four teams through a monolith-to-microservices migration in high-load banking.

Owns everything downstream of the decision: architecture, backend, clients, tests, deployment and what happens after launch — local speech pipelines, multi-tenant backends, schema migrations run against live data.

Python · FastAPI LLM orchestration local speech models PostgreSQL Kotlin · Swift Docker · VPS

Names, profiles and references are shared on the call — we keep them off the public page while current engagements are live.

Selected work

Products, not demos.

Everything below runs in production with real users. Two are opened up in full; the rest expand. Source and live URLs stay private — we walk through architecture and failure modes in detail on a call.

01 · FLAGSHIP

Engram

Meeting knowledge graph with a local-first pipeline.

● In production · macOS + web
Problem

Meetings produce the decisions a company runs on, and then those decisions dissolve into scattered notes. Cloud transcription solves recall only by uploading confidential conversations to a third party — which rules it out for exactly the meetings that matter most.

Product

Every meeting becomes searchable knowledge — decisions, ideas, open questions — while raw audio and full transcripts never leave the owner's own hardware. Only a distilled layer of insights and short quotes is exposed, on request.

Engineering

A macOS menu-bar app captures the meeting app and the microphone as separate tracks; transcription and diarisation run locally. A private backend extracts insights with an LLM, builds embeddings and serves semantic search, a web viewer and an admin panel. Transcripts are the append-only source of truth; the knowledge graph is a derived index, rebuildable at any time.

Swift · SwiftUI ScreenCaptureKit Whisper (MLX) pyannote FastAPI embeddings MCP
02 · FLAGSHIP

Tasks

Natural-language task tracker across three surfaces.

● In production · web + Telegram
Problem

Trackers ask people to think in fields — title, due date, priority, tags. People think in sentences, usually while doing something else. That friction is why most personal trackers are abandoned in week two.

Product

The form is gone. You write or say what happened — “move the dentist to Thursday and remind me the evening before” — and a parser turns it into concrete operations, shows them for confirmation, and applies them atomically with an undo. One backend serves a web app, a Telegram bot and a Mini App.

Engineering

Multi-tenant from day one, per-user isolation enforced on every query and covered by tests. Google OIDC, Telegram WebApp HMAC auth, personal API tokens. Included an irreversible schema migration executed on a populated production database, with a rehearsed rollback and a migration test against a copy of live data.

FastAPI PostgreSQL SQLAlchemy · Alembic APScheduler aiogram Google OIDC
Problem

Answering messages while driving is dangerous, and the built-in assistants make it worse: they read entire threads out loud, cannot handle a voice note, and stall on “sorry, I didn’t catch that”.

Product

Messaging with both hands on the wheel. The agent reads out a short summary of what arrived instead of the full text, transcribes incoming voice messages, and sends replies dictated by voice — triggered from the steering-wheel button, with no wake word.

Engineering

The core trade-off is recognition: an on-device recogniser handles short commands offline, while a heavier model handles dictation where accuracy beats latency. Contact aliases are inflected grammatically, muted chats stay silent, and the whole thing runs as a foreground service that survives calls, connectivity loss and reboots.

Kotlin Jetpack Compose Hilt · Room ONNX Runtime VoiceInteractionService Whisper
Problem

The market runs 24/7 and the person holding the position does not. Full automation is the obvious answer and the one most people refuse, because handing an algorithm unsupervised access to their money is a step too far.

Product

The assistant watches instead of acting. It monitors the market against user-defined conditions and, when one fires, proposes the trade for one-tap confirmation. Profit targets are set per position; a paid tier adds automatic take-profit — off by default, enabled deliberately.

Engineering

Real money makes correctness the entire job: partial order fills, funds held inside open orders, reconciliation when the user trades manually on the exchange, duplicate-order protection, and retry paths that never leave a position in an unknown state. API keys are stored encrypted.

Python aiogram exchange REST API SQLAlchemy async PostgreSQL APScheduler
Problem

Consumer AI products rarely die of a missing feature. They die because answers drift after a model update, because a handful of users discover they can make the system say anything, or because the monthly inference bill quietly outgrows the revenue.

Product

Two bilingual assistants with paid tiers: one analyses a conversation and reports tone, balance of initiative and recognised manipulation patterns; the other runs a profiling questionnaire, scheduled content and a standard screening questionnaire, with report export and history.

Engineering

An eval suite sits next to the test suite, so prompt and model changes are checked against expected behaviour instead of judged by reading a few answers. Every message passes a two-tier screen — a cheap model call with a keyword fallback — catching injection in both languages. Per-user daily quotas and global rate limiting keep inference spend bounded.

Python PostgreSQL multi-provider LLM offline STT eval suite rate limiting
Problem

On busy rail routes tickets sell out within minutes of opening, and the seats that actually matter go first. What does become available are returns, appearing unpredictably at any hour.

Product

The service watches for exactly the ticket the user wants — date, route, carriage class, upper or lower berth, specific train — and alerts the moment one appears. The purchase stays with the user by design: it finds tickets, it does not buy them.

Engineering

Browser-driven acquisition against a site with no usable public API, with request throttling and a polling scheduler tuned to stay well-behaved. Matching rules live in their own module and are tested against recorded real-world responses, so a change in the source page fails loudly in tests rather than silently in production.

Python Playwright aiogram async SQLite Docker Compose
Problem

Not every problem deserves a product. Some are small, repetitive and personal — pull the text out of a screenshot, understand a letter in a language you are still learning, justify a conference trip to a manager. Building an app for each is absurd; doing them by hand every week is worse.

Product

Four focused Telegram bots, one job each. A vision bot classifies a photo — screenshot, business letter, chart, slide — and extracts its content accordingly, reading axes and legends where they exist. A translator between Russian and six languages explains the difficult words instead of only replacing them. A European Portuguese tutor returns full conjugation tables and corrects prepositions. The fourth turns a conference URL into a justification memo for a manager.

Engineering

The interesting part is what they share. Each is deliberately small: one model call per task with a strictly expected output, no state beyond user preferences, no framework between the bot and the model. That makes them cheap to run and, more importantly, cheap to abandon — when one stops earning its place, deleting it costs nothing.

aiogram vision models OpenRouter Docker
What we care about

We don't ship wrappers.

Anyone can get a convincing answer out of a model in an afternoon. What decides whether an AI product is still standing six months later is the unglamorous part — and it is where we spend most of our engineering time.

Privacy by design 01

Where the data is sensitive, heavy processing happens on the user's own machine and only a distilled layer crosses the network. Architecture is a stronger privacy guarantee than a policy document promising deletion.

Defensive prompting 02

User input is screened for injection and role-override before it reaches the expensive model, in every language the product supports, with a non-model fallback for when the screen itself fails.

Cost under control 03

Per-user quotas and rate limits are part of the design, not a reaction to an invoice. Inference spend stays predictable as the user base grows, and one user cannot turn your margin into their playground.

Output you can trust 04

Non-deterministic behaviour is tested with eval suites alongside ordinary tests. Green unit tests are not evidence that the model still answers correctly after a provider silently changes it underneath you.

Migrations on live data 05

Schema changes on a populated production database, including irreversible ones, are rehearsed against a copy of real data with a rollback plan written before the change runs.

Owned end to end 06

Architecture, backend, clients, tests, deployment and the operations that follow are one team's problem, not a handover between vendors. Nothing is thrown over a wall, because there is no wall.

How we engage

Three ways in.

Each one starts small enough that you can stop after it without regret.

4–6 weeks · fixed scope

AI MVP

You have an idea and need it in front of real users before committing a roadmap to it.

  • Discovery and scope cut to what matters
  • Working product, deployed and usable
  • Architecture that survives being kept
Monthly · from 3 months

Dedicated product pod

You have a team and a backlog, and need an AI initiative owned end to end without stealing people from it.

  • We join as one unit, not two hires
  • Product decisions and delivery in one loop
  • Fixed days per week, visible progress
1–2 weeks · fixed fee

Architecture & risk review

You already shipped an LLM feature and want to know what it will do under real load and real users.

  • Privacy and data-flow audit
  • Injection, cost and output-drift review
  • Prioritised findings, not a slide deck
Let's talk

Tell us what you're trying to ship.

Thirty minutes, no pitch. We will tell you what we would build first, what we would refuse to build, and whether we are the right pair for it at all.

Usually a reply within one business day · full overlap with Gulf time, four to six hours with CET and WET