Software
What a company should know before the first conversation about a software project
You don't need a technical specification — but a few answers prepared in advance make the first conversation much more productive for both sides.
The best, most productive first conversations about a new software project are not necessarily the ones where the client arrives with a finished, detailed technical specification — but the ones where the client very clearly understands and can explain their real business problem, in their own words, without technical jargon. The technical decisions about how to solve that problem are our job, not yours.
What is useful to know and prepare in advance
Which concrete, everyday problem you want to solve — described in plain, everyday words, not technical terms you may have heard but don't understand quite precisely.
Who will actually use the system daily and roughly how many people — employees, clients, or both — because this directly shapes both the features and the architecture.
Whether there is an existing tool, an Excel sheet, or a paper process the new system should replace, and what exactly about that existing solution bothers or slows the business down most.
A rough desired launch deadline, and if it exists, a rough available budget — even an approximate range is much more useful for planning than complete vagueness.
What you don't need to know in advance at all
The technology, the system architecture, or the exact, final list of every individual feature — all of that is defined together only after we truly, thoroughly understand your problem and business context.
The first conversation serves mutual understanding of the problem and context, not making final decisions about code, technology or exact architecture — those decisions come naturally later, when we have enough information to make them responsibly.
Related
Nikola Cerić
Founder & CEO, Manage IT
More than 10 years of software development experience — in his own company and in major IT companies across the Balkans.