Skip to content
Uzbyte
S-07 / Systems & integration design

Systems & integration design

The website sells the last unit twice, because it and 1C count stock separately. We design how the systems talk to each other before the first line of code.

S-07.1Problem

What it looks like today

We run accounting in 1C, electronic invoices in Didox, sales in a CRM, orders in the Uzum seller cabinet, and the warehouse actually works in a Telegram group. The same order is typed four times. When the numbers disagree at month-end, three people spend two days finding out which copy is right.

Every contractor we asked priced “the system” within a week without opening our 1C. The last one built a beautiful admin panel; two years on, nobody can say who changed a price, why the report is off by 3%, or how to add a second branch without breaking the first.

S-07.2Outcomes

What changes in your business

  1. One data model for the whole business: customer, order, invoice, payment and product defined once — the same invoice entered once, not four times

  2. An integration layer instead of point-to-point links: 1C (OData/HTTP), Didox, MyID, e-imzo, Payme/Click and Uzum talk to one API, so swapping the CRM does not mean rewriting the rest

  3. Multi-tenant where you need it: branches, franchisees or client companies share one system with their data sealed at database level by row-level security

  4. An audit log on every write — who changed what, when, before and after — so “who edited the price?” is a filter, not a meeting

  5. Data rules and a residency map: which fields are personal data, which stay on servers in Uzbekistan, which may reach a model provider

  6. A build estimate you can hold any contractor to: modules, integrations, days, risks — usable for our build or your team’s

S-07.3How it works

Three steps, in this order.

  1. 01Step 1

    Systems audit

    A 30-minute call and one day inside your systems. We read the 1C configuration, take a sample export from every source, list every place the same fact is typed twice and talk to the three people who fix the numbers at month-end. Output: a one-page inventory and the questions the sprint must answer.

  2. 02Step 2

    Design sprint: 10 working days

    We draw the data model, the integration layer and the audit log, then run them against your real exports: does yesterday’s 1C sales file load without a manual step, does a Payme callback find its invoice. Reviews with your accountant and 1C programmer on day 5 and day 10. Every decision is written down with its reason, so nobody re-argues it in six months.

  3. 03Step 3

    Build with us or with your team

    The blueprint is yours. We can build the first module as a 30-day pilot and hand it over with a runbook, or your developers build from it and we review their pull requests once a week on a retainer. Either way the design does not depend on us.

S-07.4Deliverables

What you sign off on

  • Systems inventory: every system, its owner, export format and every place the same fact is entered twice (1 page)
  • Data model: entity diagram and table definitions with tenant boundaries and row-level security policies — SQL that runs on Postgres/Supabase
  • Integration map for 1C, Didox, MyID, e-imzo, Payme/Click and Uzum: endpoint, direction, frequency and what happens when each one fails
  • Audit-log specification: what is logged, who can read it, how long it is kept
  • Data rules + residency map: personal-data fields, where they live, what may leave your network (1 page)
  • Architecture decision records: every choice with its reason and the alternative we rejected
  • Build estimate: modules, integrations, days, risks — a scope you can put in front of any contractor
  • Two recorded review sessions with your accountant and 1C programmer (day 5 and day 10)
S-07.5Price

What it costs.

By agreement

Exact quote after the free 30-minute audit.

S-07.6Proof

We run what we build.

  • Fact 01

    One Postgres database for many football schools, row-level security on every table, Payme/Click callbacks and a Telegram Mini App on one data model — the multi-tenant design we draw for you is the one running our own product.

  • Fact 02

    A sporting director’s paperwork — document generation, registrations, foreign-player files — automated on top of an existing platform we do not control: an integration layer around someone else’s system, with every generated document logged. Time saved is published only once measured.

  • Fact 03

    UNDP, February 2026: 57.9% of surveyed Uzbek businesses say they have integrated AI; the barriers they name are finance, compute cost, talent and data governance. The last one is exactly what a system design fixes before the build starts.

S-07.7Questions

Questions we get on the first call.

Can we take the design to another contractor?
Yes, and that is exactly the test. The sprint produces a document that is not tied to us: architecture, data model, integration list, risks and an estimate in days. Hand it to any team and you get comparable quotes. If we build it, the sprint fee comes off the first invoice; if we do not, the document is still yours.
Where will our data be stored? The law says citizens’ personal data must stay in Uzbekistan.
That question is answered in the design, not after launch. The residency map marks every field that is personal data — passport numbers, phone numbers, MyID results — and where it lives: a database in Uzbekistan where the law requires it, foreign cloud only for anonymised or non-personal data, and an explicit list of what may reach a model provider. Your 1C stays your system of record; we integrate with it, we do not copy it wholesale. A lawyer confirms the map; we build to it.
We have 1C 8.3 with custom changes, Didox, Payme, Click and an Uzum cabinet. Can all of that really be connected?
Yes, and the point of the sprint is to decide how before anyone codes. 1C connects through OData or HTTP services — or, if your 1C programmer will not open the API, through the scheduled exports you already make. Didox has an API for e-invoices, Payme and Click send callbacks, Uzum has a seller API for orders and stock. Each goes through one integration layer with its own retry and failure rule, so a Didox outage delays one invoice instead of stopping sales. Your 1C configuration is not rewritten.
How long does it take, and what happens after day 10?
One day of audit, then ten working days — two calendar weeks — with reviews on day 5 and day 10. On day 10 you have the full pack: data model in SQL, integration map, audit-log spec, data rules, decision records and a build estimate. After that, three roads: we build the first module as a 30-day pilot; your developers build from the pack and we review weekly; or you take the pack to another contractor as the tender scope. None of those need us to keep the design alive.
Who owns the design and the code? Can our own developers use it?
You own everything from the day it is paid: diagrams, SQL, decision records, the estimate, and any code we write afterwards. It is written for a developer who has never met us — that is why every decision carries its reason. Nothing is deployed in our accounts; the repository, the database and the bot tokens are registered to your company. Our leverage is being the team that understood the system first, not holding it hostage.
S-07.8Next step

Start with the free 30-minute audit.

Five questions, one call. You leave with the workflow to automate first and a cost estimate.

+ a written plan you keep · We answer within 15 minutes in working hours.