← All articles

Mikhail Polyakov

Does a startup need a systems analyst: what the work involves and when to hire a dedicated person

Level: BeginnerReading time: 12 min

Topics: Systems analysis, Small business

A glowing laptop on a dark background with lines running to a payment card, a delivery box and a stack of customer cards; above the laptop a transparent diagram with arrows and a fork, with a yellow warning triangle at the fork

Short answer: a startup needs the work of a systems analyst from the first line of code, but it does not need a dedicated person for it right away. Someone on the team has to decide what data the product stores, which services it exchanges data with, what happens when something fails and how to tell that a feature is done. At the start, the founder and the lead developer do this using a simple template. Hiring an analyst makes sense when the losses they will actually remove are worth more in money than their full cost to the company. In a small team, add to the developers' hours what those hours cannot measure: errors with customers' money, partners' requirements, risks with personal data. Below I explain how to check this on your own team and how to do the numbers.

I have been in IT for more than 13 years, in the financial sector since 2020, and I am now a principal systems analyst. I have not worked as a staff analyst at a startup, so there are no startup stories here. This is the approach I apply to new systems built from scratch. The work in your product may look different.

What systems analysis is, in plain words

The founder says: "I want customers to be able to pay for a subscription by card." A systems analyst turns that sentence into a plan for the developers: which screens, which data, which payment service, and what to do if the money was charged but the subscription did not switch on.

The result of the analyst's work is a set of short documents. Developers write code from them, and testers check the result. The documents describe:

  • what the feature should do and under what conditions;
  • what data it stores and where it gets that data;
  • which external services it exchanges data with: payments, delivery, a CRM (software for tracking customers and deals), a marketplace;
  • what happens when something goes wrong: the payment service did not respond, the customer pressed the button twice, the data arrived incomplete;
  • how to tell that the feature is done (acceptance criteria).

Two related roles sit next to it. A business analyst answers the question "what is needed and why". A product analyst looks at user behaviour and product metrics. A systems analyst answers the question "how do we build this in our software". In a small team one person may do all of this, and that is fine.

Why this matters to a startup

A startup's main limited resource is money until the next funding round or until it breaks even. In March 2026 the research company CB Insights studied 431 venture-backed startups that shut down since 2023. The sources were public post-mortems, founder interviews and shutdown announcements. For 70%, running out of money was named among the reasons; for 43%, a product that did not match what the market needed. One startup could have several reasons, so the percentages add up to more than one hundred. And this is not a statistic about all startups: the sample includes only venture-backed companies whose shutdown has public material about it. The report's authors say plainly that running out of money is almost always the end of the story, while the root lies in other reasons.

A systems analyst will not find demand for the product; that is the job of the founder and the people who talk to customers. The analyst's work affects something else: how much money goes into building a feature and then rebuilding it. Every week of developers' time spent on rework because of a scenario nobody accounted for is paid from the same budget as the search for demand.

The second reason is personal data. If the product stores customers' names, phone numbers or email addresses, the Russian personal data law (Federal Law No. 152-FZ, Article 22) requires notifying Roskomnadzor, the Russian data protection regulator, before processing begins. The exceptions are narrow, for example processing without a computer. Failing to file the notification can cost an organisation a fine of 100 to 300 thousand rubles. For a leak of data on 1 to 10 thousand people, a first offence carries a fine of 3 to 5 million rubles for an organisation (Article 13.11 of the Russian Code of Administrative Offences, parts 10 and 12). Deciding "what data to collect, where to store it and who to show it to" is exactly systems analysis. The less unnecessary data, the lower the risk. This is a pointer, not legal advice: check with a lawyer what exactly your product needs.

Who does this work at different stages

Stage Who does it What is enough
Idea and prototype, 1-2 developers The founder together with a developer One page per feature using the template below
First paying customers, payments and 2-3 external services connected The lead developer or a part-time analyst on contract The template plus a data exchange diagram for each external service
Several teams, large customers require documentation, customers' money and personal data A dedicated systems analyst Requirements, a description of data exchange, a data model, failure scenarios

I would draw the line between stages using two questions: how much an error costs and how many systems are connected to each other. Revenue is secondary here, while the number of developers matters for the payback calculation below.

Signs it is time to hire, and how to check them

Each sign comes with a way to check it. The founder or the head of development does the check, using data from the last month.

  1. Developers spend a lot of time on clarifications. How to check: ask the team to log in the task tracker (the software where tasks are managed) for one week the time spent on calls and messages about "how is this supposed to work". The resulting hours will be needed for the payback calculation below.
  2. Finished features come back for rework. How to check: create a label in the tracker, "rework: scenario not accounted for", and count such tasks over a month. If such tasks appear every month, go through two or three of them: which scenario was missed, and could it have been described before work started. If the reason is that nobody described the scenario before work started, that is the part of the analyst's work your team is missing. If the reason is different, for example the customer's requirements changed, this sign has nothing to do with hiring an analyst.
  3. There are now many external services. Payments, delivery, CRM, marketplace, email service. How to check: draw on one sheet which services exchange data with which. If nobody on the team can draw this diagram without mistakes, it is time to document it.
  4. Errors with money and statuses. A payment went through but no order was created, or a customer was charged twice. How to check: for one month, compare the number of successful payments in the payment service's dashboard with the number of paid orders in your database. Any mismatch is worth investigating: it may mean a failure in the data exchange between services.
  5. A large customer or partner asks for documentation. A description of the programming interface (API, meaning the rules by which your system exchanges data with someone else's), a list of stored data, answers to security questions. If the team takes weeks to answer such a request, check whether anyone has the time and the skills to prepare these documents. This is one of a systems analyst's tasks.
  6. A new developer takes a long time to get up to speed. If a newcomer needs a month of questions to understand how the product works, it may mean that the way the product works is not written down anywhere.

One sign is not yet a reason to hire. Two or three at once, especially the fourth, are a good reason to at least do the numbers.

What it costs and how to work out the payback

According to Habr Career for the first half of 2026, the median salary of a systems analyst is 222 thousand rubles a month: 109 thousand for junior, 200 for middle, 303 for senior. The median salary of a backend developer (the person who writes the server side: the logic, the database work, the exchange with other services) is 251 thousand rubles. Both figures come from studies by the same platform and cover all industries. The company's real costs are higher because of taxes and social insurance contributions; the rate depends on the company's status, and an accountant will give you the exact amount.

The calculation is simple. Monthly cost: the analyst's salary plus taxes and contributions. Monthly benefit: the developers' time spent on clarifications and rework, multiplied by their monthly cost, but only the part the analyst will actually remove. The analyst pays off when the benefit is greater than the cost.

A hypothetical example using median salaries; the share of losses here is an assumption, so substitute your own from the check above:

  • 3 backend developers, 15% of time lost. 3 × 251 thousand × 0.15 ≈ 113 thousand rubles a month. That is less than a mid-level analyst's salary. Measured by developers' hours, a staff analyst will not pay off here; the template below or a part-time analyst on contract makes more sense.
  • 6 backend developers, the same 15%. 6 × 251 thousand × 0.15 ≈ 226 thousand rubles a month. But those are all the losses, and the analyst will remove only part of them. If they remove half, the benefit is ≈ 113 thousand, which is again less than their salary, even before taxes and contributions.

How many developers you need under the same assumptions (15% losses, the analyst removes half): the benefit per developer is 251 thousand × 0.15 × 0.5 ≈ 19 thousand rubles a month. To cover even a mid-level analyst's salary of 200 thousand, before taxes and contributions, you need 11 or more developers.

So in a small team, a calculation based on developers' hours alone is unlikely to add up. The case for hiring then rests on other things: errors with customers' money, a large partner who will not connect without documentation, personal data. Estimate these losses with your own numbers and add them to the benefit. If there is nothing to add, then by this calculation it is too early to hire a staff analyst.

How to tell whether the investment is working: two or three months after hiring, repeat both checks from the previous section, time spent on clarifications and the number of reworks. A decrease will not prove that the analyst is the reason, but if the numbers have not gone down at all, find out whether the team reads what the analyst writes and whether the analyst manages to describe a task before work on it starts. If nothing changes after that either, the hire is worth reconsidering.

How to start without a dedicated analyst

Before a developer picks up a new feature, the founder and the lead developer fill in one page with five points.

  1. Why. Who uses the feature and what problem it solves, in one or two sentences.
  2. Data. What the feature stores and where it gets it. Whether any of it is personal data, and whether you can do without it.
  3. Exchange. Which external services the feature exchanges data with and what exactly it sends. The principle: do not send another service a field it can do without.
  4. Failures. What happens if an external service does not respond; if the customer presses the button twice; if the payment went through but our system went down. For each case: what the customer sees and who on the team finds out about the problem.
  5. Done. Three to five checks after which the feature can be released. For example: "pressing the button a second time does not create a second order".

How to check that the template works: compare two numbers for a month. First: how many hours the team spends filling in the pages. Second: how many hours went into tasks labelled "rework: scenario not accounted for" before you started using the template and after. If the hours spent on rework fell by more than the time spent on the template, that is an argument for keeping it, but not proof. Other things affect the number of reworks too, for example a new person on the team or a big release, and an hour of the lead developer costs more than an hour of a junior, so for accuracy convert the hours into money at each person's rate and look at two or three months. If there is no difference, simplify the template or drop it.

You can ask a neural network for a draft of such a page: describe the feature and ask it to list what could go wrong. The neural network may miss something important or invent something unnecessary, so a person on the team makes the decision on each point. Do not paste customers' personal data or confidential agreements into a public chatbot.

How to assess a candidate, and when an analyst will not help

A simple test task: give the candidate a description of one of your features, for example paying for an order, and ask them to spend a couple of hours describing what could go wrong and what the system should do in each case. It is a good sign if the candidate starts by asking which services are involved and what the customer sees. It is a bad sign if they simply retell the description in other words. Ask to see an example of their past documents with confidential data removed: from them you can judge whether they write for developers or for a report.

If you need someone part-time, agree on a result rather than on hours: for example, a description of the exchange with the payment service and the failure scenarios by a certain date.

When an analyst will not help:

  • there is no demand for the product yet. The analyst will describe how a product nobody needs is built, and that is an extra cost from the same budget;
  • the team has one or two developers, and the founder is around every day and can answer any question in five minutes. The template is enough here;
  • the analyst is hired to "write documentation", while the team keeps deciding everything on calls. Documents nobody reads do not reduce losses.

Summary

Systems analysis in a startup begins with answering four questions for each feature: what data, what exchange with whom, what happens on failure and how to tell it is done. At the start, the founder and the lead developer answer them on one page per feature. A dedicated analyst makes sense when the losses they will remove are worth more in money than their full cost to the company. With median salaries and the assumptions from the example, developers' hours alone cover a mid-level analyst's salary only from 11 developers. So in a small team the case for hiring rests on customers' money, partners' requirements and personal data, and these are worth estimating with your own numbers. Start with the two checks in the tracker; they will help you understand where you are now.

I have a separate piece on how the same profession works at a bank, where the cost of an error is higher and the regulator writes part of the requirements: systems analysis at a bank and a large fintech company.

I work in systems analysis, AI agents and automation. If you would like to see my projects or discuss your own task, take a look at my portfolio.

Sources