A software development team can build software only when it understands what the business actually needs.

That sounds obvious, but many software projects begin with surprisingly little information.

A client may approach a development company with:

"We need a mobile app."

Or:

"We want an AI-powered platform."

Or:

"We need something similar to our competitor."

Those statements may describe the desired outcome, but they do not provide enough information to start development responsibly.

Before development begins, the client should provide enough business, product, operational and technical information for the development team to understand:

Why the software is being built.

Who will use it.

What those users need to accomplish.

What the software needs to do.

What systems it needs to connect to.

What constraints exist.

What the first release should include.

What success looks like.

The client does not need to know how to write the code.

The client does not need to design the architecture.

The client does not need to know which framework or database should be selected.

That is what the technology team is there to help determine.

But the client does need to provide the business context, product knowledge, existing processes, constraints and decisions that only the business can properly provide.

This article explains what information a client should prepare before starting a software development project, what the development team needs to understand, what the client does not need to know, and how to tell whether a project is actually ready to begin.

This complements the rest of our pre-development documentation series — the documentation checklist, technical documentation, the architecture document, the requirement document, the scope document, requirements vs scope vs specifications vs SOW, and acceptance criteria — but from the other side of the table: this is what the client brings, before any of those documents get written.

---

Quick Answer: What Information Should a Client Provide Before Software Development Starts?

A client should generally provide information covering these areas:

Information Area	What the Development Team Needs to Understand
Business Objective	Why the software is being built
Problem Statement	What problem needs to be solved
Target Users	Who will use the software
User Roles	What different users need to do
Current Process	How the business works today
Product Vision	What the software should become
Core Features	What the first version must do
User Workflows	How users should move through the system
Business Rules	Rules the software must enforce
Data	What information is used and stored
Existing Systems	What software already exists
Integrations	What external systems need to connect
Design Assets	Existing branding, designs or UI guidelines
Content	Text, images and business content needed
Technical Constraints	Existing systems or technologies that must be considered
Security Needs	Access, data protection and security expectations
Compliance Requirements	Relevant legal, regulatory or internal requirements
Infrastructure	Existing hosting or cloud environment, if applicable
Third-Party Accounts	Services, platforms and API accounts needed
Budget	Commercial boundaries
Timeline	Important business dates and deadlines
Priorities	What must be delivered first
Success Criteria	How the client will judge project success
Stakeholders	Who makes decisions and approves work
Dependencies	What the project relies upon
Assumptions	Important conditions the project currently depends on
Ownership	Who will own code, infrastructure, accounts and data
Post-Launch Expectations	Support, maintenance and operational responsibilities

Not every client needs to provide every item before a discovery phase begins.

Some information can be discovered collaboratively.

Some technical decisions should be made by the development team.

The important thing is to make the distinction clear between:

Information the client must provide

and

Decisions the development team should help the client make.

---

The Client Does Not Need to Know Everything

One of the biggest misconceptions about hiring a software development company is that the client needs to arrive with a complete technical blueprint.

They do not.

A client does not necessarily need to know:

• Which programming language should be used
• Which framework should be selected
• Which database should be used
• How APIs should be structured
• How cloud infrastructure should be configured
• How authentication tokens should work
• How the application should be architected internally

Those are technical decisions.

A good development team should be able to evaluate business requirements and recommend an appropriate technical solution.

What the client does need to know is the business.

The client should be able to explain:

What problem are we solving?

Who has this problem?

How is it handled today?

What should improve?

What must the new system accomplish?

That information is more valuable than arriving with a technology stack chosen without understanding the requirements.

---

1. Business Objective

The first thing the development team should understand is why the project exists.

A client should be able to explain the business objective in simple terms.

For example:

We currently process customer requests manually through email and want to automate the process through an online platform.

That is much more useful than:

We want to build an automation platform.

The objective gives the development team context for every later decision.

A feature that does not support the business objective may not belong in the first release.

---

2. Problem Statement

The client should explain the problem in its current form.

A useful problem statement describes:

• What happens today
• Who experiences the problem
• What causes the problem
• How often it occurs
• What impact it has
• Why the existing process is insufficient

For example:

Customers currently call the support team to check order status. This creates repetitive work for support staff and gives customers limited visibility into delivery progress.

That tells the development team much more than:

We need an order tracking feature.

The existing problem provides context for the proposed solution.

---

3. Current Business Process

Before designing a new system, the development team should understand how the business currently operates.

This is particularly important when replacing manual processes or legacy software.

The client should explain:

• Who performs each step
• What information is collected
• What decisions are made
• What systems are used
• Where approvals happen
• Where delays occur
• What exceptions occur
• What happens when something goes wrong

For example:

Customer submits request

↓

Employee reviews request

↓

Manager approves

↓

Operations team processes request

↓

Customer receives confirmation

The future application may automate some of these steps.

But the team needs to understand the existing process before deciding what should change.

---

4. Target Users

The client should identify who will use the software.

Potential users may include:

• Customers
• Employees
• Managers
• Administrators
• Vendors
• Partners
• Service providers
• Internal operations teams

For each major user group, explain:

• What they need
• What they do
• What information they need
• What permissions they require
• What problems they currently face

A software application designed for customers will have very different requirements from one designed for internal employees.

---

5. User Roles and Responsibilities

The client should identify important roles.

For example:

Customer

Can create requests and view their own status.

Support agent

Can view customer requests and update status.

Manager

Can approve or reject specific requests.

Administrator

Can manage users and system configuration.

The client does not necessarily need to define the technical permission model.

But the business responsibilities need to be clear.

The development team can then translate those business responsibilities into technical access controls.

---

6. Product Vision

The client should explain what the product is intended to become.

This is different from the immediate project scope.

For example:

The long-term vision is to create a platform where customers can manage their entire service lifecycle online.

The first release might only support:

• Account creation
• Service booking
• Payment
• Basic status tracking

The long-term vision helps the technical team avoid making short-term decisions that unnecessarily block realistic future growth.

But the entire vision should not automatically become the first project's scope.

---

7. First Release or MVP Priorities

The client should identify what absolutely needs to exist in the first usable release.

Ask:

If we could only launch with five capabilities, what would they be?

This forces prioritization.

For example:

Must have

• Registration
• Login
• Booking
• Payment
• Confirmation

Later

• Loyalty program
• Advanced analytics
• Mobile app
• AI assistant
• Referral system

This makes project planning much more realistic.

---

8. Core Features

The client should identify the major features they expect.

Examples:

• Authentication
• Dashboard
• Search
• Booking
• Payments
• Messaging
• Reporting
• File management
• Notifications
• Administration

At this stage, the client does not need to specify every implementation detail.

The development team can help turn the feature list into properly documented requirements.

---

9. User Workflows

Features alone are not enough.

The client should explain important workflows.

For example:

A customer submits a request, staff reviews it, a manager approves it, and the customer receives a confirmation.

That workflow reveals:

• Users
• Permissions
• Business rules
• Notifications
• Status changes
• Approval steps

A development team can build a feature much more effectively when it understands the complete workflow rather than just the feature name.

---

10. Business Rules

The client should explain rules that the software must enforce.

Examples:

• A booking cannot be created outside working hours.
• Only approved customers can access premium services.
• A manager must approve transactions above a certain threshold.
• A cancelled order cannot be shipped.
• A discount cannot be applied after a specific stage.

These rules are part of the business knowledge.

Developers should not be expected to invent them.

---

11. Data the Business Uses

The client should identify important types of data involved in the system.

For example:

• Customers
• Products
• Orders
• Payments
• Employees
• Appointments
• Contracts
• Documents
• Transactions

The client should also explain:

• What information is important
• Where it currently lives
• Who owns it
• Who can access it
• Whether historical information must be migrated

The development team can then design an appropriate data architecture.

---

12. Existing Software and Systems

If the business already uses software, provide details about it.

This may include:

• CRM
• ERP
• Accounting system
• Payment system
• Inventory system
• HR system
• Existing website
• Mobile application
• Internal tools
• Legacy software

The development team should know what already exists before designing the replacement or integration.

---

13. Existing APIs and Integrations

If the new system needs to communicate with existing services, identify them early.

Examples include:

• Payment providers
• CRM systems
• ERP systems
• Email platforms
• SMS providers
• Authentication services
• AI services
• Shipping providers
• Maps
• Accounting systems

Where possible, provide:

• API documentation
• Account information
• Test credentials
• Sandbox access
• Integration contacts
• Existing data formats

This can save significant time during development.

---

14. Existing Designs and Brand Assets

If the company already has a visual identity, provide:

• Logo
• Brand guidelines
• Colour palette
• Typography
• Existing website
• Existing application screenshots
• Design system
• UI components
• Images and icons

This gives the design team a starting point.

If there are no existing designs, that should also be stated.

The development team can then plan the appropriate design work.

---

15. Content

Software projects frequently require content.

The client may need to provide:

• Product descriptions
• Service descriptions
• Policies
• FAQ content
• Images
• Videos
• Legal text
• Email templates
• Notification text

A project can be technically ready but still unable to launch because content has not been supplied.

Content responsibilities should therefore be documented.

---

16. Required Platforms

The client should specify which platforms are actually required.

For example:

Web

Responsive browser application.

Mobile

Native iOS.

Mobile

Native Android.

Internal

Desktop or internal web application.

Do not assume:

If the web application works on a phone, we automatically have a mobile application.

A responsive website and a native mobile application are different products with different development requirements.

---

17. Geographic and Market Requirements

The client should identify where the software will be used.

This may affect:

• Currency
• Language
• Date format
• Time zones
• Tax rules
• Payment methods
• Data requirements
• Local workflows

A system designed for one market may require changes before it can operate in another.

The development team should know this early.

---

18. Language Requirements

The client should establish whether the application needs:

• One language
• Multiple languages
• Regional variations
• Right-to-left language support

Internationalization can influence architecture and design.

It is much easier to consider it early than to retrofit it later.

---

19. Security Expectations

Clients should communicate the sensitivity of the information being handled.

For example:

• Customer personal information
• Financial information
• Business records
• Confidential documents
• Employee information
• Authentication credentials

The client should also communicate any specific organizational security requirements.

The development team can then design appropriate technical controls.

---

20. Compliance and Regulatory Requirements

The client should identify any known regulatory or contractual requirements that affect the software.

Examples might include:

• Data protection requirements
• Industry-specific obligations
• Internal security standards
• Customer contractual requirements
• Data retention requirements
• Audit requirements

The development team should not be expected to discover every business-specific compliance obligation without input from the organization.

The client knows the business environment.

The technology team translates relevant requirements into technical implementation.

---

21. Existing Infrastructure

If the organization already has infrastructure, provide information about it.

This might include:

• Cloud account
• Hosting
• Domains
• DNS
• Databases
• Servers
• Storage
• CI/CD
• Monitoring
• Identity systems

If the company does not have existing infrastructure, that should also be clear.

The development team can then recommend an appropriate environment.

---

22. Third-Party Accounts

Software projects frequently depend on external accounts.

Examples:

• Payment provider
• Email provider
• SMS provider
• Cloud platform
• Analytics platform
• AI provider
• App store accounts
• Domain registrar

The client should identify which accounts already exist and who owns them.

This becomes particularly important at handover.

---

23. Business Contacts and Decision Makers

A software project should have clear decision ownership.

The development team should know:

• Who owns the product
• Who approves requirements
• Who approves design
• Who approves technical decisions
• Who accepts milestones
• Who can approve scope changes

A project becomes slower when every small decision requires searching for someone who has authority to answer it.

---

24. Stakeholder Availability

The client should also communicate how available key stakeholders will be.

For example:

• Weekly product review
• Design approvals
• Requirement clarification
• Acceptance testing
• Launch approval

If the project requires frequent client input, that should be understood at the beginning.

Software cannot move forward indefinitely when important decisions are waiting for approval.

---

25. Budget Expectations

The client should establish a realistic commercial boundary.

The development team needs to know whether the project is:

• A small MVP
• A medium product
• An enterprise platform
• A long-term development program

A budget range can help determine:

• Scope
• Architecture
• Team size
• Delivery strategy
• Phase planning

Budget should not be treated as an embarrassing question.

It is a project constraint like time and technical capability.

---

26. Timeline and Important Dates

The client should identify genuine business deadlines.

For example:

• Product launch
• Customer contract
• Internal rollout
• Regulatory deadline
• Event
• Investor milestone
• Seasonal launch

A deadline is much more useful when the reason behind it is understood.

Not every deadline is equally flexible.

The development team needs to know which dates are fixed and which are preferred.

---

27. Success Criteria

The client should explain how the project will be judged.

Success could mean:

• Customers can complete the process without manual assistance.
• Staff processing time is reduced.
• The new application replaces an existing legacy system.
• A product can be launched to paying users.
• A specific workflow becomes automated.
• A certain number of users can be supported.

Success criteria should be connected to the original business objective.

---

28. Existing Problems With Current Software

If replacing an existing application, explain what is wrong with it.

For example:

• Slow performance
• Difficult user experience
• Frequent errors
• Manual processes
• Missing functionality
• Integration problems
• Poor reporting
• Security limitations

This helps the development team understand what cannot simply be carried into the new system.

---

29. What the Client Wants to Keep

Replacing software does not always mean replacing everything.

Identify:

• Existing workflows that must remain
• Existing integrations
• Existing branding
• Existing data
• Existing reports
• Existing user roles
• Existing business rules

This is especially important during system modernization or migration.

---

30. What the Client Wants to Change

The client should also identify what should be different in the new product.

For example:

Current

Customer submits request by email.

Future

Customer submits request through self-service portal.

Current

Staff manually updates status.

Future

Status updates are automatically triggered.

This creates a clear picture of the desired future state.

---

31. Data Migration Requirements

If an existing system is being replaced, the client should explain:

• What data needs to move
• Where it currently exists
• How much data exists
• How old the data is
• What historical records matter
• Whether the data needs cleaning
• Whether all records need migration

Data migration can become a significant project in its own right.

It should not be assumed to be a simple export and import.

---

32. Reporting Requirements

Businesses often depend heavily on reports.

The client should identify:

• Existing reports
• Required new reports
• Important metrics
• Filters
• Export needs
• User access

If an existing report is important to business operations, provide an example.

That is usually much more useful than simply saying:

We need reporting.

---

33. Notification Requirements

Identify important notifications.

These may include:

• Email
• SMS
• Push notifications
• In-app notifications
• Internal alerts

For each major notification, explain:

• Trigger
• Recipient
• Content
• Timing
• Delivery method

The development team can then determine the technical implementation.

---

34. Existing Documentation

If the company already has documentation, provide it.

Useful material may include:

• Process documents
• Existing requirements
• API documentation
• Architecture diagrams
• User manuals
• Database documentation
• Business rules
• Existing contracts
• Integration documentation

Existing documentation can prevent the development team from having to rediscover information the organization already knows.

---

35. Existing Code

If the project is extending or replacing an existing application, provide access to relevant code where appropriate.

The development team may need to assess:

• Existing architecture
• Code quality
• Technical debt
• Dependencies
• APIs
• Database
• Deployment process

An existing application should be evaluated before promising that it can simply be extended.

Sometimes rebuilding a specific component is safer than continuing with an unsuitable technical foundation.

---

36. Technical Restrictions

Clients should disclose technical restrictions early.

Examples:

• Must use an existing cloud provider
• Must integrate with an existing database
• Must use company authentication
• Cannot use a particular third-party service
• Must comply with internal infrastructure rules
• Must deploy into an existing environment

Technical restrictions can significantly influence architecture.

They should not be discovered halfway through development.

---

37. Ownership Requirements

Before development starts, ownership should be discussed.

The project should establish who owns:

• Source code
• Designs
• Domain
• Hosting account
• Cloud infrastructure
• Database
• Third-party accounts
• Data
• Documentation

Ownership should never be treated as an end-of-project surprise.

The development team should know the intended ownership model before project architecture and deployment are finalized.

---

38. Support Expectations

The client should clarify what happens after launch.

Possible expectations include:

• Bug fixing
• Maintenance
• Monitoring
• Infrastructure management
• Feature development
• Technical support
• Response times
• Long-term support

Post-launch support is a separate operational question from initial development.

It should be discussed early.

---

39. Client Information vs Development Team Responsibility

This distinction is worth making very clear.

The client should provide:

• Business objectives
• Business processes
• User knowledge
• Business rules
• Existing systems
• Existing data
• Market requirements
• Compliance information
• Content
• Stakeholder access
• Decisions

The development team should typically handle:

• Technical architecture
• Technology evaluation
• Technical implementation
• Code
• APIs
• Database implementation
• Infrastructure design
• Technical security controls
• Testing strategy
• Deployment engineering

The client does not need to tell the developer:

"Use this exact architecture."

The client should instead explain:

"The system needs to support this business requirement and this expected usage."

The development team should then recommend how to achieve that.

---

What Happens When the Client Provides Too Little Information?

When the development team receives incomplete information, several things can happen.

Assumptions increase

Developers have to fill gaps themselves.

Estimates become less reliable

It is difficult to estimate work that is not clearly defined.

Architecture becomes uncertain

Important technical decisions may depend on missing requirements.

Scope changes increase

New information appears during development.

Rework increases

Incorrect assumptions may have to be reversed.

Timeline becomes less predictable

Blocked decisions can delay development.

The problem is not that clients need to know everything.

The problem is that important unknowns need to be identified and resolved before they become expensive.

---

What Happens When a Client Provides Too Much Technical Direction?

The opposite problem can also occur.

A client may arrive with a predetermined technology stack:

"We want this exact framework, this database and this architecture."

That may be completely reasonable when there is an existing technical environment.

But if the technology decisions are based only on preference, they may create unnecessary constraints.

A better approach is:

Explain the requirements, existing environment, constraints and expected outcomes. Let the technical team evaluate the implementation options.

Technology should serve the requirements.

Requirements should not be rewritten simply to justify a technology choice.

---

Client Readiness for an MVP

A client does not need a 100-page specification to start an MVP.

But the client should be able to explain:

• The problem
• The target user
• The core workflow
• The most important features
• The business rules
• The desired outcome
• What must be in the first release
• What can wait

That is usually a much better starting point than trying to document every future feature before the first version exists.

---

Client Readiness for an Enterprise Project

Enterprise projects usually need more preparation.

The client may need to provide:

• Existing architecture
• System landscape
• Security requirements
• Identity infrastructure
• Integration specifications
• Data sources
• Compliance requirements
• Infrastructure policies
• Access requirements
• Stakeholder map
• Approval processes
• Migration requirements

The larger the organization, the more important it becomes to identify dependencies and decision-makers early.

---

Client Readiness for an AI Project

AI projects need additional information because the expected behaviour of an AI system is often less straightforward than conventional software.

The client should explain:

• What business problem AI is expected to solve
• Who will use the AI system
• What information the AI needs access to
• What data can be used
• What information cannot be exposed
• What the AI should and should not do
• What happens when the system does not know an answer
• Whether human review is required
• What level of accuracy is acceptable
• How success will be measured
• What systems the AI needs to connect to

For example:

We need an AI assistant for internal company documents.

is only the beginning.

The development team may need to know:

• Which documents?
• Who can access which documents?
• How often are documents updated?
• Should answers cite internal information?
• What happens when information is missing?
• Should the system refuse unsupported questions?
• Does the assistant need to perform actions or only answer questions?

AI projects benefit significantly from this clarity before implementation.

---

A Practical Client Pre-Development Checklist

Before development begins, the client should be able to answer:

Business

• What problem are we solving?
• Why does the problem matter?
• What outcome do we want?

Users

• Who will use the software?
• What roles exist?
• What does each role need to accomplish?

Process

• How does the process work today?
• What should change?

Product

• What are the most important features?
• What must exist in the first release?
• What can be postponed?

Rules

• What business rules must the software enforce?

Data

• What information does the system need?
• Where does it currently live?
• Is migration required?

Integrations

• What systems need to communicate?
• Are API credentials and documentation available?

Design

• Are brand assets available?
• Are existing designs available?
• Who is responsible for design?

Technical

• Are there existing systems or infrastructure constraints?
• Are there technology restrictions?

Security

• What information is sensitive?
• What access restrictions are required?

Compliance

• Are there regulatory, contractual or internal requirements?

Delivery

• What is the required launch date?
• What milestones matter?

Commercial

• What budget range is available?
• Is the project expected to be one phase or multiple phases?

Ownership

• Who will own the code, infrastructure and accounts?

Support

• What is expected after launch?

If several of these questions have no answer, the project may need more discovery before development begins.

---

The Ortem Client Readiness Framework

At Ortem Technologies, a useful way to think about client readiness is through seven questions:

1. What problem are we solving?

The business problem must be clear.

2. Who are we solving it for?

The primary users must be identified.

3. What needs to change?

The desired future state must be understood.

4. What must the first release accomplish?

MVP priorities must be established.

5. What existing systems and constraints do we need to respect?

Dependencies and limitations must be visible.

6. Who makes decisions?

Stakeholders and approval responsibilities must be clear.

7. What does success look like?

The project must have meaningful success criteria.

If these seven questions have clear answers, the development team has a much stronger foundation for turning the business idea into a software project.

---

What a Client Should Bring to the First Discovery Meeting

A client does not need a finished requirements document before talking to a development company.

A useful starting package can simply contain:

Business

• Short business overview
• Problem statement
• Project objective

Product

• Main user types
• Core workflow
• Initial feature ideas
• MVP priorities

Existing environment

• Existing software
• Existing website or application
• Existing integrations
• Existing data

Business constraints

• Target launch period
• Budget expectation
• Security or compliance requirements

People

• Main decision-maker
• Product owner
• Technical contact, if available

This is enough to start a productive discovery process.

The development team can help turn that information into formal requirements, scope, technical specifications and architecture.

---

What a Client Should Not Do

There are also several things clients should avoid.

Do not assume every idea belongs in the first release

Prioritize.

Do not hide existing system limitations

Technical constraints discovered late can affect the entire architecture.

Do not treat every requested feature as equally important

The team needs to know what actually matters.

Do not choose technology simply because a competitor uses it

The right architecture depends on your requirements.

Do not wait until the end to discuss ownership

Ownership should be clear from the beginning.

Do not assume integrations are simple

An external system can significantly affect project design.

Do not keep important business rules in conversations only

Write them down.

Do not expect developers to invent business policy

The technology team can implement rules, but the business must define the rules.

---

A Simple Example of Client Readiness

Imagine a company wants to build a service marketplace.

A weak brief might say:

We need a marketplace where customers can find service providers.

A stronger client brief might say:

Business problem

Customers currently find service providers through phone calls and referrals, which makes discovery and comparison difficult.

Users

• Customers
• Service providers
• Administrators

Core workflow

Customer searches services → views provider → selects provider → requests service → provider accepts → customer receives confirmation.

MVP

• Customer registration
• Provider registration
• Search
• Provider profiles
• Service request
• Basic messaging
• Notifications
• Administration

Future

• Payments
• Reviews
• Subscriptions
• AI recommendations
• Native mobile applications

Existing systems

Existing customer database must be considered.

Timeline

Initial web release required before a defined business milestone.

Ownership

Client will own the source code, infrastructure accounts and production data.

That gives a development team dramatically more useful information than:

Build a marketplace.

---

Final Takeaway

A client does not need to be a software engineer to prepare for a software project.

The client needs to understand the business.

Before development begins, the client should provide enough information to explain:

What problem needs to be solved.

Why it matters.

Who the software is for.

How the business works today.

What should change.

What the software must accomplish.

What the first release must include.

What business rules must be enforced.

What data is involved.

Which systems need to integrate.

What security or compliance requirements exist.

What constraints the project has.

Who makes decisions.

What the timeline and budget expectations are.

How success will be measured.

The client does not need to arrive with the architecture already designed.

The client does not need to choose the technology stack.

The client does not need to write API specifications.

The development team should contribute that technical expertise.

What the development team cannot replace is the client's knowledge of the business.

That knowledge is what allows the technical team to build the right system rather than simply build something that works.

At Ortem Technologies, we believe project readiness begins with a simple principle:

The client knows the business. The development team knows how to turn that business requirement into software. The best projects start when both sides make that knowledge explicit.

When the business problem, users, workflows, priorities, constraints and success criteria are clear, technology becomes much easier to design.

And when those things are unclear, no choice of programming language, framework or development team can fully compensate for it.

Once you have that information ready, the next step is choosing who you hand it to — see our guide to what questions to ask before hiring a software development company.

Not sure whether you have enough to bring to a first conversation? That is exactly what our discovery process for custom software development is built to work through with you.

Start your project discovery →