How Custom Software Projects Are Scoped, Billed, and Accepted

The stages of a custom software engagement

It helps to separate five things that are often collapsed into one: the inquiry, discovery, the proposal, the master agreement, and the statement of work. Each has a different purpose, and each has a different level of commitment.

The inquiry

An inquiry is a request to start a conversation. It usually describes a problem, a rough outcome, and any constraints already known. Submitting an inquiry through the proposal request form does not create an order, does not commit either party to anything, and does not collect payment. No card details are requested and no invoice is issued at this stage. The purpose is to determine whether the work is a reasonable fit and what a responsible next step would be.

Discovery

Discovery is where a vague objective becomes a described system. It covers the current process, the users, the systems involved, the data, the rules, and the constraints. For a small, well-understood scope, discovery may be a single working session. For anything larger, it is usually a defined engagement with its own deliverable, such as a written assessment or blueprint.

Discovery exists to make the eventual price and schedule responsible rather than optimistic. A quote produced without it is either padded with contingency or likely to change later.

The proposal

A proposal converts discovery findings into a described engagement: what will be built, for whom, under what assumptions, with which exclusions, and on what commercial terms. A proposal is an offer. It is not a contract until it is accepted in writing.

Master agreement and statement of work

Two documents usually govern the relationship. A master services agreement (MSA) sets the durable terms that rarely change between projects: confidentiality, intellectual property, liability, payment terms, and termination. A statement of work (SOW) sets the specifics of one engagement: scope, deliverables, milestones, fees, schedule assumptions, and acceptance criteria.

Separating them means later work does not require renegotiating the whole relationship. A second project becomes a second SOW under the same MSA. Detailed commercial and billing terms are published in the payment and billing policy and the service fulfillment policy.

What a well-defined scope contains

Scope is not a feature list. A feature list without context invites disagreement about intent. A usable scope definition contains six elements.

• Objectives — the business outcome the software is meant to support, stated in terms a non-technical stakeholder would recognize.
• Users — who will use the system, in what role, and with what level of permission.
• Assumptions — conditions taken as true when the estimate was produced, such as access to a system, availability of a subject matter expert, or the existence of a documented data format.
• Constraints — fixed conditions the solution must respect: platforms, hosting, compliance obligations, existing systems, or a hard external deadline.
• Exclusions — work explicitly not included. This is the single most valuable section of a scope document, and the most often omitted.
• Deliverables — the concrete artifacts to be handed over: the running software, source code, configuration, documentation, and any migration output.

Assumptions deserve particular attention. When an assumption turns out to be false — an API is undocumented, a data export is incomplete, an approver is unavailable for three weeks — the schedule or the scope has to move. Writing assumptions down makes that conversation factual instead of adversarial. The same discipline applies to scoping any custom software project.

Engagement models

Different problems suit different commercial structures. Northbridge publishes its typical engagement models so the structure can be chosen deliberately rather than by default.

• Fixed-scope engagements suit work whose boundaries can be described precisely in advance: a defined assessment, a specific integration, a contained internal tool. Price and deliverable are agreed up front, and changes are handled as documented change requests.
• Phased delivery suits larger systems. The engagement is divided into sequential phases, each with its own deliverable and acceptance step. Later phases are scoped with the knowledge gained from earlier ones, which reduces the risk of pricing work nobody understands yet.
• Ongoing engagements suit maintenance, support, and continuous improvement of a system already in production. Work is prioritized on a recurring basis rather than defined once.

No model is inherently better. Fixed scope trades flexibility for certainty. Phased delivery trades certainty about the whole for accuracy on each part. Ongoing work trades a defined endpoint for responsiveness.

How the work is billed

Billing should be predictable and tied to something observable. Three practices make that possible.

Deposits where applicable

Some engagements begin with a deposit before scheduled work starts. Whether a deposit applies, and how much it is, depends on the engagement and is stated in the SOW. There is no universal deposit figure, and none is published here.

Milestone-based invoicing

For phased or larger engagements, invoicing is tied to defined milestones rather than elapsed time. A milestone is a described deliverable, not a date on a calendar. This keeps the commercial relationship aligned with progress that both parties can see. Invoices are issued directly; the website does not process instant checkout for custom engagements.

Documented change requests

Scope changes are normal. Undocumented scope changes are the problem. When a new requirement appears, it is written up as a change request describing what changes, why, the effect on schedule, and the effect on fees. Work on the change begins after it is approved in writing. This protects both sides: the customer is never surprised by an invoice, and the delivery team is never asked to absorb unpriced work.

Review, acceptance, and handoff

Acceptance criteria belong in the SOW, written before development starts. They describe how a deliverable will be evaluated: which scenarios must work, which data must reconcile, which users must be able to complete which tasks. Criteria written at the end of a project tend to reflect whatever the reviewer noticed that week.

A typical review cycle gives the customer a defined window to test the deliverable against the criteria and report issues. Items that fall within the agreed criteria are corrected as part of the engagement. Items outside them are handled as change requests. Delivery is electronic — access to the running system, source code, configuration, and documentation — and the specific handoff artifacts are listed in the SOW rather than assumed.

The delivery expectations for each engagement type are described in the service fulfillment policy, and cancellation and refund handling is described in the refunds policy.

Optional ongoing support

Acceptance is not the end of a system's life. After handoff, an optional ongoing engagement can cover monitoring, defect correction, dependency updates, and incremental improvement. This is arranged separately from the build so a customer is never obligated to a recurring commitment in order to receive the original deliverable.

Why an inquiry is not an order

It is worth restating plainly. Submitting a form on this site starts a conversation. It does not create a contract, does not reserve capacity, and does not charge anything. Payment only follows an agreement that describes the work in writing. That sequence exists so that the first financial commitment happens after both parties understand what is being bought. The full process is described on the how we work page.

Key takeaways

• Inquiry, discovery, proposal, MSA, and SOW are five distinct steps with different levels of commitment.
• Exclusions and assumptions are the most valuable parts of a scope document.
• Choose an engagement model deliberately: fixed scope, phased delivery, or ongoing.
• Tie invoicing to described milestones, not elapsed calendar time.
• Write acceptance criteria before development begins, not after.
• Handle every scope change as a written, approved change request.
• Submitting an inquiry does not create an order or collect payment.