Asking a tech team for software without a clear brief is like asking an architect for a house without knowing how many bedrooms you want. Something will come out. Probably not what you needed. And the fix costs more than getting it right the first time.
Before any line of code exists, someone needs to ask a series of boring questions. Questions that feel like a waste of time at first and pay off massively in the following months. Let's walk through the main ones.
The brief: the only moment where being wrong is cheap
Three questions work as a compass: who's going to use the product, what problem does it solve, and how will we measure success. Sounds simple, but most projects launch without a firm answer to at least one of them. When software ships and nobody uses it, the first question was usually answered with 'everybody'. When it turns into a permanent cost center, the third question was never asked. Document the answers on one page, two at most. This isn't the moment for a fifty-slide deck. Vision, core problem, assumptions, known constraints. That document will be referenced for months, so it has to be short enough that someone actually opens it before a meeting.
Understand the user before imagining the screen
Use a simple narrative: write a day in the life of the user you want to serve. Find out where they get stuck, which tools they already use, and what 'now this is easy' would look like for them. That description is worth more than any wireframe drawn before understanding the context. A wireframe without context is just a nice-looking screen, and nice-looking screens don't solve problems.
Minimum viable team
At the start, three roles usually cover it: someone in product who decides priorities, someone in design who shapes the experience, someone in engineering who ships. QA, data, infrastructure come in as the scope grows. Inflating the team to look serious is the most expensive way to avoid making decisions. The parallel question: outsource or hire? No right answer. Just trade-offs. An agency ships fast and walks away. An internal team takes longer to produce but builds knowledge that sticks.
Architecture without jargon
Architecture is the skeleton: web or mobile, database, integrations with existing systems, authentication. You don't need to understand every technical decision, you need to insist they're documented. A short file called an Architecture Decision Record (ADR) with the why behind each choice pays off for years. Without it, in a year someone will want to swap the database and nobody will remember why the current one was chosen.
Before coding starts: an honest checklist
There's always a tendency to start building fast because 'we have enough'. Before letting the team start coding, double-check: was the user actually mapped or are they still 'anyone'? Was the prototype tested with real people? Are the success metrics agreed between business and engineering? Do the known risks have a plan? If the answer to any of those is 'kind of', the first sprint already begins in debt.
“The most expensive money in a project is the money you spend redoing things because you skipped a step at the start.”
With these steps you don't avoid every problem, you avoid the expensive ones. Surprises will still come, they always do. The difference is they show up in things worth learning, not in decisions you could have made before spending three months building.