Skip to content
Mikhail Skarakhodau
Home

Startupa client from Belarus, a global product

A startup: from an idea to a product and a team

The investors had an idea and money; I built the product, the team and a working application out of it.

Book a conversation

12

people in a team built from zero

3

months to the MVP

99.99 %

availability of the application

01

The situation

The investors had put money into the idea of an application for algorithmic trading and for learning to trade. There was an idea and there was money. There was no product, no team, no plan. I was hired as the person responsible for the whole IT side, in the role of solution architect and tech lead. That meant the idea had to be turned into something concrete first, and only then could we settle who would build it and on what.

02

What I did

The product

I developed the investors' idea into a concrete product: what the application does, who it is for and what it is made of, described precisely enough to be built.

EffectInstead of an idea there was a description of the product, and against it the work could be planned and the people chosen.

IdeaProduct

Infrastructure and documentation

I turned the product idea and the requirements into IT documentation — the architecture, the infrastructure and the order of the work — before the first line of code.

EffectThe team started from finished documents, and from the first day the application grew on a planned infrastructure instead of on stopgap decisions.

Before the first line of codeIdeaRequirementsDocumentation

The team: developers and a designer

I hired 12 people from zero: developers and a designer. I wrote the roles, ran the interviews and brought the new people into the work.

EffectThe product was built by a team of its own, with roles and responsibilities settled from the start.

developersa designer

Requirements and standards

I gathered the requirements, set the standards of work, ran the code reviews myself and put in CI/CD pipelines: every change tested and deployed automatically.

EffectEveryone worked to one standard, mistakes came out at review, and only tested changes reached the application.

RequirementsStandardsCode reviewCI/CD pipelines

The MVP and six months of development

I brought the application to an MVP three months after the work began, and for the next six months I developed it and ran its support: new features, fixes and keeping it running.

Effect99.99 % availability, no serious incidents, regular releases of new features.

months123456789MVPDevelopment and support

A team that stands on its own

I set up the processes inside the team and brought it to self-sufficiency.

EffectFrom then on the team maintained and developed the product itself.

MaintenanceTeamDevelopment
03

The effect

The application served thousands of users at 99.99 % availability, with no major bug and not a single outage. In the same period similar projects on the market, with poor architecture and a badly planned application, were broken into through unprotected entry points; ours, despite the suspicious attempts detected, held everything thanks to an infrastructure planned in advance. The IT side succeeded in full: out of a vision came a product, and out of nothing a team that serves it.

05

Contact

Write

I reply within two working days.

The first conversation costs nothing.

The calendar asks the same questions and lets you pick a time: 60 min, Google Meet.

  • 60 minutes
  • Google Meet
  • No commitment

Book a call in the calendar