Hiring a software development company often requires an upfront payment before the team starts working.
That is normal.
The development company may need to reserve developers, begin discovery, create designs, configure the project, and allocate other resources before you receive the finished product.
However, an important question remains:
How much should you actually pay upfront?
There is no universal percentage that fits every software project. Recent software-contract guidance commonly describes initial deposits around 20%–40%, with roughly 25%–33% appearing frequently for milestone-based projects. The rest is then paid as agreed deliverables are completed and accepted. Stardelite
The percentage alone is not the most important part.
You should also understand what the upfront payment covers, what you receive at the first milestone, how later payments are triggered, and what happens if the project stops early.
This guide explains software development upfront payments, milestone structures, warning signs, and the questions businesses should ask before sending the first payment.
Why Do Software Development Companies Ask for an Upfront Payment?
A software company usually begins spending resources before it delivers the final product.
For example, the team may need to:
- Review requirements
- Conduct discovery
- Plan the project
- Assign developers
- Create wireframes
- Start UI/UX design
- Set up development environments
- Plan the database
- Prepare technical architecture
- Reserve development capacity
An upfront payment shows that the client is committed to the project.
At the same time, it reduces the development company’s risk of reserving employees and beginning work for a client who later disappears.
Therefore, requesting a reasonable deposit is not automatically a warning sign.
The real question is whether the payment terms fairly distribute risk between the client and development company.
Is 20%–30% Upfront Reasonable?
For many defined software projects, an initial payment in the 20%–30% range can be a reasonable starting structure.
Several current contract guides place deposits around this level. For example, one software-contract guide describes roughly 25%–33% as common for milestone-based arrangements, while another describes deposits around 20%–40% depending on the project. Story LLP
Suppose your software project costs €30,000.
A 25% upfront payment would be:
€7,500 upfront
The remaining €22,500 could then be divided across meaningful development milestones.
However, this is an example rather than a rule.
A small project, short engagement, highly specialized project, or established client relationship may use different payment terms.
What About a 30% Upfront Payment?
A 30% deposit is another structure you may encounter.
For example, imagine a €20,000 mobile app project.
The payment schedule could be structured around:
30% — Project start
30% — Approved design and initial development milestone
20% — Major functionality completed and available for testing
20% — Final acceptance and handover
The exact percentages can change.
What matters more is that later payments connect to clear, verifiable progress rather than vague promises.
Recent guidance on software-development contracts similarly recommends tying milestone payments to identifiable deliverables and acceptance. Stardelite
Is 50% Upfront Too Much?
A 50% deposit is not automatically unreasonable.
Smaller projects and freelancers sometimes use a 50/50 structure:
50% before work starts
50% after completion
For example, this can be easier to manage on a short, clearly defined €2,000 project than on a €100,000 custom software platform.
Project size matters.
Imagine paying €1,000 upfront on a €2,000 project.
Now compare that with paying €50,000 upfront on a €100,000 project before receiving any meaningful deliverable.
Although the percentage is identical, the financial exposure is very different.
For larger projects, more milestones can distribute risk more evenly.
One recent software payment guide notes that smaller defined projects may reasonably use full payment or a 50/50 arrangement, while larger projects often benefit from milestone or periodic billing. Vertinus
Should You Pay 100% Upfront?
For a substantial custom software project, paying the entire amount before meaningful work has been delivered creates significant client risk.
Once the complete amount has been paid, you have less financial protection if the project becomes delayed, disputed, or abandoned.
Milestone payments provide a different structure.
Instead of transferring the complete budget at the beginning, you release payments as the development team reaches agreed stages.
For example:
20% — Contract and project start
20% — Design approved
30% — Core software available for testing
20% — Final functionality accepted
10% — Launch and final handover
The exact split is negotiable.
The important principle is connecting payments with meaningful progress.
What Is a Milestone Payment?
A milestone payment becomes due when the development team reaches an agreed project stage.
Good milestones should be specific enough for both parties to understand what has been completed.
For example:
“Core customer booking workflow completed and available in the staging environment for client testing.”
That is much clearer than:
“Development Phase 2 completed.”
A milestone may relate to:
- Approved wireframes
- Approved UI/UX designs
- Working prototype
- Completed authentication
- Core feature set
- Beta version
- User acceptance testing
- Production deployment
- Source-code handover
The contract should also explain how you review and approve each milestone.
Why Are Milestone Payments Useful?
Milestones can protect both sides.
The development company receives money as it completes agreed work.
Meanwhile, the client does not need to pay the complete project price before seeing meaningful progress.
For example, consider a six-month software project.
Paying 100% at the beginning places most financial risk on the client.
Paying 100% only after six months places substantial financial risk on the development company.
Milestones distribute those risks across the project.
That is why milestone structures commonly appear in fixed-price software agreements. Stardelite
A Simple Payment Structure Example
Imagine your business is building a €40,000 customer booking platform.
The project includes mobile apps, backend development, an admin dashboard, payments, notifications, and testing.
A possible payment structure could be:
Project Start — 25%
You pay €10,000 after signing the agreement.
The team begins discovery, planning, design, and technical setup.
Design Approval — 20%
You pay €8,000 after reviewing and approving the agreed design deliverables.
Core Development Milestone — 25%
You pay €10,000 when the agreed core functionality becomes available for review.
Testing and Acceptance — 20%
You pay €8,000 after the agreed functionality reaches the defined acceptance stage.
Final Handover — 10%
You pay the final €4,000 according to the agreed handover conditions.
This is only an illustrative structure.
Your actual payment schedule should reflect your project’s length, complexity, development model, and contract.
Upfront Payment for Small Software Projects
Smaller projects may use simpler payment structures.
For example, imagine a €1,500 website modification project that takes two weeks.
Creating six different payment milestones may add unnecessary administration.
The developer might instead request:
50% before starting
and
50% after completion
For very small projects, some providers may even require complete payment upfront.
Therefore, you should consider both the percentage and the actual amount at risk.
Upfront Payment for Medium-Sized Projects
Medium-sized projects usually provide more opportunities for milestone payments.
Suppose you are building a €25,000 mobile application.
Instead of paying €12,500 immediately under a 50/50 arrangement, the parties could divide the project into more stages.
For example:
25% — Start
25% — Design approval
25% — Development milestone
15% — Testing and acceptance
10% — Final delivery
Again, these percentages are examples.
The key advantage is that payments follow progress.
Upfront Payment for Large Software Projects
Large projects require greater attention to payment structure.
Imagine your business is investing €200,000 in custom software.
Even a 30% upfront payment would equal €60,000.
At this scale, you may want more detailed phases and commercial protections.
For example, the project could begin with a separate paid discovery stage.
Once discovery finishes, the company can define the next development phase more accurately.
Large projects may also use monthly billing, sprint billing, Time and Materials, dedicated teams, or detailed milestone structures rather than one large deposit followed by one final payment.
The appropriate arrangement depends on the engagement model.
Upfront Payments for Fixed-Price Projects
Fixed-price projects often use an initial deposit followed by milestone payments.
The company first defines the project scope.
Both parties then agree on the price and payment schedule.
For example:
25% — Contract signing
25% — Design approval
30% — Development milestone
20% — Final acceptance
The advantage is that the client knows the expected price for the agreed scope.
However, additional requirements can still create additional charges.
Therefore, the contract should explain how change requests work.
What About Time and Materials Projects?
Time and Materials projects work differently.
Instead of purchasing one completely defined project for a fixed amount, you pay for the resources used during development.
The company may invoice weekly, biweekly, monthly, or according to another agreed schedule.
Some development companies may request payment for the first development period in advance.
For example, you might prepay for a two-week development sprint.
The team completes the sprint, reports the work, and you decide whether to continue with the next period.
This can reduce the need for a large percentage-based project deposit.
However, you still need spending limits, estimates, progress reports, and clear invoicing terms.
Should You Pay Before Signing a Contract?
For a substantial software project, avoid transferring a significant deposit based only on informal conversations.
Before paying, you should understand what you are purchasing.
At minimum, the written agreement or project documentation should clearly address important commercial terms such as:
- Project scope
- Deliverables
- Price
- Payment schedule
- Timeline or project stages
- Client responsibilities
- Change requests
- Ownership
- Cancellation
- Handover
- Support
The level of documentation should match the size and complexity of the project.
For significant projects, professional legal review may also be appropriate.
What Should the First Payment Actually Cover?
Do not focus only on the percentage.
Ask:
“What will happen after I make this payment?”
For example, the first payment might cover:
- Discovery workshops
- Requirement documentation
- Project planning
- UI/UX design
- Technical planning
- Environment setup
- Initial development
- Team reservation
The proposal should make the first phase understandable.
If you pay €10,000 upfront, you should know what work the company plans to perform before asking for the next payment.
Tie Payments to Deliverables, Not Just Dates
Imagine your contract says:
“25% payment after 30 days.”
Thirty days passing does not necessarily prove that meaningful work has been completed.
A stronger milestone could say that payment becomes due after specified functionality is delivered for review and meets agreed acceptance conditions.
Recent software-contract guidance similarly recommends connecting milestone payments to verifiable outcomes rather than simply calendar dates. CivSec S.M.A.R.T
This approach makes progress easier to understand.
Define Acceptance Criteria
A milestone is much more useful when both parties understand what counts as complete.
Suppose one milestone says:
“Payment after mobile app development.”
That is vague.
Does it mean every screen exists?
Do payments need to work?
Should notifications work?
Does the app need to pass testing?
Instead, define the expected deliverable and review process.
For example, the milestone might require agreed customer registration, login, product browsing, and checkout workflows to work in a test environment.
Clear acceptance criteria reduce arguments about whether a milestone has actually been completed.
Do Not Leave the Final Payment Too Early
The final payment should connect to a meaningful final stage defined in your contract.
Depending on the agreement, that could involve:
- Acceptance testing
- Production deployment
- Source-code delivery
- Documentation
- Credentials
- Design files
- Agreed account access
- Final handover
Avoid creating a payment schedule where almost the entire project value has been paid while significant deliverables remain outstanding.
For some larger projects, parties may also negotiate a small retention or holdback until an agreed post-launch period ends, although whether that makes sense depends on the contract and negotiating position. Starter
Check Source-Code Access
Payment is only one part of project protection.
You should also understand how source-code access works during development.
Will your business have access to the project repository?
When does ownership transfer?
What happens to completed work if the project ends early?
Will you receive the latest source code after paying for completed milestones?
These questions become particularly important for larger projects.
The contract should clearly define source-code ownership and handover rather than leaving both sides to make assumptions.
Check Ownership of Important Accounts
Your project may depend on:
- Cloud hosting
- Domain accounts
- App Store accounts
- Google Play accounts
- Payment providers
- Analytics
- Email services
- SMS providers
- Other third-party platforms
Where appropriate, important business accounts should remain under your company’s ownership.
The development company can receive the access it needs to complete the project.
This makes future handover easier if you later change development providers.
What Happens If You Cancel the Project?
Discuss this before making the upfront payment.
Suppose you pay a 30% deposit.
After the first development phase, your company changes direction and decides to stop the project.
What happens?
The contract should explain how cancellation works.
Important questions include:
- Is the deposit refundable?
- Which completed work must be paid for?
- What happens to unfinished work?
- Do you receive completed source code?
- Do you receive design files?
- What happens to third-party expenses?
- How much notice is required?
Do not assume that an upfront payment will automatically be refunded if you cancel.
Read the actual agreement.
Is a Non-Refundable Deposit Normal?
Some software companies use non-refundable deposits because they reserve team capacity and begin work immediately.
However, the word non-refundable should not be considered in isolation.
Understand what happens if the development company fails to start or deliver the agreed work.
Also check what happens when either party terminates the contract.
The contract should clearly explain the consequences.
For a significant investment, consider obtaining legal advice before accepting terms you do not fully understand.
Warning Signs Before Making a Large Upfront Payment
A large deposit deserves additional review when the project has:
- No written scope
- No signed agreement
- No clear deliverables
- No milestone schedule
- No acceptance process
- Unclear source-code ownership
- No cancellation terms
- No explanation of additional charges
- No clear company identity or business information
- Pressure to transfer the entire amount immediately
One warning sign does not automatically prove that a company is unreliable.
However, several together should encourage you to ask more questions before transferring money.
What About a Company Asking for 50% Upfront?
Do not automatically reject it.
Instead, understand why.
For a small project, 50% may represent a modest amount and cover most of the initial work.
For a large project, you could ask whether the first payment can be divided.
For example, instead of:
50% immediately
you could discuss:
25% at signing
25% after approved designs or another early milestone
This still provides the development company with early cash flow while reducing the client’s initial exposure.
Whether the provider accepts that structure depends on the project and negotiation.
What About 0% Upfront?
Zero upfront payment sounds attractive to the client.
However, it places nearly all early financial risk on the development company.
Established agencies may be unwilling to reserve a development team for several weeks or months without receiving payment.
Therefore, the goal should not necessarily be to negotiate the lowest possible deposit.
The goal is to create a payment structure that is reasonable for both sides.
A good development partnership requires both the client and provider to have meaningful commitments.
Should You Use Escrow?
Escrow can be useful in some situations, particularly when working through platforms or with a new provider.
Instead of transferring the money directly to the developer, funds can be held according to the escrow arrangement and released when agreed conditions are satisfied.
However, escrow services can have fees and specific dispute procedures.
Therefore, review the terms before using one.
For an established development company with a signed contract and clear milestone process, direct business payments may be more common.
Example: €50,000 Mobile App Project
Imagine your company wants to build a mobile marketplace.
The project includes:
- Android and iOS applications
- Customer accounts
- Seller accounts
- Product listings
- Search
- Shopping cart
- Online payments
- Order management
- Notifications
- Admin dashboard
- Backend
- Testing
- Deployment
Instead of paying €25,000 or €50,000 immediately, the parties could structure payments around project progress.
For example:
20% — Project Start
€10,000 after signing and beginning discovery.
20% — Design Approval
€10,000 after agreed UI/UX deliverables are reviewed and approved.
25% — Core Development
€12,500 when agreed core workflows are available for testing.
20% — Feature Completion and Acceptance Testing
€10,000 when the defined feature set reaches the agreed testing stage.
15% — Final Delivery
€7,500 according to the agreed launch and handover requirements.
Again, this is an example rather than a universal recommendation.
Your contract should reflect your specific project.
Questions to Ask Before Paying Upfront
Before transferring the first payment, ask:
- What percentage is required upfront?
- What work does the upfront payment cover?
- When will work begin?
- What will I receive before the next payment?
- What are the project milestones?
- How will each milestone be approved?
- What happens if a milestone does not meet the requirements?
- How are additional features charged?
- What happens if the project is delayed?
- What happens if either side cancels?
- Is the deposit refundable or non-refundable?
- When will I receive source-code access?
- Who owns completed work?
- What will I receive at final handover?
- Is any payment retained until final acceptance?
If the company cannot clearly answer important questions about a substantial project, clarify them before paying.
Common Mistakes With Software Development Payments
Paying 100% before meaningful work begins
This can unnecessarily increase client exposure on substantial custom projects.
Refusing every upfront payment
Developers also face financial risk.
A reasonable deposit can reserve the team and allow the company to begin work.
Paying milestones based only on dates
Connect payments to meaningful project progress where possible.
Ignoring acceptance criteria
Define what you need to review before approving major milestones.
Forgetting source-code ownership
Understand when ownership transfers and what happens if the project ends early.
Paying for undocumented additional work
When a new feature changes cost or timeline significantly, document and approve the change.
Ignoring taxes and third-party expenses
Understand whether quoted prices include applicable taxes and whether hosting, APIs, app store accounts, and other external costs are separate.
Frequently Asked Questions
Is 30% upfront normal for software development?
It can be. Current software-contract guidance commonly places milestone-project deposits around 20%–40%, with 25%–33% also frequently cited. The appropriate amount depends on the project and agreement. Stardelite
Is 50% upfront too much?
Not necessarily. A 50/50 arrangement can make sense for some small, short, clearly defined projects. For larger projects, dividing payments into more milestones can reduce the amount either side has at risk.
Should I pay a developer 100% upfront?
For substantial custom development, milestone payments usually provide better balance than paying the entire project price before meaningful delivery.
What is a good payment structure for software development?
One practical structure is an initial deposit followed by several payments tied to defined deliverables, with the final amount connected to acceptance and handover. The percentages should reflect the project’s size and stages. Stardelite
Should the upfront payment be refundable?
That depends on the contract. Some providers use non-refundable deposits because they reserve team capacity and begin work immediately. Review the cancellation and failure-to-deliver terms carefully.
When should I make the final payment?
The contract should connect final payment to clearly defined final deliverables or acceptance conditions, such as testing, deployment, documentation, source-code handover, or other agreed requirements.
Should I have a contract before paying?
For a substantial software project, written terms should clearly explain the scope, price, payment schedule, deliverables, ownership, changes, cancellation, and other important responsibilities before you transfer a significant amount.
Conclusion
There is no single upfront payment percentage that works for every software development project.
For many milestone-based projects, roughly 20%–30% upfront is a common starting range, while other legitimate arrangements may use smaller or larger deposits depending on project size, scope, duration, and risk. Stardelite
However, the percentage should not be your only concern.
A €5,000 deposit attached to a clear contract, defined first phase, measurable deliverables, source-code terms, and milestone approvals can represent a very different risk from the same payment attached to a vague promise.
Therefore, focus on the complete payment structure.
Understand what your first payment buys, connect later payments to meaningful progress, define acceptance criteria, clarify ownership and cancellation terms, and keep a meaningful part of the payment connected to final delivery.
A balanced payment schedule protects both sides: the development company receives enough commitment to begin work, while the client avoids paying most of the project budget before receiving meaningful results.
