A lawyer explained why an IT startup needs a public offer and what it should contain

Petr Zhizhin, city — Astana, founder of Zhizhin Legal Studio, registered legal consultant in the Republic of Kazakhstan, registered legal advisor at the AIFC, author of the Telegram channel Zero Bullshit Law, LinkedIn

About me 

I am the founder of Zhizhin Legal Studio, an AIFC Legal Advisor, a legal consultant in the Republic of Kazakhstan, a member of YIMA and Compliance Hub, and the author of the Zero Bullshit Law channel. 

At the stage of launching an IT product, I often see the same situation: legal documentation rarely ranks among the founder’s priority tasks. The team’s main resources are directed toward testing hypotheses, refining the code, attracting the first users, and finding a sustainable business model. During this period, the legal framework of the project is often postponed or assembled on a residual basis.

Such an approach is understandable at the start. However, as the scale of the business grows and the volume of transactions increases, I see how poorly prepared documents begin to create systemic risks — from financial claims by users to sanctions from tax and financial regulatory authorities.

How it usually looks

At the minimum viable product (MVP) stage or in areas with low levels of legal regulation, teams often copy documents from a competitor with a similar model or generate basic text using language models. For the first dozens of users or when testing hypotheses, this approach really does help save resources. However, when moving to active sales, I recommend building a correct system of documents, clearly understanding the function of each:

— public offer. It is an offer addressed to an indefinite circle of persons to conclude a contract on the terms specified in it. This is the main document regulating commercial relations between the service owner and the buyer or user.

— User Agreement / Terms of Use / Terms of Service. Regulates the rules of interaction with the service functionality, the procedure for creating and blocking accounts, content posting rules, and acceptable usage scenarios. In SaaS products, the User Agreement is often combined with the public offer into a single document.

— Privacy Policy. A standalone document describing the procedures for collecting, storing, processing, modifying, and deleting users’ personal data. Due to legislative requirements on personal data, this document must be separated from the offer.

— Refund Policy. Regulates the conditions and procedure for refunding funds when services are rejected. This section can be moved to a separate document for user navigation convenience or included directly in the text of the public offer.

Why an IT product needs a public offer

In my practice, I view a well-drafted public offer not only as a tool for legal protection. It also helps optimize the company’s operational processes.

The main legal tool for interacting with the user. In mass-market IT products, signing individual contracts in paper form is economically impractical. Therefore, the public offer becomes the main legal foundation determining the settlement procedure, auto-debit conditions, contract termination procedure, and the boundaries of liability of the parties.

Reducing the load on the support service. In practice, I often see that a significant part of user inquiries to technical support is related to questions about the procedure for deducting funds, subscription cancellation conditions, refund rules for incomplete usage periods, and access provision procedures. Transparent and logically presented conditions in the offer allow the support service to quickly refer to specific points of the document and prevent conflict escalation.

An element of user experience and trust in the brand. According to my observations, investors and large clients evaluate product quality partly by the degree of elaboration of legal documentation. Modern contract drafting practices actively incorporate Legal Design principles: using structured headings, brief summarizing explanations before complex blocks, understandable terminology, and the absence of excessive bureaucratic jargon.

What is important to provide for

When preparing the document, I pay attention to sections where errors most often lead to losses or legal disputes.

Subject of the contract and qualification of the business model. I always start with the correct qualification of the subject of the contract, as its formulation determines the legal nature of the relations and directly affects the company’s tax obligations. An error in qualifying the subject can lead to incorrect recognition of income and additional tax assessments. For example, it is important to clearly distinguish between the transfer of rights to use software, providing information and consulting services, an agency model, or performing development work.

For participants in the special tax regime of Astana Hub, I especially recommend carefully approaching the definition of the subject of the offer. If the formulation of the subject in the offer is interpreted by tax authorities or the hub administration as providing services not included in the list of priority activities, for example, marketing or standard agency services instead of providing access to proprietary software, the company risks losing tax preferences with subsequent tax reassessments and penalty sanctions for the entire period of applying the benefits.

Separation of liability and legal status of the product. I recommend clearly fixing the status of the service and its functional boundaries so that the user does not have exaggerated or incorrect expectations. This is especially relevant for technological services in the fields of finance, medicine, and education.

For example, if a FinTech product provides users with a software interface for data aggregation or calculation automation, I recommend explicitly stating in the offer that the service is exclusively a technological solution and does not provide banking, brokerage, or payment services. The absence of such a distinction creates a risk of qualifying the service’s activities as unlicensed financial activity, which under the legislation of the Republic of Kazakhstan entails administrative or criminal liability, as well as the blocking of resources.

The same applies to EdTech products: I recommend clearly distinguishing between providing access to informational materials and providing educational services that require obtaining a license or accreditation.

Settlement procedure, subscription, and auto-debit / Recurrent Payments. If the business model involves recurring payments, I recommend describing in detail in the offer:
— frequency and amount of debits
— the procedure for notifying the user about the upcoming debit
— the system’s algorithm in case of insufficient funds on the user’s card — the number of re-debit attempts, the period of suspension of access to the service
— a clear procedure and deadlines for canceling the subscription before the next debit.

From my experience, insufficient elaboration of this block often leads to mass user inquiries to banks with requests to dispute transactions, which threatens higher commissions from the acquirer or disconnection of the payment gateway.

Intellectual property rights and restrictions / Acceptable Use Policy. I recommend explicitly fixing in the document that the user is granted a limited, non-exclusive, revocable license to use the service without the right to transfer it to third parties.

I also recommend explicitly prohibiting:
— decompilation, reverse engineering, and attempts to obtain source code
— the use of automated scripts to collect information from the service
— bypassing technical restrictions and protection systems
— resale of account access or sublicensing.

Procedure for changing the terms of the offer. Since the IT product is constantly evolving, I advise building a transparent mechanism for making changes into the offer in advance. It is important to fix the procedure for notifying users about the new edition: through publication on the website, email newsletter, or notification in the personal account, as well as the period during which continued use of the service is considered consent to the new terms.

Dispute resolution and applicable law. I separately draw attention to the applicable law and the procedure for resolving disputes. When working with individuals within the Republic of Kazakhstan, the ability to choose jurisdiction is limited by consumer protection legislation. However, when entering the international market or working in the B2B segment, determining the applicable law, jurisdiction, or arbitration clause becomes the main means of protection against lawsuits in a foreign jurisdiction.

Procedure for accepting the offer and fixing user consent

In order for the public offer to have legal force and be used as evidence in court or when reviewing complaints, I recommend thinking through the correct procedure for its acceptance in advance — that is, actions confirming the user’s consent to the terms.

Methods of acceptance. I do not recommend limiting yourself to simply publishing the text of the offer at the bottom of the web page. It is better to fix user consent through an explicit targeted action:

— placing a mark in a checkbox with the phrase “I accept the terms of the public offer” during the registration form or before proceeding to payment
— making a payment if the payment form explicitly states that by clicking the “Pay” button, the user expresses consent to the offer.

Fixing the fact of acceptance. In the event of a dispute, the service owner will need to prove the fact of the user’s acquaintance with and consent to the offer. Therefore, I recommend that the software architecture of the product ensure the saving in the database of the following parameters:

— user identifier: User ID, e-mail, or phone number
— exact time and date of the action: Timestamp
— IP address from which the action was performed
— unique identifier or direct link to the specific edition of the offer that was in effect at the moment of acceptance.

Conclusion

For me, the public offer in an IT product is not a formality or a “for later” document, but part of the business architecture itself. It should reflect the real business model, payment scenarios, liability boundaries, and user journey. Therefore, I advise building it simultaneously with the product: the earlier these elements are synchronized, the easier it is for the company to scale, reduce legal and operational risks, and build transparent relationships with users.