Systems analysis

How it starts

Most clients arrive with an answer rather than a question: a finished specification, a list of modules, a chosen stack. At first glance it all looks solid. At second glance the technologies conflict, surplus features inflate the budget, and the document never answers what the system is actually meant to do.

That is not a badly written spec. It is a missing product idea that the spec conceals. Two of the three case studies published on this site began exactly that way.

How we take it apart

We do not cost development blind. First come the questions — on the last project more than eighty of them across fourteen areas, from who uses the product and why to what happens when everything goes wrong.

Then we walk the whole path: from a person’s first action to the result they came for. The real problem is rarely where it was being looked for.

What you get

A document you can work from: what the system does, in what order, under what conditions, and what counts as finished. Rules, not a wish list.

Where rules already exist outside us, we use them rather than invent our own: on one project five national standards for a product category became the logic by which the system asks, checks and warns.

Numbers on the project

A typical scope after the review: six weekly sprints to a first working version at a modelled development cost of 2.25M ₽.

The review pays for itself twice over: it describes not only what to build but what not to build — on one project the scope was reassembled a third cheaper without losing the point.

When you do not need this

If the task is clear, written down and uncontested inside your team, you do not need analysis — go and build. We will say so plainly: the review exists to work out whether anything should be built at all, not to sell development.