A fair custom software payment schedule gives the developer enough commitment to reserve time while limiting the buyer's exposure before useful work exists. The schedule should connect money to a written scope, time worked, identifiable deliverables, or accepted milestones.

A request for a deposit is not automatically a warning. Paying an entire vague project in advance is. The important questions are what the payment covers, when work begins, what evidence the client receives, how cancellation is handled, and who controls the work completed so far.

Quick answer: smaller, defined projects may reasonably be paid in full or 50/50. Larger or uncertain projects usually benefit from a paid discovery phase followed by milestone or periodic billing. Never let the payment schedule substitute for scope, acceptance criteria, repository access, ownership terms, and a cancellation process.

Why developers request money before starting

A developer may decline other work, schedule staff, create project infrastructure, purchase approved services, and begin discovery before the client sees a finished screen. An initial payment confirms that the client has authority and budget to proceed.

The amount should still be proportionate to the commitment. A short, two-day website adjustment and a year-long operational platform should not use the same risk structure.

Common software payment structures

Payment in full before work

Full payment can be reasonable for a small, tightly defined engagement with a trusted provider: a focused assessment, a minor integration repair, or a short proof of concept. It is harder to justify for a large build with unresolved requirements.

If paying in full, require written deliverables, a start window, access to work in progress, cancellation terms, and a clear refund or earned-fee rule.

Fifty percent to start and fifty percent at completion

A 50/50 split is easy to understand and works for many small projects. The initial payment reserves the work; the final payment follows completion and acceptance.

Define completion objectively. It might mean the agreed scenarios pass in a staging environment and the approved handoff package is ready. It should not mean merely that the provider says the project is complete.

Milestone payments

Milestones are useful when the system can be divided into complete slices. A schedule might use discovery, working first workflow, integration and migration rehearsal, pilot release, and production handoff.

A useful milestone produces evidence. "Backend 80 percent complete" is difficult for a buyer to inspect. "Managers can create, approve, and export a purchase request using representative data" is much clearer.

Weekly or monthly time-and-materials invoices

Periodic billing fits evolving work, retained development, or a project in which priorities may change. The buyer pays for verified time and approved expenses rather than a promised feature total.

This structure needs an hourly rate, initial estimate, reporting cadence, budget alerts, approval boundary, and the right to pause. An open-ended hourly agreement with no estimate is not financially controlled.

Paid discovery followed by a separate build

When data, integrations, rules, or exceptions are unclear, a short discovery phase can reduce risk before either party commits to the full build.

Discovery should produce portable artifacts: requirements, workflows, data findings, prototype decisions, architecture options, risks, release boundaries, and an implementation estimate. The buyer should be able to use those deliverables even if another developer performs the build.

How milestone payments should be defined

For each payment, record:

  • The deliverable or billing period.
  • The user scenarios or documents included.
  • The environment in which the work will be reviewed.
  • The acceptance tests and known exclusions.
  • The client's review deadline and responsible approver.
  • How defects differ from new requirements.
  • The amount due and payment deadline.
  • What happens if the milestone is rejected or feedback is late.

A milestone may still contain minor defects. The agreement should state which defects block acceptance, which can enter an agreed correction list, and when the related payment becomes due.

Example schedule for a $5,000 first release

At Vertinus's published $49.99 hourly rate, a $5,000 budget represents roughly 100 hours. A focused internal workflow might use a schedule such as:

  • 50 percent to begin: approve the written scope, estimate, schedule, first-release boundary, and account responsibilities.
  • Working reviews during development: inspect complete scenarios using representative data rather than waiting for the final day.
  • Final balance at acceptance: confirm the agreed behavior, receive the completion materials, and authorize production handoff.

The related guide, what a $5,000 custom software budget can build, shows why the release boundary matters more than the round number.

How Vertinus billing works

Vertinus provides a written scope and estimated hours before project work begins. The client may pay in full or use a 50/50 schedule for the approved estimate.

Project work is billed at $49.99 per hour for time actually worked, up to the approved estimate. If completing the agreed scope requires more hours than estimated, Vertinus absorbs those extra hours. New requirements are estimated and approved separately.

That structure combines an hourly record with a ceiling for the agreed work. The project-specific written scope controls the deliverables and schedule.

Separate project payments from third-party costs

Hosting, databases, email, text messages, payment processing, mapping, identity, file storage, software subscriptions, app-store accounts, certificates, and specialist reviews may create outside charges.

The proposal should name who purchases each service, who owns the account, whether the charge is recurring, what volume assumption was used, and what happens if the provider changes its price.

Whenever practical, the client should own production accounts and grant the developer appropriate access. A low development deposit does not protect the buyer if the provider controls the domain, cloud account, repository, and data.

Connect final payment to a real handoff

Before the final payment event, confirm the agreed items are ready:

  • Completed code and project-specific interface work.
  • Repository and production-account access.
  • Deployment and environment information.
  • Data export or migration reconciliation.
  • Administrator guidance and credentials transfer.
  • Known issues, deferred work, and support terms.
  • Third-party licenses and recurring-cost inventory.

Under Vertinus's terms, the client receives ownership of the completed project code, interface work, and project-specific deliverables after final payment. Third-party assets remain subject to their own licenses.

Plan for scope changes

A buyer should be able to suggest an improvement without accidentally authorizing an unknown invoice. The agreement should distinguish clarification, defect correction, revision within scope, and a new requirement.

For a change, record the requested behavior, effect on existing work, additional hours or price, schedule impact, and approval. Continue the original scope while the change is considered when practical.

Plan for cancellation before it is needed

The contract should explain notice, payment for work completed, treatment of unearned amounts, access to unfinished code, return or deletion of data, transfer of accounts, and reasonable transition help.

Do not assume that a "nonrefundable deposit" answers all of these questions. A qualified legal or accounting professional can review the agreement for the applicable business and jurisdiction.

Payment warning signs

  • The provider requests the full price for a large, undefined project.
  • Payments are tied only to calendar dates, regardless of progress or evidence.
  • No written scope or approved estimate exists.
  • The provider refuses ongoing repository or account visibility.
  • "Completion" and acceptance are undefined.
  • New work can be added without written client approval.
  • Third-party and recurring charges are hidden.
  • Cancellation means losing all work, accounts, or data.
  • Final payment is due before any realistic acceptance test.

Choose a schedule that preserves leverage for both sides

The developer should not finance months of approved work. The client should not finance a vague promise. A good schedule keeps commitment, evidence, access, payment, and ownership moving together.

Use the software development contract checklist to review the rest of the agreement before signing.

Send Vertinus the workflow and working budget. We will return a written scope, estimated hours, payment options, ownership terms, and the next review point before work begins.