Zero Panic — Projects

Private Investments Portal

An invite-only investment club where allocating capital, tracking positions, and coordinating with peers all happen inside one platform — not across email threads, PDFs, and spreadsheets.

Members join on an annual subscription with no per-deal fees. Access is by invitation only.

Portfolio construction spans five alternative asset classes:

Private equity
Venture capital
Private credit
Real assets
Hedge funds

When a member finds an opportunity, they allocate directly inside the platform — no side-channel confirmations, no PDF subscription docs passed over email. Positions across all five classes are visible in a single portfolio view: exposure by category, performance over time, concentration risk at a glance. The social layer sits alongside: members comment on specific deals, challenge assumptions, and build investment theses together. Remove that layer and the "club" part stops functioning.

The club also runs a live educational programme:

Monthly thematic deep-dives
Sessions with GPs and founders
Member-led talks
Curated in-person events and trips

Event discovery, registration, and RSVPs all live in the same product — not in a separate Eventbrite link or a pinned message in a group chat.

We partnered with the client's product leadership from day one — designed the architecture, then built feature by feature. The platform launched four months from inception. The client returned for a second engagement.

Next.js Auth0 PostgreSQL TypeScript

Token Bridge for Securities

A bridge between an issuer's permissioned ledger and Ethereum: tokens representing regulated securities are issued, paid for, and redeemed through standard public-blockchain wallets, while control over who can hold them stays with the issuer.

On Ethereum, the token is an ERC-20 contract in which transfers between regular wallets are blocked at the smart-contract level. A token can change hands only when one side of the transfer is the issuer's wallet. The rule is enforced by the network itself, not by a server and not by a database. Each instrument gets its own contract, deployed through a factory and wrapped in an upgradeable proxy — the issuer can change contract logic without changing the address that appears in the legal documentation.

The coordinator service is written in NestJS and reads both systems in parallel. Three flows pass through it:

Issuance — the ledger requests a new contract, the service calls the factory and writes the deployed address back to the ledger.
Distribution — the ledger approves a transfer to an investor, the service mints the tokens and sends them to the address validated against the ledger record.
Subscription and redemption — the investor sends USDC or returns the asset token to the issuer's wallet; the service detects the transfer, matches the sender against the ledger, and records the operation. Unknown senders are rejected.

The service is designed to run unattended for long stretches:

Each Ethereum transaction is tied to an operation id in the ledger. A restart mid-operation does not produce a duplicate mint.
Block scanning is resumable — after a restart the service continues from the last processed block, with no gaps and no duplicates.
Public-RPC behaviour is handled explicitly: retries with back-off, automatic narrowing of the block range on errors, a configurable daily request budget, block-number caching.

Solidity ERC-20 NestJS TypeScript

Telecom

Our team contributed engineering work inside Syniverse projects — one of the world's largest carrier-grade messaging hubs. Syniverse handles over 740 billion text messages a year and connects 300+ mobile operators, underpinning inter-carrier SMS/MMS routing, A2P delivery, roaming settlement, and fraud prevention across most of the world's telecoms. The systems our team worked on run at that scale.

MMS routing modernization — refactored core routing logic in an aging MMS subsystem, improving reliability and maintainability of carrier-level message delivery
SIP messaging performance — diagnosed and resolved throughput bottlenecks in a legacy SIP application handling real-time messaging traffic
SSO integration — wired a third-party identity provider into the auth layer, replacing a brittle in-house authentication flow
Automated SSL certificate rotation — built a service that handles certificate lifecycle end-to-end, eliminating manual renewal toil across distributed infrastructure
Configuration management service — designed a centralized config distribution service for a geographically spread network of machines, replacing ad-hoc per-node management

The stack reflects the carrier-grade telecom domain: MM4 and MM7 for MMS routing layered over SMTP and MIME, SIP for real-time messaging signaling, and a substantial amount of business logic implemented as PL/SQL stored procedures inside Oracle. Around that core sit Java services on Docker and Kubernetes, with Angular powering the internal operations consoles. The hard part isn't the legacy itself — it's introducing modern build, deploy, and operations practices around a system that has to keep routing live traffic through every change.

Java SOAP Docker Kubernetes Angular

Tipse

Tipse is a service for cashless tip payments. We provided full-cycle development services, starting from discovering business requirements, through design and implementation, to production deployment and maintenance — and a full rebrand to the current Tipse identity. Considering the startup nature of the client we came up with a cost-efficient approach, rapid development cycle and quickly delivered the first release.

Hello, we are very grateful to the guys for their work, they are very professional and helped us solve a difficult problem

React GraphQL PostgreSQL TypeScript RedwoodJS DigitalOcean

Order and delivery management for a food business

A system for a company that prepares and delivers healthy meals. It runs the full chain from an order to a delivered package: a manager records the order, the kitchen sees what to cook, the courier gets the route. Within an organisation, staff work under their own accounts, and the system itself serves several branches, each with its own data.

Planning is organised around dates:

Calendar and orders — orders are placed against specific dates, with deliveries one to three days out; a single client can hold several packages at once, kept as one record rather than separate entries.
Kitchen load — the kitchen works from two requests: a preliminary one the day before, for planning, and a final one that fixes the actual volume to cook.
Courier dispatch — once orders are packed, each courier gets a route list of packages and delivery points; for any date, a manager can see what is leaving and for whom.

Access is split across five roles, each scoped to what it needs:

Organisation administrator — creates branches, manages their administrators, and controls access across all of them.
Branch administrator — invites managers, kitchen and courier accounts, and maintains the product catalogue.
Manager — keeps the client base (contacts, addresses, order and request history) and forms the production and delivery requests.
Kitchen — sees the preliminary and final requests, and nothing else.
Courier — sees only the route assigned to them.

The work was less about any one feature than about keeping orders, kitchen, and delivery in step — so no one has to re-enter the same data by hand.

Firebase Angular TypeScript

Our Process Overview

We start from what's already clear — and build from there.

"We look for whatever clarity already exists — however small. There's always something the client is confident about: a piece of functionality, a workflow, an expected output. That's our anchor." — Michael Musatov

Each engagement runs in cycles. The scope of each cycle is fixed before work begins:

First conversation — we map goals and constraints: budget, deadlines, stack. We check whether expectations match before committing to anything.
Scope and estimate — we define the smallest meaningful unit of work: an MVP, a proof of concept, or a scoped feature. Fixed price, fixed timeline — the commitment is ours.
Delivery — design, development, deploy, testing. Iterations stay inside the agreed scope; no silent expansion, no surprises at handoff.
Review and adapt — after delivery, an honest look at real outcomes. Together we decide what comes next: refine, expand, or change direction.
Next cycle — if we continue: new scope, new estimate. Fixed bid or time & material, chosen based on how well the work is defined.

A few things that don't change between cycles:

Partnership — we work toward a long-term relationship, not a series of one-off transactions.
People — a stable team environment is what produces consistent quality; we protect it.
Honesty — a hard truth is more useful than a comfortable estimate.
Quality — cutting corners now costs more later; we've seen it enough times to stop doing it.
Reliability — we commit only to what we can actually deliver.

A note on these projects

Some of the work our team has built over the last several years. Different domains — telecom, fintech, insurance, blockchain, food production and delivery — corporates and startups alike. Different stacks: Java and .NET on the backend, Angular and React on the interface side, Next.js or RoR when speed to market matters.

Technology choice usually follows the client: what already runs, what will be cheaper to maintain going forward. The stack is rarely the most important part of the work — it matters more that the team grasps the problem quickly and can make well-reasoned decisions.

We keep up with the times. AI tooling in the hands of a senior team genuinely raises productivity: boilerplate gets generated by the machine, and the team's attention shifts toward specifications, technical design, and code review.

Get in touch — we'll go into detail and show you how it all works.

telegram hello@zeropanic.ru

We do