Insights
Notes on building digital products in Kazakhstan
Where BBI writes about the practical side of web development, mobile apps, design, AI, and IT consulting — for people making build-or-buy decisions, not for other agencies.
What this page is for
Insights collects the notes we would otherwise repeat on first calls. Each one takes a decision buyers in Almaty and across Kazakhstan actually face — native or browser-first, agency or in-house capacity, which cloud costs to expect at growth — and lays out how we think about it. Nothing here is a pitch. If a note changes how you brief a vendor, it did its job.
Choosing a studio
How buyers should compare studios
The Kazakhstan market mixes web studios, app developers, and full-cycle software companies, and their service lists look similar on paper. The useful difference is what happens after launch: who maintains the code, who owns the infrastructure, and how changes get priced. Bring those three questions to any first call — the answers tell you more than a portfolio page.
- Who maintains the code
- Ask who picks up the work six months in, and whether a retainer or a handover is the norm.
- Who owns the infrastructure
- Domains, cloud accounts, repositories, and analytics should sit in your name from day one.
- How changes get priced
- A clear rate for small changes beats a vague promise that everything is included.
Ask each studio to walk through one project that changed after launch. How the team describes the change — the estimate, the disagreement, the fix — is the clearest signal of what working together would feel like.
Build decisions
When a PWA beats a native app
Progressive web apps and cross-platform builds have changed the default answer for many products. If your users need content, ordering, booking, or an account area, a browser-first build can reach them without app-store friction and with one codebase to maintain. Native still wins when you need device features, offline reliability, or a store presence as part of distribution. We write about how to tell which case you are in.
What that means in practice
A browser-first build usually reaches the first real users in weeks, not months, and updates ship without review queues. A native build costs more to maintain in two codebases but unlocks camera, background sync, and push behaviour that a browser cannot fully match. The deciding question is whether your users need an app-store icon, or whether they just need the service to work on a phone.
Product design
Why UX/UI is a business capability
Interface design is often treated as polish added at the end. In practice it decides whether a checkout completes, whether staff use the internal tool you paid for, and whether support tickets drop. Modern studios treat UX/UI as part of product engineering, not a separate phase. That changes how projects are staffed and how early design starts.
- Design starts with the first workflow question, not the first mockup — screen count follows the process, not the other way around.
- An internal tool that staff actually use is worth more than one with a longer feature list.
- Checkout and onboarding are measured against completion, not against a style guide.
Applied AI
AI in real business workflows
Most useful AI work today is narrow. Document processing, request classification, catalog search, and drafting assistants remove specific manual steps, and they can be tested against real data before launch. The interesting question is not which model is newest. It is which task in your operation is repetitive enough to automate and safe enough to hand over.
How we test it
-
Pick one repetitive task
Not the whole workflow. The single step someone does every day and would gladly stop doing.
-
Run it against your own data
Real documents, real messages, real catalogue. A demo on clean sample files proves very little.
-
Keep a person in the loop
The tool drafts and routes; a colleague approves. Review volume tells you whether it earned its place.
Document processing
Invoices, contracts, and forms read into a structured record so someone stops retyping them.
Request classification
Incoming messages routed to the right queue before a person opens them.
Catalog search
Search that understands what a customer means, not only the exact words they typed.
Drafting assistants
A first version of a reply, a listing, or a summary that a person still reviews.
Systems
CRM and system integration
A new website or app usually exposes a gap: leads arrive, then someone re-types them into a CRM. Integration work closes that gap and is often the highest-return part of a project. Consulting engagements frequently start here, because mapping sales and support workflows reveals what the software should actually do.
- Sales workflow
- A lead lands in the CRM with its source attached, assigned to a person, and visible on the pipeline the same day. Nobody copies an email into a spreadsheet to keep it from being forgotten.
- Support workflow
- A request filed from the app or the site carries its history with it. Support sees what the customer bought, when, and what broke — without asking them to repeat it.
- Reporting
- One view of what came in, what converted, and what stalled. If the numbers live in three systems, someone assembles them by hand every month.
Infrastructure
Cloud, DevOps and backend architecture
Backend decisions are invisible until something breaks or bills spike. Cloud infrastructure, deployment pipelines, and monitoring are part of the build, not an afterthought. For products expecting growth, the architecture question is how the system behaves at ten times the current load, and what it costs to run at that point.
Questions worth asking before launch
- What happens to the queue when traffic triples during a campaign?
- Who gets woken up when a deploy fails at night, and how do they find out?
- Which costs scale with users, and which are fixed whether anyone shows up or not?
Two ways to add people to a project
Companies with an in-house product owner sometimes need capacity, not a vendor. The wrong choice in either direction costs time, so it is worth deciding deliberately before you open a conversation.
Staff augmentation
Engineers or designers on your team
Fits teams that already run a product process and know what they want built. Your backlog, your standups, your priorities. We add capacity and hand over clean work at the end.
Fixed scope
A defined project with an end date
Fits projects with a clear finish line — a new site, a first app release, a migration. Scope, milestones and a price are agreed up front, and the team carries it through to launch.
Reading the market
Reading rankings and directories
B2B marketplaces and rankings help you build a shortlist by service mix and city, and they are a reasonable starting point. They are less useful for judging technical depth, because a listing cannot show how a team handled a migration or a launch deadline. Use directories to filter, then use conversations and case details to decide.
Useful for
Filtering by city, service mix, and rough budget band before you send a single email.
Weak for
Judging how a team handled a hard migration, an outage, or a launch that slipped.
What to do instead
Ask for the project that did not go to plan, then ask what the team changed afterwards.
See how these decisions show up in real projects.
Questions
Common questions
Two things readers ask most often before they write to us.
Do you publish on a schedule?
We add notes when there is something concrete to say about a project decision or a market shift, rather than filling a calendar.
Can we suggest a topic?
Yes. If you are weighing a technical decision, send it and we will consider writing about it.
Almaty · Tbilisi
Bring the decision you are stuck on.
If a note here raises a question about your own project, write to us with the details — what you are building, where it stands, and what you need to decide. We answer on weekdays between 9:00 AM and 6:00 PM.