/Tashkent, Uzbekistan
A software and data engineering studio. We build application backends, warehouses, analytics and AI integration, then handle the deployment and support that keep them running.
/Services
Web applications and APIs built to survive production: schema, service, interface, and the deployment that keeps them online.
Pipelines that turn raw operational data into clean, modelled datasets an analyst can query without asking three questions first.
Dashboards built on a modelled warehouse, so the numbers agree with each other and someone can explain where every one of them came from.
Language-model features wired into products that already exist: retrieval over your own documents, structured extraction, and evaluation that shows whether it actually works.
Containerised deployment, CI/CD, monitoring and backups: the part that decides whether software is still running six months after launch.
/Selected work
A regional newspaper needed a publishing platform its own editors could run. Client project, live since August 2026 and now operated entirely by their team.
Building an end-to-end analytics platform: ingestion from operational sources, layered transformation in PySpark, and a reporting model analysts query directly. Work carried out within Itransition's commercial data engineering programme.
An uptime monitoring product built around the part most teams get wrong: Stripe subscriptions, webhooks and the states in between. Our own product, built to be shown rather than described.
An agricultural marketplace connecting producers and buyers, with a Flutter application for the field, a React console for operations and a NestJS API behind both. Our own build.
First we work out what the system has to do, and just as often, what it must not do. You end up with that in writing: the scope, the constraints we ran into, and the things that worry us. Better to know them before anyone signs.
We start with the data model, because it is the decision hardest to undo later. Code gets rewritten; a database rarely does. Technology is picked against two things: the load it has to carry, and who will look after it once we are gone.
We cut the work into pieces that each end in something you can open and look at. The most uncertain part gets built first, not last. If there is bad news in this project, you want it early.
Short cycles, and at the end of each there is something to show. Tests go where things break quietly: sign-in, permissions, money, dates, background jobs. Those are the failures nobody notices for a week.
The system ships in containers, releases are automated, and the way back is written down before anyone needs it. After deployment we check it from the outside: the certificate, the security headers, whether the real client IP arrives, whether a backup actually restores. None of that can be taken on trust.
After that there are two paths: we keep it running, or your team does. If it is your team, handover is not just the repository. It is the runbook, how credentials are handled, and sitting down to go through the system together. Tong Yulduzi was handed over this way and has been run by their own people since.
/Technologies
/Next step
A short description of the problem is enough to start. You get a written reply with an approach, the rough shape of the work and what it would take. Not a sales call.