What to Prepare Before Outsourcing Software Development

Start with what is difficult today.

“We need a customer portal” describes a possible solution. It does not explain which tasks the portal needs to support.

Use real examples where possible. Screenshots of an existing workflow or a sample form can be more useful than a long list of software features.

Different users may need different actions and permissions.

A customer, staff member and administrator should not automatically receive the same access.

Prepare a simple role list:

Choose one important task and describe it from beginning to end.

For a booking workflow, that might be:

1. 1A customer chooses a service.
2. 2Available times are displayed.
3. 3The customer submits the required information.
4. 4The booking is recorded.
5. 5Staff receive the details.
6. 6The customer receives confirmation.

You do not need to solve every technical detail yourself. Recording the questions helps the supplier identify what needs clarification.

An early feature list often combines essential functionality with improvements that could wait.

Sort requirements into three groups:

If the software is already running, prepare a factual summary of its current state.

Include what you know:

Mark unknown information as unknown.

Avoid describing an application as “90% finished” unless that figure has a clear basis. A list of completed workflows, unfinished work and observed failures is more useful.

An application technical assessment can help establish the condition of an unfamiliar project.

You can prepare a small collection rather than a polished specification.

Useful materials include:

• Existing requirements.
• Wireframes or designs.
• Screenshots.
• A current task list.
• Example reports or documents.
• API documentation.
• Previous test results.
• Error messages and reproduction steps.
• Setup or deployment instructions.

Remove unnecessary personal or confidential information before sharing examples.

If another supplier is leaving, ask what handover material is available. Our software project takeover service explains the transition questions to address, or you can Plan the handover before changing developers.

An integration can affect scope, cost and testing.

List each connected system and what needs to happen between them:

An external developer still needs priorities, answers and approval.

Identify someone in your business who can:

• Clarify requirements.
• Set priorities.
• Approve designs and content.
• Review completed work.
• Authorise changes.
• Make release decisions.

Be realistic about their availability.

If your team cannot provide daily direction or technical review, explain that early. The engagement may need additional coordination or oversight.

For ongoing capacity, explore our dedicated developer hiring options.

A budget range helps the discussion focus on an achievable scope.

You can ask the supplier to explain what fits within it and which requirements would need a later stage.

Describe deadlines accurately:

• Is there a fixed event or contractual dependency?
• Is the date a preference?
• What happens if delivery moves?
• Are designs, content and access ready?

A supplier cannot assess a deadline properly if it is unclear which inputs will arrive later.

Our developer cost guide explains the difference between an hourly rate and a complete project budget.

Before development starts, explain what the first delivery needs to demonstrate.

An acceptance criterion should be observable.

The review should also account for relevant failures and permission boundaries.

Identify who will test the workflow, where feedback will be recorded and who can accept completion.

This helps avoid a situation where “finished” means different things to the business and developer.

Know which accounts the developer will need, but do not share passwords in an initial enquiry.

Prepare an access list covering relevant repositories, environments and services.

Agree on:

• Appropriate collaborator permissions.
• Who approves access.
• Whether a test environment is available.
• How credentials are shared.
• How access will be removed or changed later.

Your business should understand who controls its essential accounts and assets.

Read how developer hiring works for the steps between initial requirements and onboarding.

A completed build still needs an owner.

Clarify who will:

• Operate the application.
• Manage users and content.
• Pay service subscriptions.
• Handle reported problems.
• Approve updates.
• Maintain documentation.

If ongoing support is needed, define its coverage separately.

Our application maintenance service explains the responsibilities to discuss.

Share:

• A short description of the problem.
• Whether the project is new or existing.
• The main work required.
• Your preferred timing.
• Any known technology requirements.
• A budget range, if available.

Mention supporting documents rather than sending sensitive material immediately.

For a project with major unknowns, ask for a defined discovery or assessment proposal before requesting a final build price.