up to 80× shorter path from a product idea to a manufacturing brief
5 standards turned into the rules the system runs on
< 30 seconds to produce the first draft of a technical brief The pain The company makes homeware at contract factories, but every new item in the range starts in chaos: a treasure hunt through spreadsheets, old files and messenger threads. One manager records the body material but forgets the alloy grade; another adds the base thickness and saves the change in a spreadsheet of their own.
The result is that “we need a new saucepan” turns into a month of sign-offs and the risk of a faulty batch.
Audit The client arrived with a finished document describing an automation service. At first glance it was serious work: stack, modules, integrations. At second glance the technologies conflicted, surplus features inflated the estimate, and the central question — what exactly should this system do? — had no answer. The problem was not a badly written brief. The project had no product idea at all.
We went looking for one in the saucepan rather than in the technology: cookware already has mandatory characteristics, permitted materials and quality requirements, all of it long since written down in national standards.
The builder: describing a product in free text Not a demo. A product In the new brief we made those standards the basis of the whole product logic. For the first version we took five standards covering one product category apart into working rules: what has to be stated on the form, which values are permitted, and what the system should ask about on its own.
All of it went into a web-based builder that walks an employee from a hypothesis for a new product to documentation a factory can read.
How the first version works A manager describes the product in plain words: “a five-litre stainless steel saucepan with a non-stick coating”. The system identifies the applicable standard, finds the mandatory characteristics and asks only the questions that are still open. If a material changes the requirements, the form rebuilds itself; if two parameters contradict each other, it warns; if something is missing, it asks rather than assumes.
Once everything lines up, it assembles a single version of the brief as PDF, Word or Excel.
The system asks for the characteristics it still needs 6 sprints 6 weeks 2.25M ₽
Six weekly sprints to the first working version, at a modelled build cost of 2.25M ₽.
The assembled brief, ready to export as PDF, Word or Excel HOPFER is a stand-in for the brand name. Modelled on 12 new products a year, an hourly rate of 2,000 ₽ and 158 hours saved per brief. Prevented errors and failed batches are not counted.
69 %
modelled first-year return
Got a problem? Let us take it apart. You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
Fill in the brief
Email Telegram channel MAX channel
≈10,000 policies issued every month
up to a week sales can stall while a partner is unreachable
10,000+ clients in the broker’s database The pain A broker sits between a person and a single insurer: takes the request, gets a price, issues the policy. When the partner goes down, nothing is quoted, nothing is issued, and sales across the whole network stall for up to a week.
On top of that, each of the ten thousand monthly policies is handled by hand: the same data entered again, a separate payment link sent for every product. Two items means two policies and four links. Clients get lost, reports are stitched together in spreadsheets, and renewals live in someone’s head.
Audit We started with the process rather than the ageing technology, and walked the client’s path from the first question to issuing and renewing a policy. It turned out two separate pains needed two separate answers.
Automation removes the manual chaos: data entered once, a single order and payment, automatic reports and reminders. An aggregator removes the dependence on one partner: the platform queries several insurers in parallel, and if one is unavailable it turns to the others.
Client record: details entered once Not a chatbot. A platform We designed one system for the whole of policy work: insurer quotes, clients, orders, payments, renewals and reporting. At its centre is the aggregator that collects quotes from different insurers. Around it sit a CRM, unified payment, analytics and an assistant for routine questions.
A manager enters the owner and vehicle details once, prices arrive in a single view, and the client gets one link or QR code instead of several.
The budget changed. The project did not The platform was planned as six weekly sprints. After the second, the client’s finances changed and the remaining four could no longer be funded in full. Stopping would have left them with analysis, architecture and a skeleton, but no working product.
We went back through the feature list, separated what was essential from what could be added later, and rebuilt four sprints into two. Testing and documentation were not cut — only the scope of the first version was.
Quotes from several insurers side by side 6 → 4 sprints −33 % 1.5M ₽
Development shrank by a third: the modelled budget after the rebuild went from 2.25M ₽ to 1.5M ₽.
The remaining 20 % of the feature set moved to the next stage — nothing was thrown away, all of it is written down and ready to come back into the work.
One link and one payment for every policy BROKER.PRO is a stand-in for the brand name. Modelled at a nominal sprint cost of 375,000 ₽. The 80 % of retained functionality is the team’s own estimate. The actual project budget is not disclosed.
750,000 ₽
saved while keeping 80 % of the feature set
Got a problem? Let us take it apart. You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
Fill in the brief
Email Telegram channel MAX channel
+60 % target growth in output: from 25 to 40+ books a year
up to 7× faster text and storyboarding
3 › 2 months shorter production cycle per book The pain The publisher puts out around 25 children’s books a year, but each one is assembled like a one-off project. An external author writes the manuscript, an editor reworks the text in a private chat with a model, a designer lays out the pages in professional software, and the illustrator waits off to the side.
Edits and approvals live in messengers, and every decision that matters funnels back to an overloaded editor-in-chief. Not a production process — a book hand-assembled out of people, files and chats.
Audit A four-page brief was already on the table, written by the client themselves. At first glance it was ambitious and technical. At second glance there was plenty of technology, little logic, and no answer to the question of what exactly was being built.
Rather than price development blind, we put together 80+ questions across 14 areas, traced a book’s path from subject to layout, and found the real task. The publisher did not need another writing tool — it needed one production system.
An editor starts a book: subject, character, task The product is the editorial process The new brief described not a feature list but an editorial chain: one book project, four roles, one current version and mandatory points of approval.
Each stage hands its result to the next: synopsis to text, text to storyboard, storyboard to illustrator, finished images to layout. Until the previous stage is approved the next one does not open, and the system keeps the versions, comments, prompts and working material.
How the first version works An editor describes the subject, the character and the task straight in the browser, then fills in the intent: age, format, tone, method. The system offers ways the synopsis could develop; the editor picks one, adjusts the detail and approves it.
From there the system lays the story out across spreads and drafts the text, then describes each spread from the final version: what happens in the scene, where the text sits, what the illustration needs to show. The storyboard goes to the illustrator, and the finished illustrations are joined to the text in a browser-based layout.
Spreads storyboarded from the approved text 6 sprints 6 weeks 2.25M ₽
Six weekly sprints to the first working version. Target output: 40+ books a year against the previous 25.
Layout: illustrations and text assembled in the browser WISEBOOKS is a stand-in for the brand name. The development timeline is actual. Cost and the growth in output are modelled figures; real impact will be measured after rollout.
+15 books
every year on top of the previous twenty-five
Got a problem? Let us take it apart. You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
Fill in the brief
Email Telegram channel MAX channel
Bot development and process automation We take off people the work people should not be doing: moving data, reconciling spreadsheets, reminding each other.
Where we start Not with a bot. A bot is the last thing to appear in this work, and it does not always appear at all. First we look at what the process is actually made of: who does what by hand, where they move it, what they double-check and where they wait for an answer.
Usually it turns out that what needs automating is not the action but the approvals around it.
What stops being manual Moving data between systems that do not talk to each other. Collecting the same details a second time. Checking that everything is filled in. Reminders that a deadline is due. The report assembled every month from the same exports.
None of it is heroic work, but it is what eats the working day, and it is where the most expensive mistakes happen.
Where the AI sits Where something has to be understood rather than executed: parsing an email, pulling meaning out of a free-form description, suggesting wording, reconciling scattered documents.
It does not make decisions. Product logic, architecture and consequences are a person’s responsibility — that is not a disclaimer, it is the condition we work on.
When you do not need this If the process runs once a month and takes twenty minutes, automation pays for itself in a decade. We will say so plainly, as we do in every case where building is not worth it.
Got a problem? Let us take it apart. You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
Fill in the brief
Email Telegram channel MAX channel
Why this comes before development 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.
How we take it apart We ask questions — on one project more than eighty of them across fourteen areas: who uses the product and why, what happens when everything goes wrong, who answers for it.
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 are left with 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.
When you do not need this If the task is clear, written down and uncontested inside your team — go and build it. The review exists to work out whether anything should be built at all, not to sell development.
Got a problem? Let us take it apart. You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
Fill in the brief
Email Telegram channel MAX channel
Design does not start in the mockup A beautiful screen laid over a misunderstood process is still a misunderstood process. So design here sits right against analysis: the scenario, the states, what a person sees when there is no data, when there is too much of it, and when everything has broken.
Those three states decide more than the main screen does, and they are the last ones anybody remembers.
What we do Product structure and navigation. Key scenarios down to the pixel. States — empty, loading, error, limit. The rules by which new screens get built, so the product does not sprawl by its twentieth one.
And interface copy: a button that honestly names its action saves more support than any redesign.
How we hand it over Not as a picture. The mockup goes with a description of behaviour: what happens on tap, what happens on failure, how it behaves on a narrow screen. Development does not have to guess, which means it does not have to rebuild.
When you do not need this An internal tool for ten people rarely needs product design — it needs a clear form and predictable states. That is work too, but noticeably less of it, and selling a full cycle for it would be dishonest.
Got a problem? Let us take it apart. You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
Fill in the brief
Email Telegram channel MAX channel
What «one loop» means Not three contractors but one coherent logic. The interface knows what the server can do; the server knows where the data comes from; the infrastructure is sized for what was actually built.
The gaps between those three cost more than any of them alone — that is where «it somehow does not work» lives, along with the months spent working out whose half it is.
What is included Web interfaces, including hard ones — builders, editors, operator workplaces. Server logic, the database, integrations with other systems and data exchange. Deployment, environments, logs and monitoring — the things without which a product lives until its first outage.
What we build it on The stack is chosen for the task rather than the other way round — and we always show what we use and why. The client gets a system they can run, not magic: documentation, access, and the ability to hand the project to another team without archaeology.
How we cost it In weekly sprints: each one leaves a working result and leaves the decision about the next investment with you. On one project that let us rebuild the scope a third cheaper when the client’s circumstances changed — throwing nothing away, only deferring it.
Got a problem? Let us take it apart. You do not need a finished brief. An idea, a bottleneck or a process that has outgrown its spreadsheet is enough to start.
Fill in the brief
Email Telegram channel MAX channel
