Quick checklist before signing
- Included and excluded scope.
- Assumptions and responsibilities of each party.
- Milestones or delivery cadence.
- Deliverables.
- Acceptance criteria.
- Price and recurring costs.
- Change management.
- Bug fixes and support.
- Rights over the software, licenses, and code access.
- Third-party dependencies.
- Termination/exit conditions for the vendor.
What a software development proposal should include
Before comparing prices, compare whether the proposals even contain the same things. These are the elements a professional proposal should have in writing, not just said out loud:
Explicit scope of work. It has to state exactly what’s included — features, integrations, documentation — and what isn’t. A proposal describing the project in general terms (“a platform to help your team manage X”) leaves too much room for each side to read it differently, and those gaps usually surface halfway through the project.
Timeline divided into phases. Discovery, design, development, testing, launch — each phase with an estimated date. It doesn’t need to be perfectly precise, but without any time reference you have no way of knowing whether the project is on track or falling behind until it’s already too late.
Clear deliverables per stage. What they deliver at each milestone: mockups, source code, documentation, test environment. If deliverables aren’t defined, every “that wasn’t included” turns into an argument over interpretation instead of something you can check against the contract.
Acceptance criteria. A deliverable shouldn’t be defined just by its name. Spell out what conditions it has to meet to count as complete, who signs off on it, and what happens if it falls short of what was agreed. That cuts down on later arguments over whether something is a bug, an open task, or a new request.
Documented assumptions. Every proposal is built on certain assumptions: that you’ll have certain information available, that certain business decisions are already made, that you have access to specific systems or data. A serious proposal writes them down, so nobody is caught off guard when one of them turns out to be wrong.
Intellectual property, licenses, and code access. It has to be clear what rights each party receives when the project ends: what developments are transferred to the client, what components the vendor keeps or licenses, what elements belong to third parties, and what access the client will have to source code, design files, and documentation. Don’t assume that paying an invoice automatically resolves all of these questions — read what the contract actually says.
In Paraguay, Article 14 of the Copyright and Related Rights Law (Ley N° 1328/98), a Paraguay-specific regulation, establishes that for works created under a work-for-hire contract, ownership of the transferable rights follows whatever the parties agreed to. The same law also contains specific provisions for software programs (Ley N° 1328/98, DINAPI — Software Industry Copyright Instruction Guide). That’s why the contract should spell out the scope of any assignment or license rather than leaving it to later interpretation — this is general information, not legal advice for your specific situation.
Identify the libraries, frameworks, open source components, APIs, and other third-party elements too. A vendor cannot hand you, as their own, rights that belong to someone else; those components remain subject to their respective licenses and conditions, which may affect how the resulting software can be used (DINAPI — Software Industry Copyright Instruction Guide).
Included and recurring costs. Beyond development, the proposal should indicate what costs fall outside or continue after launch: hosting/cloud, domains, third-party APIs, messaging, licenses, storage, backups, monitoring, support, maintenance, data migration, or training, when applicable. Two proposals with the same upfront price can carry very different running costs afterward.
Red flags
None of these flags automatically disqualifies a vendor, but if any of them shows up without explanation, ask about it before you sign:
- Fixed price without prior discovery. A fixed price can be reasonable if the scope is already sufficiently defined. If the vendor quotes without having met with you or having detailed requirements, ask about what scope, assumptions, and exclusions they built that figure on.
- Ambiguous scope or “all-inclusive” promises. Proposals that promise a lot without spelling anything out cause trouble later: when something doesn’t get delivered, each side is convinced the other promised something different.
- No timeline or milestones. As a general guideline (not a fixed rule — there are small projects where more informal management works well), a complete absence of dates or intermediate deliverables usually makes it hard to measure real progress until the end of the project.
- A price noticeably lower than the rest. When several quotes fall in a similar range and one is noticeably lower, it’s worth digging in before you sign. There may be a good reason for it (lower overhead, a leaner process), or the vendor may have read the scope differently or left out line items the other quotes include, and those gaps tend to resurface later as scope changes. Don’t assume either without asking.
Questions to ask the vendor — including the uncomfortable ones
These are questions any serious vendor, Flexora included, has to be able to answer clearly. If you’re evaluating a Flexora proposal, ask us exactly the same questions you’d ask anyone else.
- What rights do I receive over the software when the project ends? Is there a transfer of ownership rights, a license to use, or a combination? What happens to the code developed specifically for you, the design files, the documentation, the vendor’s pre-existing components, and third-party dependencies? Will I have access to the repository and be able to hire another team to maintain the system if I ever need to?
- How is a scope change handled once the contract is signed? Does it require written approval? How is it quoted? Don’t leave these changes just in a conversation — document them through the approval mechanism set out in the contract.
- What happens after final delivery? Is there a defect correction period? What does the contract consider a bug and what does it consider a change or new feature? What support or future maintenance is included, and what’s contracted separately?
- What team will work on my project? Who will be responsible, what roles and experience levels will the team have, and roughly how much of their time will be assigned to it?
- What happens if the project falls behind? Are there penalties, is there proactive communication, or do you find out when you ask?
- Can I speak with a previous client on a project of similar size and complexity to mine? If there are confidentiality restrictions, ask if they can show an anonymized comparable case, verifiable metrics, or some other evidence of relevant experience — the inability to share a specific contact is not automatically a red flag.
If a vendor — any vendor — gets uncomfortable or evasive with these questions, that’s information just as valuable as the proposal itself.
Fixed Price vs. Time and Materials
There are two main contracting models, and understanding the difference helps you read any proposal better:
Fixed Price. A total amount, defined scope, and timeline are agreed before starting. As a general guideline, it tends to work better when requirements are already well-defined and stable — it’s not a hard rule about project duration. The downside is that it offers less flexibility: a change that significantly increases or alters scope may require renegotiating price, timeline, or deliverables. It’s also possible to agree on a reprioritization while keeping the original constraints if both parties consider the changes equivalent.
Time and Materials (T&M). You pay for the time or capacity actually used, per the agreed rates and conditions. It can be billed hourly, daily, team capacity, or another unit defined in the contract; any additional expenses should be spelled out up front. It gives much more flexibility and is more appropriate when requirements are still evolving or not fully clear. The risk, from the client’s side, is that without periodic review milestones the budget can end up open-ended.
Hybrid model. One hybrid option is to start with T&M for the discovery and specification phase — when scope is still being defined — and move to fixed price once that scope is clear. It can reduce certain risks for both parties, though whether the model makes sense and how much time to spend on each phase depends on the project.
Neither model is “better” in the abstract — what matters is that the model you choose matches how well-defined your requirements are today.
The risks of choosing by price alone
The lowest price doesn’t always cost less in the end. Some risks worth reviewing:
- Scope cutting or renegotiation. When a proposal turns out to be too tight for the actual work, you may end up cutting, reprioritizing, or renegotiating deliverables. So compare carefully what each quote includes and excludes.
- Additional costs via change orders. When the initial scope isn’t sufficiently defined, clarifications and needs that come up mid-project can get treated as extra changes and push the final cost up.
- Possible impact on quality and maintainability. A very tight price can mean less time for testing, documentation, or security best practices, which can turn into higher maintenance costs down the line.
A low price doesn’t cause these risks on its own. But when several of these flags show up together, go back over the scope, assumptions, and conditions before deciding.
How to structure payment
The payment structure should match the contracting model. In a fixed-price or milestone project, it can make sense to tie payments to deliverables or verifiable stages. With T&M, it’s more common to have periodic invoicing with visibility into time or capacity consumed, progress, budget used, and regular reviews. In a hybrid model you can combine both mechanisms.
Changes that alter price, timeline, contracted capacity, or agreed commitments should follow the approval mechanism defined in the contract and be documented before they’re executed.
Before you sign
If you’ve already decided that custom software development is the right path for your company — a topic we covered in when your company needs custom software (and when it doesn’t) — and you already have a sense of what determines pricing in the Paraguayan market, which we explored in how much does custom software development cost in Paraguay, the next step is to read the proposal in front of you with this checklist beside it.
No proposal is going to check every one of these boxes, and that alone doesn’t disqualify it. What does matter is that the vendor can clearly explain the parts that are missing, and is willing to put them in writing before you start paying. If you want to see how we structure our custom software proposals, the same questions from this guide apply.