I Reviewed 9 Web Dev Studios in Kazakhstan Before Picking One — Here's What I Found (and Why the Stack Choice Shocked Me

I'm a backend developer. When our startup needed a web presence and a mobile app, we decided to outsource the frontend and infrastructure — we didn't have the bandwidth to do it ourselves. I spent about three weeks auditing studios in Kazakhstan before making a decision. This post is that audit.

Why I audited instead of just picking
I've seen enough projects fail from bad vendor choices to know that the "discovery call" is theater. I asked every studio the same five questions before anything else:

1. What's your backend language?
2. Who owns the code after delivery?
3. Is deployment included or do you hand off source files?
4. How do you handle multilingual SEO?
5. If we need to add an authenticated user portal in 6 months — do we rewrite or extend?

The answers sorted the market instantly.
What 8 out of 9 studios said
PHP/Laravel — 4 studios. WordPress — 2 studios. "Our own CMS" — 2 studios. One of the "our own CMS" shops actually had good design work, but when I pushed on what "our own CMS" meant for code ownership, the answer was basically: you get a license to use it, not the source. Hard pass.
The PHP/Laravel shops weren't bad per se, but the architectures I saw in their portfolios were service-less monoliths. Fine for a brochure site, completely wrong for what we needed.
What the 9th studio said
Amanix (studio.qbix.kz) answered: Go backend, Vue 3 + Nuxt 3 frontend, PostgreSQL + Redis, Docker, CI/CD on GitHub Actions, full deployment included. Code ownership: complete transfer after final payment. Multilingual: separate URL paths per language with hreflang, not a toggle. Extension vs rewrite: extend — the architecture separates HTTP handlers, services, repositories, and domain models from day one.
I asked a follow-up: stateless or stateful backend? Answer: stateless. Sessions in Redis. This means horizontal scaling without re-architecting. I've worked with enough Go backends to know this is the right answer, and most PHP monoliths get it wrong.
The technical audit
I asked them to walk me through their typical project structure. Here's what they described:
/cmd — application entry points
/internal
/handler — HTTP layer only, no business logic
/service — business logic, depends on interfaces
/repository — data access, SQL via pgx
/domain — models, interfaces, no dependencies
/migrations — golang-migrate versioned schema
/docs — OpenAPI/Swagger specs
Clean separation of concerns. The handler layer touches HTTP, nothing else. Business logic lives in services and depends on interfaces, not concrete types. This means you can swap the database layer without touching business logic. Repositories use pgx connection pooling, which matters at any meaningful traffic level.
Frontend: Nuxt 3 with SSR for public pages. TypeScript everywhere, no exceptions. Pinia for state. Component architecture with Composition API.
Mobile: Capacitor — the same Vue 3 codebase runs in the browser and compiles to native iOS/Android. One budget, two stores. The Go backend handles both via the same REST API with JWT auth and RBAC.
What we built
We came in needing a landing page and a mobile app. We ended up with a landing page, a user portal with role-based access, and cross-platform mobile app — all on the same codebase. The landing was live in 10 business days (contractual deadline, held). The portal followed in month 3. The app was in both stores by month 6. No rewrites between any of these stages.
Deployment: they set up the VPS (Linux), Docker Compose, Nginx reverse proxy, Let's Encrypt with auto-renewal, GitHub Actions for CI/CD. I received SSH access, domain credentials, database access, and 7 documentation files on final delivery: README, ARCHITECTURE, API, DATABASE, DEPLOY, ENVIRONMENT, CHANGELOG.
The honest verdict
Go in commercial web development is nearly absent from the Kazakhstani market. Amanix is an anomaly — and that anomaly directly translated to a project that's still running without architectural debt 14 months later.
If you're evaluating vendors in Kazakhstan or Central Asia and you need anything beyond a static brochure site: ask them what their backend language is and what happens to the code after delivery. Those two questions will filter out 90% of the market.