Sberautopodpiska — Case Study

Car-subscription platform for SberAuto, built from scratch and shipped to production in three months.

Summary

Sberautopodpiska is the consumer-facing car subscription service inside Sber's auto-mobility ecosystem — customers pick a car and pay a monthly fee for 6 to 36 months instead of financing a purchase. topsweteam built the platform end-to-end: architecture, backend, frontend, and the integration surface into Sber's internal systems. A three-person team took the project from empty repo to a production release in three months, then continued to expand scope as the product grew.

• Client: Sber (Sberautopodpiska)
• Industry: Mobility / Fintech
• Engagement: Full build-out from scratch in 2021; continued post-launch development until handoff in 2023
• Timeline: Three months from kickoff to production launch in 2021; full handoff to Sber in 2023
• Team: 3 engineers at launch, scaled with new features
• Status: Shipped to production; fully handed off to internal Sber teams in 2023

Challenge

The product had a firm launch window tied to a Sber ecosystem event, a standing expectation that it would integrate cleanly with the rest of Sber's services, and no existing codebase to start from. The team had to ship a full consumer platform — public web, checkout flow, fleet/contract domain, operational tooling — in the time most projects take just to agree on an architecture.

Approach

We picked a microservices architecture from day one rather than starting with a monolith and extracting later. The rationale was specific to Sber: several bounded contexts (catalog, contracts, billing, fleet) already had clear owners across the organization and would inevitably be owned by different teams post-launch. Building them as separate services from the start made the eventual handover and co-ownership cheaper.

• Java/Spring for the core domain. Contracts, billing, and the fleet model live in strongly typed services where the JVM's maturity and Spring's ergonomics around transactions paid off.
• Python for the surrounding services. Integrations, scraping, and admin tooling were faster to build in Python — FastAPI where we needed an HTTP API, Django where we wanted the batteries-included admin.
• Graylog from day one. With microservices you pay the observability tax up front or pay it under incident pressure later. We chose the former.

Solution

The production platform combines a React/TypeScript storefront (using Strapi as the content layer for non-engineers to manage offers and car lineup), a JVM core for domain logic and contract state, and a cluster of Python services for integrations and internal tools. PostgreSQL handles the transactional store; Kubernetes runs everything. The first production release covered the full customer journey end-to-end: catalog browsing, configuration, signup, contract generation, and a working admin for operations.

Architecture

A handful of JVM services own the core domain (customer, vehicle, contract, subscription lifecycle). Python services sit at the edges — partner integrations, document generation, operational dashboards, back-office batch jobs. Everything communicates over HTTP within the cluster. Postgres is the system of record; Graylog aggregates logs; Kubernetes handles scheduling and rollouts.

Key features shipped

• Public storefront with car catalog, subscription configurator, and online signup
• Contract generation and subscription lifecycle (activation, renewal, cancellation, swap)
• Admin panel for operations to manage inventory, offers, and customer support
• Integrations with Sber's identity and payment stack

Outcome

The platform went live in 2021 inside the promised three-month window. Customer signups, contract processing, and operations moved onto the new stack on launch day. topsweteam continued to build on the platform after launch and fully handed it off to internal Sber teams in 2023. The service runs as part of Sber's broader auto ecosystem.

• Three months from empty repo to production launch (2021)
• Microservices architecture that survived the post-launch handover to internal Sber teams (2023)
• Full customer journey (browse → subscribe → manage) shipped in the first release
• Clean handoff after two years of co-development with Sber

Tech stack

Infrastructure: PostgreSQL, Docker, Kubernetes, Graylog Backend: Java 14 (Spring, Hibernate), Python 3.8 (FastAPI, Django) Frontend: React, TypeScript, Strapi Data / integrations: Sber identity, Sber payments CI / ops: Kubernetes-native deploy pipeline; centralized logging via Graylog

What we learned

• Microservices on day one paid off because the bounded contexts mapped to real organizational boundaries. The same call on a smaller or more uniformly-owned project would have been premature.
• Polyglot backends are cheap when they map to team skill, not fashion. Java for contracts, Python for integrations — each team shipped faster than they would have in a single language.
• Three months is enough for an MVP with the right constraints: fixed architecture, no scope negotiation, operations tooling treated as day-one work rather than an afterthought.