You do not need a complete technical specification, finished interface designs, or a hundred-item feature list before speaking with a software development company.

In many projects, defining those details together with the product and development team leads to a better result.

Still, thinking through a few essential areas before the first meeting can improve the quality of the conversation significantly. The team can understand the need more accurately, uncertainty becomes visible earlier, and it becomes easier to evaluate why proposals differ in scope, timing, and cost.

The following eight areas provide a strong foundation.

1. The problem you want to solve

It is possible to begin with “We want a mobile app” or “We are considering an AI-powered platform.” But explaining the problem before the preferred solution is far more useful.

Prepare short answers to the following questions:

  • What is inefficient, unreliable, or difficult today?
  • Who is affected by the problem?
  • How often does it happen?
  • What does it cost in time, money, errors, or lost customers?
  • How is the team handling it now?

“We need a teacher dashboard” describes an output. “Teachers spend several hours each week combining student results from different sources” provides the context needed to design the right solution.

2. The target users and decision-makers

Who will use the product, who will manage it, and who will approve the purchase?

These may be different people.

In an EdTech product, students, teachers, school administrators, parents, and publishers can all interact with the same platform in different ways. In hospital software, doctors, nurses, operations teams, IT departments, and executives may have distinct requirements.

For each user group, note:

  • The main task they need to complete
  • Their biggest difficulty today
  • The outcome they expect from a successful experience

This helps prevent a common problem: designing one generic interface for roles that have completely different goals.

3. The current workflow

Even when the new product is intended to transform the process, users are already doing something today.

Describe the current workflow in simple steps:

  1. Where does the request or information originate?
  2. Who takes the first action?
  3. Which data is collected?
  4. Who approves or reviews it?
  5. Where does the result go?
  6. Which report or output is produced?

Include spreadsheets, forms, emails, WhatsApp messages, existing applications, and manual workarounds.

The development team needs to understand not only the ideal future process, but also the habits, dependencies, and exceptions that shape the work today.

4. The business result you expect

“The software is completed” should not be the definition of success.

Describe what should improve in the business. For example:

  • Reduce manual data entry
  • Create a new subscription-revenue stream
  • Respond to customer requests faster
  • Increase active use among teachers
  • Reduce reservation errors
  • Enter a new market
  • Enable the operations team to support more customers without growing at the same rate

Where possible, identify one or two measurable outcomes. These provide a practical basis for discussing scope and priority.

5. What is essential and what can wait

You do not need to arrive with a fixed and exhaustive feature list. It is still useful to group your current ideas into three levels:

  • Essential for the first release
  • Valuable, but suitable for a later phase
  • Interesting ideas that still need validation

Use the word “essential” carefully. If removing a feature does not eliminate the product’s core value, create a legal or security problem, or prevent the target user from completing the main journey, it may not belong in the first phase.

Prioritisation is not random cost-cutting. It is a way to learn earlier and invest with better evidence.

6. Products you like—and products you do not

Reference products make expectations easier to discuss. Rather than saying “We want something like this,” explain what works for you and why.

  • Is the registration process simple?
  • Does the dashboard summarise information effectively?
  • Are search and filtering particularly strong?
  • Does the visual language create trust?
  • Is the mobile experience fast and focused?

Share examples you dislike as well, together with the reason.

References do not need to come from your own industry. A tourism booking journey may borrow ideas from the guided flow of a healthcare application. What matters is explaining the behaviour or principle you want to learn from—not asking for a copy of the product.

7. Integrations, data, and technical constraints

Consider how the new product will relate to the organisation’s existing environment.

Prepare whatever information is available about:

  • Current systems and software
  • Required integrations
  • Existing APIs or technical documentation
  • Data that must be migrated
  • File formats and data quality
  • Current user numbers and expected growth
  • Security, privacy, or regulatory requirements
  • Web, mobile, or offline use

You may not have every answer. That is fine. Unknowns should still be made visible.

“We do not know whether the existing system has an API” is useful information. Ignoring the integration until development begins is not.

8. Budget, timing, and the decision process

Many organisations are hesitant to discuss budget early. But without any range or commercial context, it is difficult for a software company to recommend a realistic approach.

The same problem can be addressed through a lightweight pilot, a production-ready platform, or a multi-country enterprise system. Those are not comparable in cost or delivery effort.

Try to clarify:

  • The expected investment range
  • Any critical launch, event, contract, or regulatory date
  • Who will make the final decision
  • Whether procurement, legal, security, or IT approval is required
  • Who is responsible for content, design, data, and internal coordination

Even when time and budget are not fixed, you can explain the trade-off that matters most. For example:

Speed is more important than breadth in the first phase.

Or:

The initial scope can be small, but the system must meet specific security requirements from the beginning.

What should you expect from the first meeting?

A strong software team will not simply record requested features. It will try to understand the problem, users, business model, constraints, and risks.

You should expect questions such as:

  • Why is this capability necessary?
  • How does the process work today?
  • Who will be the first user group?
  • How will success be measured?
  • Which assumption creates the greatest risk?
  • Is technical access available for the integration?
  • Can the scope be divided into phases?

These questions are not intended to make the process more difficult. They are intended to prevent the team from building the wrong product correctly.

At ONX Software, we have worked on software projects across different industries for nearly 20 years, including more than 12 years of focused EdTech experience. One pattern has remained consistent: clients do not need to arrive with every answer.

The strongest projects begin when everyone understands which questions remain unanswered.

The purpose of the first meeting is not to present a perfect project file. It is to create enough shared context to define the right problem, scope, and next step together.