Why Technical Debt in Business Starts with a Poor Brief

Over years of working in business — first at Alkar in the 90s, then at Dom i Sad, and now with formspace.design — I've repeatedly become convinced: the root of most problems with development, automation, and even simple tasks lies in a poor brief. Technical debt, the accumulated problems in code or a system that slow down development, doesn't start with a programmer's "clumsy hands," but with a vaguely formulated request. This is my deep conviction, based on decades of practice, task setting, and subsequent reworks.

Why a poor brief is the foundation of tech debt

Imagine: you're building a house. But instead of a clear project and plan, you tell the builders: "Make something beautiful, spacious, and cozy." What will they build? Something that matches their ideas of beauty, spaciousness, and coziness, but not necessarily yours. In IT projects, this is even more acute. A programmer is an executor who works with logic and algorithms. If they receive a vague technical specification (TS), they have to fill in the details, make decisions for the client. These "fill-ins" are the first bricks of tech debt.

I remember in the early 90s, when we at Alkar were just starting to implement software for management accounting, I made this mistake myself. I thought that programmers "should understand" my needs. As a result, we spent weeks, sometimes months, developing functionality that later had to be redone because it didn't quite match the real business processes. Each such rework is not just lost time; it's lost profit, team demotivation, and ultimately, real money. In my observations, changing a TS by 30% halfway through a project can double the timeline and budget. These are huge losses that can be avoided.

Signs of a poor brief: how to recognize it at the start

Recognizing a poor brief at the initial stage is already half the battle. Here are a few red flags I always pay attention to:

1. Lack of specificity. Phrases like "make it convenient," "make it modern," "improve efficiency" without numerical indicators or clear evaluation criteria. What does "convenient" mean? For whom? How?
2. Conflicting requirements. When one point in the TS says one thing, and another says the exact opposite. Or when different stakeholders provide different inputs, and they are not aligned.
3. Lack of understanding of the goal. If the client cannot clearly articulate what business problem the product or function should solve, what result they expect to achieve in the end.
4. Frequent changes during the process. Of course, the business environment changes, but if requirements are drastically revised every week, it's a sure path to chaos and endless reworks. This is a classic example of "first we did X – then we redid it," which I've seen hundreds of times.
5. Absence of priorities. When all functions are equally important, and there's no understanding of what needs to be done first for a Minimum Viable Product (MVP).

How I learned to formulate tasks for programmers

My journey from "a director who wants something" to the founder of formspace.design, who sets tasks himself (sometimes even for myself, with the help of AI), has been long and arduous. At Alkar, I realized I needed to delve into details. At Dom i Sad, managing construction and landscape design projects, I learned to decompose large tasks into small, measurable stages. It was then that I began to apply principles that later formed the basis of my approach to automation and IT.

I started demanding from myself and my managers:

• Clear description of the desired result: What should happen when the user performs an action? What data should change? How does it look?
• Screenshots, prototypes, diagrams: Visualization often speaks louder than a thousand words. Even a hand-drawn mockup helps avoid ambiguity.
• Data examples: What should input and output data look like? This is critically important for the system to function correctly.
• Understanding the business process: If a programmer understands why a particular function is needed, they can suggest a more optimal solution or notice logical errors in the TS.

This doesn't mean I became a programmer. Rather, I learned to speak a language that allows the developer to precisely understand my thoughts. My experience working with AI, which I discussed in the article How AI helps me run formspace.design without a large team, only confirms this thesis: the more precise and detailed my prompt, the better the result.

Checklist for creating an effective brief

To avoid the pain and tech debt I've encountered, I recommend using the following checklist when preparing a brief:

1. Define the goal: What problem does the project solve? What result is expected? (For example: "Reduce estimate calculation time from 3 hours to 15 minutes").
2. Describe the target audience: Who will use the product? What are their needs and limitations?
3. Formulate a list of functions (functional requirements): What exactly should the system do? Every user action, every system reaction. (For example: "User can upload a photo of the site," "System generates 3 landscape design options").
4. Specify non-functional requirements: Performance, security, usability, scalability. (For example: "Page should load in no more than 2 seconds," "System should handle up to 1000 requests per hour").
5. Draw prototypes or diagrams: How does the interface look? How does the user navigate the system? This can be a sketch on paper or a full-fledged mockup in Figma.
6. Specify technologies used and integrations (if any): With which other systems should the product interact?
7. Define timelines and budget: Realistic frameworks for the project.
8. Assign responsibilities: Who from the client side will accept the work, answer questions, provide feedback?
9. Review the brief: Have several people from both the client and the executor read and discuss the document to identify ambiguities and contradictions before work begins.

Consequences of a poor briefing for business

The cost of a poor brief is high and is measured not only in money but also in time, reputation, and even team morale. I've seen projects drag on for a year or two, or even fail entirely due to initial vagueness. In my estimation, every ruble "saved" at the briefing stage turns into ten in rework and modifications.

• Financial losses: Additional programmer hours, payment for reworks, lost profit from untimely product launch.
• Time loss: Projects go beyond deadlines, which can lead to a loss of competitive advantage.
• Low product quality: If requirements were unclear, the final product may not solve real user problems or be inconvenient to use.
• Team demotivation: Constant reworks and a lack of clear goals exhaust both the client and the executor, reducing productivity and willingness to work on the project.
• Reputational risks: Unsuccessful projects can damage the reputation of both the client company and the executor. After all, as I wrote in the article A typical story: ordered one thing, got another, paid twice, this is a common problem many face.

formspace.design and lessons from the past: how we avoid tech debt

When I started creating formspace.design, I understood how important it was to avoid past mistakes. I am not a professional programmer, but my many years of experience in business and landscape design taught me the value of clear planning. I develop formspace.design myself, using AI as a powerful tool, and this has only been possible because I learned to formulate my ideas as concretely as possible. formspace.design modules are created with this principle in mind.

For example, when I plan a new function, whether in the planning modules (1.x plan/zones/objects) or in the AI concept block (2.1 AI concept), I first thoroughly work through the use case scenario myself, down to the smallest details. I imagine what the user will do, what data they will enter, what result to expect. For module 3.1 "Design by Photo," this means precisely defining image processing parameters, possible styles, elements that the AI should recognize and modify. I write down these steps, draw prototypes, and only then proceed to write the code (or prompts for the AI). This allows me to avoid "filling in the blanks" during implementation and minimize technical debt, even working without a staff of programmers, as I shared in What a day looks like when I code without being a programmer.

FAQ

Can technical debt be completely avoided?

Completely avoiding technical debt is probably impossible, as it can arise for various reasons, including changing technologies or business requirements. However, it can be minimized and effectively managed through quality briefing, regular refactoring, and strategic planning. The main thing is to approach each task consciously and not postpone solving known problems 'for later.'

What if the client cannot provide a clear brief?

In such a situation, the task of the manager or analyst is to help the client formulate requirements. This may include conducting workshops, interviews, studying business processes, and creating prototypes. It is important to ask guiding questions, offer options, and achieve specificity before handing the task over for development. This is a time investment that will pay off many times over.

Does a detailed brief always mean a successful project?

A detailed brief significantly increases the chances of success but does not guarantee it 100%. The qualifications of the executors, effective project management, adequate risk assessment, and willingness to communicate are also important. However, the absence of a detailed brief almost always leads to problems, while its presence is a powerful foundation.

How to distinguish technical debt from ordinary necessary refinements?

Technical debt is 'unpaid loans' taken for speed, but which later demand repayment. It manifests as suboptimal code, temporary solutions, lack of documentation, which complicates further development. Ordinary refinements are planned product development, adding new functionality or improving existing ones, which are not caused by past errors or poor-quality solutions.

As a manager, do I need to understand technical details to create a brief?

You don't necessarily have to be a programmer, but understanding the basic principles of how a system works and how your decisions affect technical implementation is very useful. My path to formspace.design showed that deep subject matter expertise combined with the ability to clearly formulate tasks is more important than knowing programming languages. The main thing is the ability to translate business needs into requirements understandable to developers.

How often should a brief be reviewed and updated?

A brief is a living document that can and should adapt to changing conditions. However, drastic changes should be minimized and carried out consciously, understanding the consequences. For long-term projects, it is recommended to conduct regular brief reviews (e.g., quarterly) and record all changes so that the team always works with up-to-date information.

Can Agile methodologies be used for flexible briefing?

Agile methodologies are excellent for a flexible approach to development and can help avoid a rigid, outdated brief. However, even in Agile, clear user stories and acceptance criteria are necessary for each iteration. Without them, even with a flexible approach, it's easy to fall into ambiguities and accumulate technical debt.

Conclusion

My experience has convinced me: a quality brief — is not just a formality, but a critically important stage that determines the success of the entire project. Ultimately, it is your investment plan for business development. Don't skimp on time and effort in preparing it, and you will save much more in the future. Clarity and specificity at the start are the key to stable development and risk minimization. This is a lesson I learned over decades and now apply in creating formspace.design.