Systems & integration design

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

← All services

Who it is for

Companies where the accounting program, the e-document system, a CRM and three spreadsheets each hold a different truth about the same invoice
Uzum sellers and retailers with stock in the accounting program, orders in the marketplace cabinet and payments in Payme/Click that nobody reconciles
Fintech, edtech and service companies that must build identity verification and e-signatures into onboarding and signing
Founders about to commission a platform who want the data model and integrations designed before the build quote
Teams that took over a system from a previous contractor and want to know how it works and who changes what

Problem

We run accounting in one program, electronic invoices in another, sales in a CRM, orders in the Uzum seller cabinet, and the warehouse actually works in a Telegram group.

Your Telegram

✓ 11:20 · arrived

The website and your accounting program show the same stock. Nothing sold twice.

What it looks like today

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.

We do not need one more program. We need the ones we already have to agree: one order, one invoice, one stock figure, and a record of who changed what. And before anyone quotes a build, we want to see how it all fits together — and how to add a second branch later without touching the first.

What changes in your business

One data model for the whole business: customer, order, invoice, payment and product defined once — the same invoice entered once, not four times
An integration layer instead of point-to-point links: the accounting program, the e-document system, identity verification, e-signatures, Payme/Click and Uzum talk to one API, so replacing one system does not mean rewriting the rest
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
A change history on every write — who changed what, when, before and after — so “who edited the price?” is a filter, not a meeting
Data rules and a residency map: which fields are personal data, which stay on servers in Uzbekistan, which may reach a model provider
A build estimate you can hold any contractor to: modules, integrations, days, risks — usable for our build or your team’s

Three steps, in this order.

Step 1
Systems review
A 30-minute call and one day inside your systems. We study how your accounting program is set up, 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.
Step 2
Design sprint: 10 working days
We draw the data model, the integration layer and the change history, then run them against your real exports: does yesterday’s sales file from the accounting program load without a manual step, does a Payme callback find its invoice. Reviews with your accountant and the programmer who looks after your accounting program on day 5 and day 10. Every decision is written down with its reason, so nobody re-argues it in six months.
Step 3
Build with us or with your team
The blueprint is yours. We can build the first module ourselves and hand it over with a runbook, or your developers build from it and we review their pull requests once a week. Either way the design does not depend on us.

What you sign off on

A process map and a module breakdown: what gets built, and in what order
The connections themselves, running between your systems
Integrations with the systems you already use, as far as those systems allow
Documentation and user instructions in plain language
Training for each role on your team

The price depends on the type of application: web, desktop or mobile.

Less than the problem costs you — or we tell you straight.

By agreement

We count what this costs you now — hours, missed customers, errors. The quote comes after, set against that number. The final price is agreed individually with each client.

Questions we get in the first chat.

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, identity-check 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 accounting program 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 already use an accounting program. Can you work with it?

Yes. If you already use an accounting program or any other specialised software, we can integrate with it, provided that system allows integration. Data is then entered once and lands where it is needed. Exactly how it connects is settled in the design, before anyone writes code.

How long does it take, and what happens after day 10?

One day of review, 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, integration map, change-history spec, data rules, decision records and a build estimate. After that, three roads: we build the first module ourselves; 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, the data model, 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.

Contact us.

Describe one process that eats your team's time. We'll tell you what to start with — and what the manual work costs you now.