Start with the work, not the vendor list
Write one page: the job the software must do, who will use it, which systems it must talk to, and what a good first live version looks like. If you cannot write that page, buy a short discovery, not a build. Sending a vague brief to six companies and averaging the quotes will not get you a comparable set of numbers.
Questions that sort the room
- Who writes the code, and where are they? If the answer is a rotating bench, ask who owns the architecture when someone leaves.
- What have you shipped that looks like this? Adjacent is fine. Unrelated portfolio pieces are not evidence.
- What do you need from us each week? A vendor that needs nothing from you will guess, and you will pay for the guesses.
- How do change requests work? “We’ll just include it” is not a process. A written change path is.
- What do we hold on the last day? Source, hosting, documentation, a way to change a rate without calling you.
Warning signs
- A fixed price before anyone has seen your data or your other systems.
- A proposal that restates your email and adds a technology list.
- Ownership of the code that stays with them, or a licence you cannot leave.
- No named person for after go-live.
A simple score you can use in the room
Give each vendor 0–2 on five things: they restated our process in their words; they named our other systems; they wrote a definition of done; they showed work that looks like ours; they explained change control and handover. Ten is a serious partner. Below six, you are buying a brochure. Price is a sixth column, not the only one. A low score with a low price is how you fund a second project.
How to run the conversation so you can compare
Send the same one-page brief to everyone. Same systems, same first-slice, same “what done looks like”. Ask for a written list of assumptions. Then put the replies in a table. If one vendor refuses to write assumptions, they will discover them on your clock.
Meet the people who will do the work, not only the person who sold it. Ask who is still there from the case study they showed you. Ask what they will need from you every week — hours, not slogans. A partner that needs nothing from you will guess.
What a usable proposal actually contains
A proposal you can compare has five parts: the job in their words, the systems they will touch, a first live slice with a date range, a list of assumptions, and what happens when something is missing. Technology lists and “agile methodology” paragraphs do not help you choose. If two vendors return those five parts, you can put price next to them. If only one does, you are not comparing price. You are comparing a plan to a brochure.
Ask for names, not roles. “A senior developer and a part-time designer” is a bench. “Priya will write the data model; Arun will do the Tally connector” is a team. You will still lose people — that is normal — but you want to know who owns the architecture when that happens.
What the first thirty days should look like
Week one is not screens. It is sitting with the people who do the job, photographing the spreadsheets, and writing the definition of done so narrowly it feels rude. Week two is access: test accounts, a sample of real data, the API credentials someone has to request from Tally or the bank. Weeks three and four are the first vertical slice — one path that works on real records — not a clickable mock of twelve modules.
If after a month you have only workshops and a Figma file, you do not have a software partner. You have a discovery that has not been named. That can still be useful. Do not pay build rates for it.
India-specific noise you can ignore — and noise you cannot
Ignore: “we have 200 developers”, ISO logos on the email footer, a slide about AI if you did not ask for AI. Do not ignore: they will not sign that you own the source; they want production passwords in week one; they quote a fixed price before they have seen a single export; the only English-speaking person is the salesperson. Those are how projects become a second project.
Students and intern-heavy teams can ship a demo. They struggle when the GST treatment is wrong, the old item codes collide, or the night-shift supervisor refuses the new screen. Ask who was on the last job that looked like yours after go-live, not who designed the landing page.
References that mean something
Ask to speak to a client whose job looked like yours — not a logo strip. Ask what broke in week six, and who fixed it. Ask whether they still have the source. A partner who only offers a marketing site as proof they can replace your dispatch process has shown you their real product. Adjacent work is fine. Unrelated work is a bet on general cleverness. You are not buying cleverness. You are buying a path through your exceptions.
If they cannot name a job that is still in production, you are the case study. Price that risk. Sometimes it is worth it for a small, well-bounded MVP. It is not worth it for the system that invoices your customers.
How we would want to be chosen — so you can test anyone
We would rather lose a vague RFP than win it. Send the one-page brief. Ask for assumptions in writing. Meet the people who will write the data model. Score the five things in the room. If we cannot restate your process, do not hire us. If we quote a fixed total before we have seen an export, do not hire us. If we will not write that you own the source, do not hire us. Apply the same sentences to every logo on your shortlist. The work of choosing is the brief and the score, not the number of proposals.
After you pick someone, the first month should still look like the section above — process, access, a vertical slice — not a branding workshop. If it does not, you chose a studio. Studios are fine for a site. They are the wrong animal for the system people work in. Price and scope still belong on how much custom software costs; this page is only how you tell who can carry that scope. If you are still deciding whether to build at all, stop here and read custom versus off-the-shelf first — choosing a vendor for the wrong job is how you fund two projects.
Cost context is in how much custom software costs. If you are still deciding whether to build at all, read custom versus off-the-shelf.