Why site builders lose to custom development in the Uzbek market
Site builders are a legitimate tool with specific technical limits — and locally you hit those limits sooner than in global markets.
Where a builder genuinely fits
A landing page for a one-off promotion, an event page, a demand test, a portfolio — anywhere the site lives a few months and does one job. Assembled in days, a few hundred thousand UZS a year.
If the business has not validated its hypothesis, spending 30–60 million on custom development is an expensive way to learn the product was not needed.
Trouble starts not with design but the moment the site has to talk to the rest of your business systems.
Local payments are the first wall
Payme, Click, Uzum Bank and Humo/Uzcard cards need a server side: receiving gateway webhooks, verifying signatures, idempotent handling of repeated notifications, and replying in a prescribed JSON format.
Builders offer Stripe and PayPal; local gateways arrive either through dubious plugins or a payment link with no status callback. The latter means manually reconciling every transaction.
One more detail: Uzcard payments confirm via SMS, and on a slow connection the return-to-site flow needs handling. Inside a closed builder you do not control it.
Multilingual and Uzbek localisation
Two full language versions with correct hreflang, separate URLs and translated structured data usually require duplicating the whole site or a client-side translation script that destroys indexation of the Uzbek version.
Uzbek Latin script with U+02BB and a correct html lang attribute is its own headache. Template platforms know nothing about this script, and on-site search starts misbehaving.
Local formats only sound trivial: masked +998 phone input, UZS amounts without decimals, familiar date order. In custom code that is one formatter; in a builder it is a workaround.
Performance on weak networks
Builders emit generic code: heavy JavaScript, unused CSS, blocking third-party scripts. On office Wi-Fi the difference is invisible; on regional 3G it becomes seconds before first paint.
You do not control critical CSS, LCP image priority, image formats or CDN caching strategy. Optimisation stops where the platform stops.
On a custom stack — Next.js with static generation, WebP and AVIF, deliberate bundle splitting — a sub-megabyte first screen is a choice rather than an accident.
Integrations and data ownership
1C exchange, stock sync, a dealer portal with individual pricing, pushing orders into a manager's Telegram bot — all require server logic and database access. On a closed platform you get whatever API exists, if any.
Data lives on the platform's infrastructure, often outside the country. Where personal data residency matters, that is a legal question in its own right.
Migration exports usually hand back HTML without data structure. Practically, you carry the text over and rebuild the project.
The honest arithmetic
Builder: 300,000 – 2,000,000 UZS a year plus design work. Custom site: 25,000,000 – 80,000,000 UZS once, plus hosting and support. Over two years the builder is almost always cheaper.
What flips the maths is not price but the cost of the limitation. If manual payment reconciliation and retyping orders into 1C consume half a manager's time, custom pays back faster than expected.
The working rule: while the site is a storefront with a contact form, a builder suffices. Once it becomes part of operations, the platform costs more than development would.