A software proposal reads like a sales document and behaves like a contract. Anything it leaves unsaid today gets argued over four months from now, with the system half built.

This is the list you can use to evaluate any vendor. It is written so you can use it against us too.

What it must put in writing

A serious proposal does not have to be long. It has to be specific on seven points.

A closed scope, not "and whatever comes up"

The document should list concrete modules, screens and workflows. "Customer management system" is not a scope; it is a title.

What works reads like this: customer sign-up with these fields, three user roles, an exportable monthly report, an email notification on approval.

If you cannot count the deliverables on your fingers, the scope is open, and so is the price.

What it does NOT include

This is the section almost nobody writes and the one that prevents the most arguments.

It should state explicitly what is left out: historical data migration, integration with your invoicing system, a native mobile app, in-person training, after-hours support. Any of those can be in or out, and both options are valid.

What is not valid is finding out at the handoff meeting.

Ownership of the code and the data

The document should say whose name the repository is in, and whose name the service accounts are in.

The right answer is: your company's, from day one, not once you finish paying. If the vendor gives you guest access to their own account, you do not own anything.

Same with the database. Yours, complete, with its relationships and files, not an export file.

A maintenance plan with a price

A system is not delivered, it is operated. If the proposal ends on the delivery date, it is incomplete.

It should state the monthly cost after delivery and what it covers: security updates, business changes, data growth, integrations that break on their own. We publish ours: maintenance starts at $1,000 USD per month, and a first working version runs between $4,000 and $15,000 USD.

A proposal without maintenance looks cheaper today and costs more within the year.

Who answers when it fails

There should be a name, a channel and a committed response time. "Just message us on WhatsApp" is not a commitment, it is a habit.

Ask what happens on a Tuesday at nine in the morning with the system down, and who answers if that person is on vacation.

Timelines with the reasoning behind them

Honest timelines come with conditions. A first system that real people already use takes four to eight weeks once the scope is closed; one with several modules, integrations and migration runs three to six months.

What moves those dates is almost never the programming. It is how available the person who knows the process is on your side, and how dirty the data to be migrated is.

A proposal that promises dates without saying what they depend on is guessing.

A fixed price and payment terms

Total amount, what happens if you ask for something outside the scope, and what each installment is paid against. The healthy approach is paying against verifiable deliverables, not against the calendar.

A proposal with seven clear points is worth more than one with thirty pretty pages.

The red flags

None of these is proof of bad faith. All of them are reasons to ask more before signing.

Quoting by the hour

Billing by the hour rewards taking longer. And it leaves you without a ceiling: you do not know how much you will pay until you have already paid.

There are cases where it makes sense, like a bank of maintenance hours. To build a new system, ask for a closed scope with a fixed price.

Promising everything in two weeks

Today anyone can have a working demo in two weeks. Writing code is fast and cheap for everyone.

What does not fit in two weeks is what holds the system up: testing, per-user permissions, data migration and going live. When someone cuts the calendar, that is where the time comes from.

You will get a good-looking demo without the production part.

Not publishing any price

The reason they give is that every project is different, and that is true. But a vendor who will not share even a range after understanding your case is waiting to see how much you can take.

Ask for a range on the first call. If they do not give it there, they will not give it any better later.

Refusing to hand over the repository

It is the most serious flag on the list. A vendor that does not hand over the code is selling dependency, not software.

The soft version is just as serious: "we'll hand it over at the end of the contract." The code is handed over to you as it is written, commit by commit, in your own account.

"We'll keep it on our server"

It sounds like convenience and it is lock-in. If the database, the domains and the services are in the vendor's name, switching teams means rebuilding.

The cloud, database and domain accounts go in your company's name, and you pay that bill directly. The vendor comes in as a collaborator.

A single developer with no backup

They can be excellent and cost half as much. They are also a single point of failure with your operation inside.

If you go that route, require written documentation and access in your name from day one. That turns a risk into a manageable risk.

Uneven detail in the document

When the proposal spends four pages on methodology and three lines on scope, it is selling confidence instead of work.

Detail goes where the money is, not where the presentation is.

Questions to copy and send

Send these questions by email, not over a call. What you want is the answer in writing.

In which company's name is the code repository, and from what point do we have admin access?
In whose name are the cloud, database and domain accounts, and who receives that bill?
What concrete deliverables does the price include, and what is explicitly out of scope?
If midway through the project we ask for something that was not included, how is it quoted and who approves it?
How much is monthly maintenance after delivery, and what exactly does it include?
If the system goes down on a Tuesday at nine in the morning, who do we contact, and within what time do you commit to a response?
Are database changes versioned in the repository, or applied directly in production?
How do you make sure a user only sees the data they are supposed to, and where is that permission enforced?
Where are the system's keys and passwords stored, and what happens if the repository leaks?
Are there automatic backups, how often, and have you ever restored one to prove it works?
What happens to our data if we stop working together, and in what format is it delivered?
Who specifically is going to write this system, and what happens if that person leaves the project?
What does the timeline you are giving us depend on, and what would delay it?
Which of your projects has been in production the longest, and who maintains it today?

Questions 7 and 10 are the ones that separate vendors the most. Almost nobody expects them.

How to read the answers

Do not look for perfect answers. Look for specific ones.

A good answer has nouns. Names of services, frequencies, names of people, numbers.
A bad answer has adjectives. "Robust," "secure," "scalable" without saying how.
A clear "no" is worth more than a vague "yes." A vendor who says "we don't do that" is a vendor who knows what they do.
A "we'll look at that later" is a future cost. Write it down and ask again before signing.

If someone gets annoyed by the list, you already got the most useful information of the whole process.

How to compare two different proposals

The real problem is not evaluating one proposal. It is comparing two that look nothing alike.

The approach that works is to normalize both to three years, the same way you compare a custom build against a subscription product.

Add up development plus thirty-six months of maintenance for each one.
Add to each one whatever the other includes and it does not: migration, training, integrations.
Add the monthly infrastructure if it is not included.

It is normal for the cheapest proposal to become the most expensive once you fill in the gaps. That is where the discount was.

The cheapest proposal is almost never the cheapest project.

Discovery comes before the proposal

A quote that arrives without anyone having understood your process is not a quote. It is an average.

Before writing down a price, someone has to find out who enters data, who approves, where the workflow stalls and what gets solved over chat because the system does not allow it. That conversation is what decides whether the project is useful.

Pay attention to who asks the questions and what kind of questions they are.

Good sign: they ask about the current process, the data that has to be migrated and who will use the system every day.
Bad sign: they ask only about screens and colors, and leave with a number the same day.
Sign they already get it: they tell you which part of the project is not worth building.

A paid discovery can be legitimate. One that never happens always gets paid for later, in scope changes.

What is on you

The list above is demanding of the vendor. It is only fair to say what is needed on the other side, because half the projects that run late run late here.

One person who decides. Someone with the authority to settle questions the same day, not at next Thursday's meeting.
Someone who does the process every day. Not only whoever runs it. The gap between how it is supposed to work and how it actually works is where the project lives.
Your data as it is. Dirty, duplicated, spread across three different files. Cleaning it up is part of the work; hiding it delays it.
Time to test. A system nobody on your team tested before going live goes live with your errors inside.

A vendor who asks you for none of this is not planning to deliver anything serious.

Use it with us

This list is not written so you choose us. It is written so you compare with good judgment, and that includes us.

Our answers to the fourteen questions are public and always the same: the repository and the database are in your company's name from the first commit; the cloud accounts are in your name and you pay that bill; the scope is closed in writing with its list of exclusions; we do not bill by the hour; maintenance starts at $1,000 USD a month; database changes are versioned in the repository, never applied by hand in production; permissions are enforced in the database, not on the screen; keys live in a secrets vault, outside the code.

If we stop working together, you keep everything: repository, database, documentation and access. That is the whole point of building custom.

Our process has been the same since the first project: we listen, we define, we build, we expand. The initial discovery is free, and if we conclude on that call that you do not need a custom build, we tell you right there.

Send the fourteen questions to three vendors and compare the answers. From idea to production, the first decision is who you believe.

What to ask for in a software proposal before you sign