Product development → SaaS and e-commerce development

Product development

We build SaaS, e-commerce, client portals and digital services: product logic, UX, architecture, integrations, analytics and the launch of a first working version.

Discuss your project

Overview

Product development: the service in short

Gotomarket builds SaaS, e-commerce, marketplaces, client portals and internal tools. We start with a coherent user scenario and a business decision, not a detailed backlog. The result is a working product, data to manage it and a system you can safely keep developing.

Formats: SaaS · e-commerce · portals
Start: once value is confirmed
Work: in short iterations
Output: code, environments and documentation

In plain words

What it is and why it matters

What it is: We build the first working version of a digital product — a subscription service, online store or customer portal — and hand it over with code, access and documentation.
Who it is for: An IT company that has already validated the product's value for customers, has someone who owns product decisions, and needs to launch a first version to a limited audience.
What you get: A working product in your company's own code repository, an architecture and data model, required integrations, user analytics, error monitoring, documentation and a post-launch development plan.
Where to start: Tell us where the product stands: an idea, a prototype or a live system. We will identify the main risk and suggest a starting point: validation, prototype or development.

Solution architecture

How we build products with the 5D methodology

Each stage produces a working artifact and lets the product owner change priorities before the whole project is finished.

Discover

Define value and scope

We define the user, the key scenario, product events and the minimum coherent version.

Design

Design the product and architecture

We put together the UX/UI, data model, roles, integrations and the decisions with long-term consequences.

Deploy

Build in iterations

We build the frontend, backend, integrations and automated checks, with regular demos of the result.

Drive

Launch the first version

We prepare test and production environments, analytics, monitoring, support and a limited audience.

Dominate

Grow based on data

We review behavior and errors, update the roadmap and scale the scenarios that work.

Unit economics and ROI

How we manage development economics

The economic effect comes not from coding speed itself but from scope control and early validation of a working result. The team does not pay for the full backlog before it has data from users.

We compare build, integrate and replace: what to develop, what to plug in as a ready-made service and what to replace with a standard platform. This cuts unnecessary cost of ownership and dependence on custom code.

Cost control: coherent scope
Validation: a working result every iteration
Solution: build · integrate · replace
After release: analytics and monitoring

Result

What you get

The product is handed over with access, documentation and an operational setup.

Product scope and roadmap
UX/UI for key scenarios
Architecture and data model
Code in a repository you control
Required API integrations
Test and production environments
Product analytics and monitoring
Documentation and a post-launch development plan

Comparison of approaches

Custom development or a ready-made platform

The choice depends on how unique the business logic is and on the long-term cost of ownership.

Approach	Strength	Limitation	When it fits
Ready-made platform	Fast, standard launch	Limited room for unique logic	A standard process
Integrating services	Combines ready-made features	Depends on external contracts	Several mature components exist
Custom development	Control over core logic	More responsibility for operations	The product creates unique value

Limitations and risks

When not to start development

Code should not compensate for product uncertainty or a missing owner.

The problem and segment are not validated

Start with Product Discovery or a commercial test.

A standard system is enough

If a CMS, CRM or ready-made platform fully solves the problem, custom development is overkill.

No product owner

Without someone who makes product decisions, critical questions pile up on the contractor's side.

A good fit

When this service is a good fit

The key scenario and value are confirmed
The product has a business owner
You need unique logic or several systems working together
The team is ready to launch a limited first version

Not a fit

When to start with a different step

The core hypotheses have not been tested yet
You only need a visual prototype
A ready-made platform does the job
No team will support the product after release

Terms in plain words

Product scope: the agreed boundary of the first version
Product owner: the person who makes decisions about the product
Production environment: the environment where real customers use the product
Build / integrate / replace: develop it, plug in a service or replace it with a ready-made solution
Product event: a user action that helps measure value
MVP: The smallest coherent version of a product that covers one key scenario for a limited audience and provides data for the next decision.
Backlog: The full list of tasks and features a team could build. The first version takes only what the core scenario cannot work without.
Proof of concept: A short technical experiment that checks whether a risky solution is feasible before you invest in full development.

For IT products

MVP, SaaS and web application development for IT products in Kazakhstan

The Gotomarket team in Almaty builds MVPs, SaaS and web applications around one testable user scenario and product events: the first version should produce data for the next decision, not just a set of screens.

SaaS with subscriptions and roles

For SaaS, the first version includes multi-tenancy, roles and permissions, onboarding up to the first useful action, and pricing logic. We tag product events — sign-up, activation, repeat use — so that activation and retention are visible from the very first users. The payment flow is chosen for the market: in Kazakhstan we account for local acquirers and invoicing for legal entities.

Web services and client portals

A web application for clients or partners usually lives next to existing systems: CRM, accounting, a payment gateway. So before development we define which system holds which data and which one is the source of truth. The client account, request statuses, documents and notifications are designed around the client's real questions, not around the database structure.

Mobile app after the web version

If the product needs a mobile client, we first check which scenario really requires a phone: push notifications, camera, geolocation or work on the go. It is often wiser to launch the first version as a responsive web application and add a native or cross-platform client once activation is confirmed. That way the team does not maintain three codebases before there is data.

IT studios and in-house teams

We work with IT studios and in-house development teams alike: we take on the product side, the architecture or a separate track such as integrations and analytics. Repositories, code review, environments and areas of responsibility are agreed in advance. Tasks are tracked in Jira or Plane so the product owner sees progress by iteration, not by reports.

How it works

How MVP and web application development works in practice

MVP development at Gotomarket is a sequence of decisions: what goes into the first version, what is connected off the shelf, how data is stored and which events measure the result. Each decision is captured in an artifact that stays with the company.

Coherent scope instead of a long backlog

We start with one key scenario: who the user is, what task they solve and at what moment they get value. From this scenario we build a map of screens and states, and everything not needed to complete it moves to the roadmap. A typical mistake is a trimmed feature set taken from the full backlog: it has screens, but the user cannot get through to the result. The output of this stage is a product scope document with the boundaries of the first version, the list of product events and the criteria for deciding on further development a few weeks after launch. At this stage we also agree who makes product decisions on the company side and how quickly they answer the team's questions.

Build, integrate or replace for each block

We check every functional block separately: authentication, payments, notifications, CRM, analytics, search. If a block is standard, we connect a ready-made service or an open-source solution — for example Twenty or amoCRM for customer work, Plane or Jira for internal tasks. We write custom code where the logic is unique and creates the product's value. The decision is recorded in a table with reasons, dependencies and maintenance effort, so that a year later it is clear why this path was chosen, and a change of contractor does not require reconstructing the logic from the code. We also assess external service risks: plan terms, API limits, availability from Kazakhstan and data export options.

Architecture and data storage

The data model, roles and permissions are designed before development starts, because reworking them late costs the most. If the product handles personal data of people in Kazakhstan and the client wants to keep it in the country, we choose where the database is hosted, separate personal and anonymized data and document access rights. Backups, logging and the separation of test and production environments are handled separately. The artifact is an architecture diagram and data model handed over together with the code. If the product plans to enter other markets, we design for splitting data storage by region from the start. This is easier than migrating the database once real clients are in it.

Kazakhstan specifics: Kaspi, WhatsApp, two languages

Users in Kazakhstan expect familiar channels and payment methods, so we build them into the scenario from the start. Payment via Kaspi and local acquirers, notifications and support via WhatsApp, and phone-number sign-in are designed as part of the user journey, not as add-ons after launch. The interface, emails and messages are prepared in Russian and Kazakh, and texts are kept separate so that adding a language does not require code changes. For B2B products we keep in mind that the business owner often makes the purchase decision, and give them a simple report on the product's value. For products with an audience outside Kazakhstan we plan an English version and alternative payment methods from the start.

Iterations, demos and product handover

Development runs in short iterations with regular demos of working results on the test environment, not slide decks. The product owner sees progress and can change priorities before the project ends. Automated checks, error monitoring and product analytics are connected before launch so that the first users produce data immediately. The code lives in the company's repository; access and rights are set out in the contract. The output is documentation, deployment instructions and a development plan that let the product be run by an in-house team, another contractor or us. We used the same approach in our own products finspot.kz, salemdom.kz and developers.kz. Before launch we run scenario-based acceptance: we walk the user journey from sign-up to result on the production environment.

Product analytics from the first release

Product events are designed together with the scenario, not after launch: sign-up, first useful action, return visit, inviting a colleague, payment. For each event we describe where it occurs, what properties it carries and which question it answers. The result is a tracking plan that shows activation, retention and funnel bottlenecks. We also connect the product with a CRM, for example Twenty or amoCRM, so that B2B sales can see the path from sign-up to deal and which companies actually use the product. A typical mistake is installing a page view counter and discovering months later that it cannot answer product questions. The artifact is a tracking plan and a dashboard of the first version's key metrics.

How we work

How MVP development works: step by step

From the first meeting to the launch of the first version, MVP development goes through five practical steps. At each step it is clear who takes part on the company side and what document or result remains afterwards.

Free basic diagnostic and kick-off meeting

The first meeting involves the business owner or product owner and, if there is one, the technical lead. We go through the idea, the target user, current systems and constraints: the team, data requirements, launch expectations. We review existing materials such as prototypes, research and code. The output is a short summary with the product's main risk and a recommendation on where to start: discovery, a prototype or building the first version straight away.

Scenario and scope workshop

We run one or several working sessions with the product owner and people who know the clients — sales and support. We describe the key scenario step by step, user roles, data and integrations. Debatable features are split into must-haves for the first version and deferred ones. The output is a scope document, a user journey map and a list of open questions with owners.

Prototype and technical design

The designer builds a clickable prototype of the key scenario while the architect prepares the system diagram, data model and choice of services based on build, integrate or replace. The prototype is shown to the product owner and, where possible, to a few future users. The output is an agreed prototype, an architecture diagram and an iteration plan in Jira or Plane. If the scenario includes Kaspi payments or phone-number sign-in, we check the connection requirements at this step.

Development iterations with demos

The development team works in iterations and at the end of each shows a working result on the test environment. The product owner accepts tasks, changes priorities and answers questions in a shared channel. In parallel we set up analytics, error monitoring and automated checks. Each iteration ends with an updated version on the test environment, a list of accepted tasks and an adjusted plan. The company's technical lead, if there is one, joins code review.

Launch and the first weeks after release

We deploy the production environment, run scenario-based acceptance and launch the product to a limited audience. In the first weeks we review user behavior, errors and support requests together with the product owner. The output is a working product with access and documentation held by the company, a report on early data and an updated roadmap that decides what to develop next and who will run the product.

Ways to work

MVP and SaaS development formats: timelines and outcomes

MVP or SaaS development can start with a short validation, with the first product version or with developing a system that is already live. Timelines are set once the coherent scenario is agreed and technical risks are assessed.

Format	What is included	Timeline	Outcome
Discovery or proof of concept	Key scenario, product scope, technical risk checks, build, integrate or replace decision	A short stage	Agreed first-version scope, list of technical risks and a development plan
MVP development	UX/UI of the key scenario, architecture, frontend and backend, integrations, analytics, monitoring, launch to a limited audience	Based on discovery results	A working first version in production, code in the company's repository, analytics and documentation
Developing an existing product	Review of the current state, roadmap, development iterations, analytics and monitoring setup	In short iterations	An updated roadmap and regular releases of validated scenarios
Separate track or integrations	API integrations with CRM, payments and external services, a client portal or an internal tool	Defined after the diagnostic	Working integrations or a separate module with documentation and monitoring

We choose the right format during a free basic diagnostic that identifies the product's main risk and first step.

Frequently asked questions

SaaS and e-commerce development: questions

Do you only build MVPs?

No. We can launch a first version, develop an existing product or build a separate digital module.

Who owns the code?

Rights, repositories and access are set out in the contract. The company must be able to keep working without depending on a single contractor.

Can our in-house team be involved?

Yes. We agree on roles, code review, repositories and areas of responsibility in advance.

How do you estimate the timeline?

Once the coherent scope and technical risks are defined. When uncertainty is high, we start with a short discovery or proof of concept.

How much does MVP development cost?

The cost depends on the scope of the first version, the number of roles and platforms, the integrations and the data and security requirements. We provide an estimate once a coherent user scenario is agreed and the technical risks are clear. Comparing build, integrate and replace helps avoid paying to develop what can be plugged in ready-made.

What is the difference between an MVP and a full product?

An MVP is the minimal coherent version that covers the key scenario for a limited audience and provides data for the next decision. The full version adds features, roles and scale once value is confirmed. A cut-down set of screens without a working scenario is not an MVP.

How do I choose a development partner for an MVP or SaaS product?

Check whether the partner starts with value, scope and technical risks rather than just estimating a ready-made backlog. The code, repositories and access should belong to your company, results should be shown in regular iterations, and the first version should include analytics, monitoring and documentation. It also helps to agree early on who will support the product after release.

Should we build our own CRM or task management system?

Usually not. If the process is standard, a configured CRM such as Twenty or amoCRM and a task tracker such as Plane or Jira, together with integrations, cover it. Custom development is justified when the logic is unique and itself creates business value, which is exactly what we check when comparing build, integrate and replace.

What happens after the MVP launch?

We analyze user behavior, errors and product events, update the roadmap and scale the scenarios that work. That is why analytics and monitoring are built into the first version. Further development can continue with us, be handed over to your in-house team or be shared between both sides.