Danil Tyumentsev

Problem

The key product risk is not competition but external constraints: addresses and protocols fail without warning, while the user must not have to reconfigure anything. A separate difficulty is keeping a single stable link on the client side through a complete change of internal configuration.

Approach

A “one link, interchangeable profiles” architecture: the subscription serves configuration dynamically, so switching protocol or site requires nothing from the user. Several independent transports run in parallel, so the failure of one does not mean the failure of the service. Changes to the live system are rolled out in stages, with a backup and a configuration check before any restart.

Outcome

The service survived several waves of blocking without migrating users to new links. This produced a management practice later carried over to the other products: reversible changes, a rollback window, and a pre-restart check as a mandatory part of every release.

Problem

Without consumption accounting you can neither price a plan nor tell when capacity will run out. Yet the data source is a set of network services that report statistics inconsistently, and some counters stay silent because of configuration.

Approach

A regular one-minute metric collection loop with a dedicated history store. Discrepancies were traced to root cause rather than papered over: some of the “zeros” turned out to be incomplete provisioning, not absence of traffic. The gaps found were written up as prioritised operational defects.

Outcome

A factual basis for pricing and capacity planning replaced eyeball estimates. A separate class of defects was documented: cases where the system shows plausible but wrong numbers — more dangerous than an outright failure.

Problem

A foreign-currency catalogue with rouble revenue is a pricing problem, not an interface one. The conversion rate turned out to be hard-coded and had drifted from the market by roughly a quarter: the customer price was inflated, and the live rate source was unreachable from the server.

Approach

The defect was framed as a management issue rather than a technical one: what it costs the customer and the seller, and why the inverted price bands make some plans structurally unprofitable. The product was moved to its own domain and database with a full data migration and a sign-in check before cutover.

Outcome

The migration completed without data loss or downtime for buyers. The pricing defect was escalated as a separate decision with an impact estimate — a clear case of a single constant costing more than a month of product work.

Problem

Payment is confirmed by a webhook from an external provider. If the application is unavailable at that moment the notification is lost, and the deal stays permanently unpaid in the system while the money has in fact arrived. For a sales process that costs more than interface downtime.

Approach

Payment handling was rebuilt around an outbox pattern: receiving the webhook is separated from processing it, and redelivery does not create duplicate deals. An admin view surfaces any divergence between the provider’s status and ours.

Outcome

Payment stopped depending on whether the service happened to be up at a given second. This produced a principle later applied to every other payment integration: store the external event first, process it second.

Problem

Every extra second and extra screen when logging an expense lowers the odds the entry is made at all. The classic “amount — category — date” form loses to a single spoken sentence.

Approach

Input was reduced to a single message: a short phrase or a voice note from which amount, category and comment are extracted. Voice processing runs server-side so as not to depend on the phone’s capabilities.

Outcome

Input stopped being the barrier: logging an entry takes less time than opening an app. The product doubles as a testbed for retention hypotheses before they are moved into the paid services.

Problem

An unlimited subscription is impossible here: every clip consumes machine time and external calls. The classic “pay monthly, use as much as you like” model with such a product reliably turns heavy users into losses.

Approach

The pricing model was split: publishing and scheduling are unlimited, generation is what you pay for. Per-clip cost was calculated and used to size the render farm needed for the declared volume. Launch is deliberately held until a list of blocking conditions is closed rather than fixed to a calendar date.

Outcome

There is a pricing grid derived from calculation rather than from competitors’ prices, and an explicit list of launch conditions. A deliberate delay is a management decision too: shipping a negative-margin product costs more than waiting.

Problem

Data collection depends on third-party sites: they change markup and add anti-automation defences without notice. A working collector at some point started returning nothing — with the application itself entirely healthy.

Approach

The accumulated posting dataset was preserved and analysed to separate the product conclusion from the technical failure. Development was paused deliberately: maintaining collection requires continuous investment, and demand for alerts fell below the break-even threshold.

Outcome

A dataset of 8,659 postings was collected and analysed as a basis for market assessment. Resources were redirected to products with confirmed payment. Closing a line of work on time is part of portfolio management, not a sign of failure.

Problem

Working with an external issuer, the state in our database and the state at the issuer diverge: applications remain for which no card was actually issued, and vice versa. The divergence surfaces only on explicit reconciliation, never in the interface.

Approach

A reconciliation procedure with the issuer was introduced, real card-state indicators were surfaced in the lists, and the “ghost cards” found were collected into a separate register. Fund write-offs and card closures happen only after explicit owner approval — irreversible operations are not automated.

Outcome

The first card was issued and taken through the full lifecycle. The handling of irreversible operations was fixed as a rule: first the register and the assessment, then approval, and only then execution.

Problem

The products grew separately, each with its own database of live users. The obvious solution — merging everything into one shared database — would create tight coupling: a schema change in one product would break the others, and a mistake in the panel would hit everyone at once.

Approach

The inverse architecture was chosen: the panel keeps a small database only for what belongs to it (operators, audit log, tickets, identity mapping), while product data is read through their narrow internal interfaces. Each product decides what to expose — least privilege. Operator access uses two-factor authentication and role separation.

Outcome

A panel outage does not take the products down, and a product schema change does not require changing the panel. The architectural decision was made before any code was written and documented together with the rationale for rejecting the alternative.

Problem

A dedicated server per site is a recurring cost that creates no value. But co-hosting has its own price: the shared port entry point must route traffic correctly, or a single new domain breaks all the others at once.

Approach

Domain-name routing is configured so that adding a site is an isolated change with a configuration check before it is applied and a rollback path. Some content is separated by domain inside a single application — where standing up a separate service would cost more than it is worth.

Outcome

Around fourteen domains run on a single server, and infrastructure cost does not grow linearly with the number of projects. Adding a domain became a repeatable procedure rather than a one-off feat.