Your own software or vendor lock-in: why companies are changing their approach

Every business runs on software it did not write. That is normal: no one builds their own email client or spreadsheet. The problem starts when the systems your core processes depend on belong entirely to someone else: their pricing, their roadmap, their terms of service, their decision about where your data lives.

This is not a reason to panic or to rebuild everything in-house. But it is worth being clear-eyed about what it means to depend on infrastructure you do not control, and where that dependence quietly turns into a business risk.

Why vendor independence is on the agenda

For years the default playbook was simple: pick the best cloud product for the task, pay a subscription, and get to work. A CRM here, an accounting system there, a handful of point solutions glued together. It works, right up until it does not.

Subscription prices climb. A vendor sunsets the plan you rely on, or buys a competitor and changes the rules. An acquisition shifts the roadmap away from your use case. A foreign service restricts access in the region, changes how you can pay, or prices in foreign currency, so a budget planned in tenge starts to depend on the exchange rate. None of these are catastrophes on their own, but together they describe a single condition: vendor lock-in. The deeper a system sits in your operations, the harder and more expensive it is to leave.

For companies in Kazakhstan there is also the question of data: the law requires personal data to be stored in a database located in the country, and a cloud service with servers abroad can turn a routine workflow into a legal question. So "which parts of our stack do we actually control, and which could change under us without our say?" has moved from theory to a practical question in every system choice.

The three types of risk that lock-in creates

Operational risk

A vendor can deprecate a feature, raise limits, or change an API at any time. Processes tied to that system stall or degrade. The more tightly integrated it is, the more painful the disruption, and the longer the migration if you ever decide to move. The same applies to marketplaces: if all your sales go through one platform, its rules and commissions become your rules.

Legal and compliance risk

Personal data is stored in a database located in Kazakhstan (Law of the Republic of Kazakhstan No. 94-V of 21 May 2013 On Personal Data and Their Protection, Article 12(2), text on adilet.zan.kz). The company collecting the data remains responsible for this even when a third party processes it. If your CRM, email or mailing service stores customer data abroad, that is a cross-border transfer, and it has to be stated in the customer's consent. What this means for a website and lead forms is covered in our personal data guide.

Strategic risk

A company whose key processes live on someone else's platform inherits that vendor's pricing policy, terms of use and strategic decisions. Price hikes, licence changes, the discontinuation of a version: all of it affects your business without your involvement in the decision.

How depending on many scattered services holds back growth, and how to bring a business into a single system, is covered in from scattered services to one system.

Where lock-in shows up most often

A few typical places where companies become dependent without noticing:

• A cloud CRM. The customer base, deal history and correspondence live with the vendor. Find out where the servers are, and check that you can export the whole database with its history, not just a contact list.
• Selling only through a marketplace. Product listings, reviews and order history stay on the platform. If the rules or the commission change, you see it in your margin at once, and you have no channel of your own to the buyer.
• A website on a site builder. Convenient at the start, but the code and design belong to the platform, and moving to other hosting often means rebuilding the site.
• Undocumented 1C customisations. The database is yours, but if only one specialist knows the changes, you now depend on that person.
• A WhatsApp chatbot run through a contractor. The number, the message templates and the account with the API provider should be registered to your company; otherwise a change of contractor means rebuilding the channel.

None of these is a reason to drop everything. It is a list of questions worth asking before a system becomes irreplaceable.

What "your own software" actually means

Owning your software does not mean writing everything from scratch or refusing every external tool. It means keeping control over the critical elements of your digital infrastructure, and choosing where you accept lock-in deliberately rather than by accident.

Systems built around your processes

CRM, accounting and operations systems written around how your company actually works, deployed on infrastructure you choose, owned by you. No dependence on a third party's terms, and data stored where you decide, including on a server in Kazakhstan. Connections to 1C, Kaspi and the ESF e-invoicing system are built around your process, not around another service's limits.

Mobile apps and web platforms

Your own channel to customers: a product that belongs to you rather than a rented slice of someone else's service or marketplace. Push notifications, loyalty, customer accounts: all working on your terms, and staying with you if you change suppliers.

Open standards and data portability

Favour systems with documented APIs and clean export formats. The ability to take your data and integrations elsewhere is what turns "lock-in" back into "a choice". This applies to ready-made products too: some offer a version you can run on your own server, others are cloud-only. Before you buy, ask how to export all of your data.

Reducing dependence without the pain

The worst approach is replacing everything at once. It is expensive, slow and risky for processes that are working fine today.

The right approach is prioritisation by risk. Start with what creates the greatest dependence or legal exposure right now, and move step by step.

Step 1. Audit your dependencies

Map every system the business relies on. For each one ask: where is the data stored, who owns the system, what happens if the price doubles or the vendor changes direction, can the data be exported in full. That gives you a real risk picture instead of a gut feeling.

Step 2. Classify by criticality

Not every system matters equally. A CRM holding your customer base is critical. A video-conferencing tool can be swapped in a day. Prioritise the systems your key processes depend on and the ones holding personal data.

Step 3. Replace, migrate or build your own

Some systems have strong off-the-shelf alternatives with better terms or data storage in Kazakhstan. For unique processes that no product covers well, custom development tailored to your requirements, deployed where you control it, is often the most durable answer. How to choose between a ready product and development is covered in off-the-shelf vs. custom, and whether you need a full ERP in why a full ERP when you need only part of it.

How not to end up locked in to your developer

Your own system protects you from lock-in only if it is really yours. Otherwise you swap dependence on a cloud service for dependence on a studio that keeps the code and the server to itself. Check the development contract for these points:

• the source code and repository are handed over to you, not kept by the vendor;
• the server, domain and paid services are registered to your company, not to the contractor;
• there is deployment documentation so another team can pick up the work;
• all credentials (admin panels, databases, app stores, payment accounts) are with you;
• the warranty on the delivered scope is written into the contract with a clear term.

This is exactly how we work: the price is fixed in the contract, a six-month warranty applies, and the code and credentials stay with the client. After the warranty, the system can stay with us for support and maintenance or move to your own team.

What the business gets in the end

Vendor independence is not an abstract idea; it is a set of concrete, practical advantages:

• customer and process data sits where you decide, which makes the requirement to store personal data in Kazakhstan easier to meet and to demonstrate;
• core processes no longer hinge on a single vendor's market or pricing decisions;
• systems you own adapt to the business instead of forcing the business to fit a platform;
• a transparent cost of ownership, without surprise licence hikes;
• a competitive edge: your unique processes are automated the way you need, not the way a product permits.

That said, honesty matters: owning your software is not a cure-all or a goal in itself. Where a mature product covers the task well and offers fair terms, there is no point reinventing it. The aim is to minimise critical dependencies, not to isolate yourself from every external tool.