Red flags in a software development proposal

A software proposal is a document about disagreement. Everything in it that reads pleasantly describes a project where nothing goes wrong, and that project does not exist. What earns your attention is what happens when you change your mind, when an assumption turns out false, and when two people read the same line differently. So read for the absences: a missing clause is not a tidy omission you settle later, it is the clause you will argue about.

That includes ours. The last section names what a sceptical reader should push back on in an EdgeBrain proposal, and what a fair answer looks like.

Three questions the price is downstream of

What am I getting, written specifically enough that I could tell whether I got it. What happens when the scope changes, because it will. Who owns the result, and from when.

A document answering those three can be compared with another that does. One answering none cannot be compared with anything, which is frequently why it was written that way. The lowest bid in a stack of three is usually the one that answered the fewest questions, and the gap is rarely efficiency. It is scope nobody wrote down, which you pay for later with no leverage. The artefacts that make a quote honest before anyone writes one are in writing a spec a developer can quote.

Go line by line, and read the silences

A number with no scope attached

The commonest defect, easy to miss because a total looks like an answer. A price means nothing without an itemised list of what produces it: screens or modules named individually, integrations named by vendor, environments named, and explicit lines for the work that is not features. Testing. Deployment. Data migration. Project management. Then ask of each line, how would we know this is finished. Where the answer is a conversation rather than an observation, that line is a placeholder, and placeholders are where the budget goes.

“And more”

Also “etc.” and “including but not limited to”. In a priced scope these are worthless, because the vendor did not estimate what the phrase gestures at, so it is not in the number. Ask for the list to be closed. A vendor who will not close it either has not done the estimate or is keeping the right to argue later.

Hours with no rate, or a rate with no hours

You need both halves or neither. “A team of four for eight weeks” with no rate cannot be checked against the total. “A senior engineer at a day rate” with no day count is a subscription with no ceiling. Where both appear, the next question is what a day contains, and that is the trick below.

No named exclusions

An exclusions section is the strongest signal in a proposal, because writing one is unpleasant: it makes the vendor say no in advance, in print, before you have paid anything. A catch-all does not count. “Anything not described above is excluded” decides nothing, because the fight you will have is over whether a thing was described above. Good exclusions are specific, testable, and say what happens if you want the excluded thing anyway, a shape taken apart in fixed price versus time and materials.

If the document has none, supply the list yourself and ask for each item to be marked in or out: browser and device matrix, accessibility standard, who writes the copy and supplies photography, data migration, content entry, third-party licence fees, analytics setup, search engine work, email deliverability, additional languages, an admin interface, the load the system is built to hold, and support after launch. Most disputes on small builds come from that list. Almost none come from the features everybody discussed.

No assumptions section

Assumptions are the estimator showing their work: the conditions under which the number is true. A proposal without them claims perfect knowledge of a business the vendor met three weeks ago.

What matters is that each one carries a consequence. “We assume the existing API is documented and has a sandbox” is a statement. “We assume the existing API is documented and has a sandbox; if not, discovery on that integration is quoted separately and adds an estimated two weeks” is a mechanism. The first becomes an argument, the second a decision. Read the assumptions before the price, every time: the cheapest bid in your stack is often cheapest because of one line buried there. The same discipline applied to the services themselves is in what a third-party integration really costs.

No change order mechanism

Every fixed scope meets a change, usually in week two. The proposal should name who may raise one, who on your side approves it, how fast the vendor must respond with a cost, what price basis that cost uses, and that schedule impact is stated separately from money. A change adding a given sum and two days is a different decision from one adding the same sum and three weeks.

Absence here is not neutral. Without a mechanism, small requests get absorbed informally until the vendor’s contingency runs out, after which they refuse things, including reasonable ones. A client told yes for two months reads the first no as bad faith, and neither side did anything wrong. The document never named a process.

No payment schedule tied to deliverables

Payments attached to dates pay for the passage of time. Payments attached to phase names pay for assertions: “development complete” is a claim rather than a test. A milestone should be a behaviour you can go and observe on a staging URL today: a user signs up, creates an organisation, invites a second person, and both accounts see the same project list. That is either true or it is not.

Check too that a meaningful proportion is held to final acceptance: a closing payment small enough to walk away from stops working as leverage. Our own published terms, for comparison rather than as a standard: half on contract and half on delivery, moving to milestones above $30,000, against a card whose minimum for a build is $7,500 and whose bands are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

No statement of who owns the code

This is the one silence with a legal default behind it, and the default is probably not what you assume. Under United States law a work made for hire is either a work prepared by an employee within the scope of employment, or a specially ordered or commissioned work falling into one of nine categories enumerated in 17 U.S.C. section 101. Computer programs are not among the nine. In Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), the Supreme Court read “employee” there through the common law of agency, which is how an outside development shop is ordinarily classified. Paying for software does not by itself make you its copyright owner. A written assignment does.

The United Kingdom arrives by a shorter road. Section 11 of the Copyright, Designs and Patents Act 1988 makes the author first owner, the employer only for works made by an employee in the course of employment, and section 90(3) provides that an assignment of copyright is not effective unless in writing signed by or on behalf of the assignor. A contractor who never signed one still owns it.

So look for four things. An express assignment of the work product to you. What triggers it, normally full payment, which is defensible as long as you know that is the trigger. A licence for any pre-existing tooling of the vendor’s inside your system, which they keep owning and you need the right to use and modify after they are gone. And a list of third-party dependencies with their licences, since a copyleft library is a constraint no assignment clause undoes. The absence of the clause is itself the finding. Who can actually deploy the thing is in what happens to your software if your agency disappears.

No named people

“A senior team” is not a commitment. Ask for names, ask which are employees of the company you are contracting with, ask what proportion of their week is yours, and ask for written notice before anyone is substituted. Silent substitution is how a proposal priced on senior engineers becomes a project delivered by juniors, one of the failure modes behind the in-house, agency and freelancer comparison. If the document names nobody, there is nothing to notice when the person who understood your problem hands the work to the person who writes the code.

Four tricks, and what to say back

The low bid that assumes you supply the designs

Buried in assumptions: final designs to be provided by the client, all screens, all states. Design is a large fraction of a front end build, and a bid that excludes it sits next to bids that include it looking like a discount. It is a different scope, and you now owe a design process you had not budgeted, on your critical path. Say back: quote it both ways, so you compare two totals covering the same work.

The day rate that quietly excludes testing and deployment

Ask whether the quoted days include code review, testing, deployment and infrastructure setup, coordination, and fixing defects found during acceptance. Then ask what happens to a bug found a week after launch, and whether that is warranty work or billable. A vendor who answers crisply has run projects. One who calls it nitpicking has told you something.

The fixed price with an uncapped discovery phase in front of it

The headline is a fixed number. Ahead of it sits a discovery phase billed by the hour with no cap, and a note that the price will be confirmed afterwards. Nothing in that document is fixed: you have signed for an unbounded spend followed by a number nobody has written yet, by which point you hold sunk cost and the vendor holds the information. A paid discovery step is still a good idea; bound it. A fixed fee, a fixed duration, a named list of artefacts yours to take elsewhere, and no obligation to proceed. A vendor who will not cap discovery is asking you to fund the estimate that protects them.

The estimate that is really a range with the top end cut off

“From $X” presents the bottom of a distribution as the middle of one. The honest thing underneath, Barry Boehm’s cone of uncertainty, is that an estimate made before requirements are settled spans a wide multiple in both directions and narrows only as decisions get made. The bottom of that span alone is a qualifying question dressed as a price. Say back: what is the top, what pushes a project there, and what did the last three comparable projects invoice against their original figure. The third question separates a firm with delivery history from a firm with a pricing page, and what building an MVP actually costs takes the same swing apart input by input.

Where our own proposals deserve pushback

This is the section that costs us work.

We publish bands, and a band is not a quote. Our card says a marketing site is $7,500 to $15,000 and that most projects land between $18,000 and $45,000, and those numbers are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff. Ask what moves a project from the bottom of a band to the top. A fair answer names drivers: how many unique page templates, whether content is migrated or entered fresh, and whether any integration is a system we cannot get a sandbox for. If we cannot name them, the band is decoration.

And two of our own published prices start with the word from. A support retainer is from $2,500 a month and AI advisory is from $4,000 a month, which is the trick above, the bottom of a span presented as a price. The reason is real and it is still not a defence: those two are recurring engagements whose top depends on how much of a month you want, so we publish a floor where we cannot publish a band. Make us name what sits above the floor before you sign anything. Ongoing product work is published as a band, $3,500 to $6,000 a month, and if we cannot tell you what moves you from the floor into that band, treat our floor exactly as this article told you to treat everyone else’s. Those figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

We ask some clients to buy scoping before we will quote fixed. A $3,500 scoping sprint is a real cost incurred before you hold a fixed number, and by the argument above you are right to be suspicious of a paid step in front of a price. What makes it fair: the fee is fixed rather than hourly, one week rather than open-ended, credited in full against a build that starts within thirty days, and its artefacts are yours whether or not you continue with us. It is also the step that replaces our published bands, which are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff. Drop one of those four conditions and the objection above applies to us in full.

Our exclusions cut against you too. We exclude things like copywriting and photography on marketing builds, which is honest and also puts that item on your timeline. The right pushback is not to demand inclusion, it is to ask for a price, so you decide with two numbers rather than discover a gap after kickoff.

We are small, and the named people really are the people. That is the strength of the arrangement, and the arithmetic runs the other way too: a firm with a bench absorbs an illness or a resignation in a way we cannot. Ask what happens if the named engineer is unavailable for two weeks. A fair answer states an effect on the date. A reassurance is not an answer.

Half on contract and half on delivery is weaker for you than milestones. Below the threshold where we move to staged payments, the final tranche is the only leverage you hold. If you would rather have three payments against demonstrable behaviour on a smaller project, ask. We would rather that sat in the document than in an argument.

The ten-minute read

Before the total, look for nine things. An itemised scope where every line has an observable finish. No “and more”. Days and a rate, and what a day contains. Specific exclusions. Assumptions, each with a consequence. A change order mechanism naming who approves and how fast. Payments tied to behaviour. An express assignment of ownership with a stated trigger, plus a licence for anything of theirs inside your system. Named people, with notice before substitution.

Ask in writing for whatever is missing, then watch what comes back. The reply is more diagnostic than the proposal, because a proposal is written to win and a reply to nine awkward questions is written under pressure.

If you are holding a stack of bids that do not resemble each other, send us the brief and the range you have been quoted. We will tell you which gaps are scope and which are margin, including when the right call is a firm that is not us.