To choose a software development company, shortlist three to five firms that have shipped work similar to yours, check that work directly (live apps, references you call yourself), ask each firm the same set of questions about process, team and ownership, and compare written proposals on scope and assumptions rather than on the headline price. Sign only a contract that gives you the source code, the accounts and the IP once you have paid.
That is the short version. The rest of this guide turns it into a checklist you can actually run: how to shortlist, what to verify, twenty questions worth asking on the first call, the warning signs that should end a conversation, how to read three very different quotes side by side, and what a good proposal looks like. It is written for founders and business owners who are hiring a team for the first or second time and do not want to learn these lessons the expensive way.
Before you contact anyone: write a one-page brief
Most bad vendor experiences start with a vague request. If you ask five companies to "build an app like X", you will get five quotes for five different products and no way to compare them. Spend an evening writing a one-page brief first. It does not need to be technical; it needs to be clear about the problem, the users and what "done" means for the first release.
A good brief also forces you to separate must-haves from nice-to-haves. Vendors will price everything you list, so a long wishlist inflates every quote. Mark the three to five features the business cannot launch without and put the rest under "later". You can share your rough budget range too; it saves everyone time and good firms will tell you honestly what fits inside it.
- The business problem and who uses the software (staff, customers, both)
- The must-have features for version one, and a separate "later" list
- Existing systems it must connect to: accounting, payment gateway, WhatsApp, ERP, spreadsheets
- Platforms: web, Android, iOS, desktop, or a mix
- Target launch window and any hard deadline (a season, a funding milestone, a compliance date)
- A budget range, even a wide one
How to build a shortlist and vet it
Start with relevance, not size or location. A ten-person firm that has built three booking systems will usually do a better booking system than a 500-person firm that has not. Look at portfolios for work that resembles yours in type (a CRM, a POS, a marketplace) and in scale. Referrals from people who have actually shipped a product with the firm are worth more than any review site.
Then verify. Portfolios are easy to decorate, so open the live website or install the app and use it. Ask for two references from past clients and call them yourself; ask what went wrong and how the firm handled it, because every project has problems. Check that the company is a real registered business with a traceable address and a history longer than a few months. Finally, meet the people who would actually work on your project, not just the salesperson.
- Relevant, verifiable work: live apps or sites you can open, not only screenshots
- Two or three references you contact directly, ideally from projects finished at least a year ago
- A registered business with a real address, GST registration where applicable, and a clear billing entity
- A named project lead or senior developer you have spoken to
- Evidence of support after launch: ask how many clients have stayed on a maintenance plan
20 questions to ask on the first call
Ask every shortlisted firm the same questions so the answers are comparable. You are listening for specifics. "We follow agile" tells you nothing; "we demo working software every two weeks and you get access to a staging site from week one" tells you a lot. Honest answers to uncomfortable questions, such as what went wrong on a past project, are a strong positive signal.
You do not need to ask all twenty in one meeting. The first ten are for the initial call; the rest fit naturally into the proposal review. Keep notes in a simple spreadsheet with one column per vendor, and you will be surprised how quickly the differences become obvious.
- 1. What have you built that is closest to this, and can I see it running?
- 2. Who exactly will work on my project, and how much of their time will it get?
- 3. Is any of the work subcontracted or outsourced to freelancers?
- 4. How do you turn my brief into a detailed scope, and is that discovery phase paid?
- 5. How often will I see working software, and will I have a staging link?
- 6. What tools do you use for tasks, code and communication, and will I have access?
- 7. Which technology stack do you recommend, and why that one for this project?
- 8. How do you handle changes to scope once work has started?
- 9. What does your testing process look like before anything reaches me?
- 10. What happens if a key developer leaves during the project?
- 11. Who owns the source code, designs and IP, and when does ownership transfer?
- 12. Will the code live in a repository that I own from day one?
- 13. Whose name are the hosting, domain, app store and third-party accounts registered in?
- 14. How do you estimate, and what assumptions sit behind this price?
- 15. What is not included in the quote (hosting, licences, content, app store fees)?
- 16. How is payment split across milestones?
- 17. What warranty period do you give for bugs after launch?
- 18. What do maintenance and support cost after the warranty ends?
- 19. How do you handle security, backups and personal data?
- 20. Tell me about a project that went badly. What happened and what did you change?
Red flags that should end the conversation
Some warning signs are subtle, but a few are reliable enough that you should walk away. The most common one is a firm quoting a precise fixed price after a single short call, with no questions about your users, integrations or edge cases. Either they have not understood the work, or they plan to recover the difference through change requests later.
Be equally wary of anyone who is vague about who does the work, who asks for most of the money upfront, or who wants to keep the code in their own accounts "for security". None of these automatically means dishonesty, but each shifts risk from the vendor onto you, and you should only accept that knowingly.
- A fixed quote with no discovery and almost no questions asked
- Pressure to sign quickly, or discounts that expire in days
- More than roughly 30 to 40 percent requested upfront before any deliverable
- No access to code, staging or task boards until the end
- Refusal to transfer source code or accounts after final payment
- Portfolio items you cannot verify, or references who never respond
- Every answer is "yes, we can do that" with no trade-offs mentioned
- The team you meet in sales is not the team that will build it
Comparing quotes without comparing apples to oranges
Quotes for the same brief often differ by three to five times, and the cheapest is rarely the best value. The gap usually comes from different assumptions: one vendor has priced a basic admin panel, another a full reporting module; one included testing and deployment, another did not. Before comparing numbers, line up what each quote actually covers.
Also check the pricing model. Fixed price gives budget certainty but needs a tight scope, and vendors add a buffer for risk. Time and materials is more flexible and often cheaper for evolving products, but you need to watch progress closely. Many sensible projects combine them: a small fixed-price discovery phase, then a fixed-price first release, then monthly time-and-materials for improvements. As a rough 2026 guide for Indian development teams, a focused business web app often lands between INR 3 and 12 lakh (about USD 3,500 to 14,000), and a product with web plus mobile apps and several integrations commonly runs INR 10 to 40 lakh (about USD 12,000 to 48,000). Your scope decides where you land.
| What to compare | Quote A | Quote B | Quote C |
|---|---|---|---|
| Features explicitly listed | |||
| Assumptions and exclusions | |||
| Pricing model (fixed / T&M / hybrid) | |||
| Timeline and number of milestones | |||
| Team size and seniority | |||
| Testing, deployment and documentation included? | |||
| Warranty period after launch | |||
| Monthly maintenance cost after warranty | |||
| Code and account ownership terms |
What a good proposal contains
A strong proposal reads as if the vendor understood your business, not as a template with your name inserted. It restates the problem in its own words, breaks the work into features or milestones with estimates for each, and is honest about what is uncertain. If a proposal contains no assumptions at all, the assumptions are hidden in someone's head and will surface later as disputes.
Look for a phased plan. The best proposals suggest a smaller first release that gets the core workflow into users' hands quickly, then build from real feedback. That is not upselling; it is the most reliable way to avoid spending the whole budget on features nobody uses.
- A summary of your goals and users, in the vendor's own words
- Feature-by-feature scope with estimates, split into phases or milestones
- Explicit assumptions and exclusions
- Recommended technology with a short reason for each major choice
- Team composition and who your day-to-day contact is
- Timeline with demo dates, not just a final delivery date
- Payment schedule tied to delivered milestones
- Warranty, support and maintenance terms
- Ownership, confidentiality and handover terms
Contracts and code ownership: the clauses that protect you
The contract matters most when things go wrong, so read it assuming they will. The single most important clause is intellectual property: it should state that all custom code, designs and documentation become yours on payment, with the vendor keeping only a licence to its own pre-existing, reusable components. Ask for the code to live in a Git repository under your organisation from the start, with the vendor added as collaborators.
Everything else supports that principle. Domains, hosting, app store developer accounts, payment gateway and WhatsApp Business accounts should all be registered to your business, with the vendor given access. Add a handover clause that requires credentials, documentation and deployment instructions if the relationship ends. For anything handling customer data, include confidentiality and basic data-protection obligations; in India, the Digital Personal Data Protection Act makes this more than a formality. Have a lawyer review a contract of any meaningful size.
| Clause | What good looks like |
|---|---|
| IP ownership | All custom work assigned to you on payment; vendor retains only pre-existing tools, licensed to you |
| Code repository | Hosted in your GitHub/GitLab organisation from day one |
| Accounts | Domain, hosting, app stores and third-party services in your business name |
| Milestones and acceptance | Clear acceptance criteria and a review window for each milestone |
| Change requests | Written process with estimates approved before work starts |
| Warranty | A defined period (often 30 to 90 days) of free bug fixes after launch |
| Termination and handover | Right to exit with code, credentials and documentation delivered |
| Confidentiality and data | NDA terms plus data-handling obligations for personal data |
Making the final decision
By now one or two firms usually stand out. If you are still torn, pay for a short, fixed-price discovery or prototype phase with your top choice. Two to four weeks of real collaboration tells you more about communication, honesty and quality than any number of sales calls, and you keep the output, such as a detailed scope and clickable designs, even if you do not continue.
Weigh fit over price. The right partner asks hard questions, pushes back on features that do not earn their cost, shows you working software early and makes it easy for you to leave if you ever need to. If you want a second opinion on a brief or on quotes you have already received, RED SAG is happy to review them; we build custom business software from Tiruppur, and a quick honest read costs you nothing.
Frequently asked questions
How many software development companies should I contact?
Three to five is the practical range. Fewer gives you too little to compare; more makes it hard to give each proposal a proper review, and good firms may deprioritise a request that looks like a mass tender. Shortlist based on relevant work first, then have one serious call with each before asking for a written proposal.
Is it better to choose a fixed-price or time-and-materials contract?
Fixed price suits a well-defined first release where you need budget certainty. Time and materials suits evolving products where requirements will change. Many projects use both: a fixed-price discovery and first release, followed by monthly time-and-materials for improvements. Whichever you choose, tie payments to delivered, demonstrable milestones.
Who should own the source code of my software?
You should, once you have paid for it. The contract should assign all custom code, designs and documentation to your business, and the repository should sit in your own GitHub or GitLab organisation. The vendor can keep its pre-existing reusable components but should license them to you permanently so the software keeps working if you part ways.
Why do software quotes for the same project vary so much?
Mostly because vendors make different assumptions about scope, quality and what is included. One may price a basic version without testing or deployment, another a production-ready system with documentation and warranty. Seniority and location also matter. Line up each quote's features, assumptions and exclusions before comparing numbers, and ask vendors to explain their biggest line items.
How much should I pay upfront to a software development company?
A common and fair arrangement is 20 to 30 percent to start, with the rest tied to milestones such as approved designs, a working beta and launch. Be cautious about paying more than about 40 percent before seeing any deliverable. For a paid discovery phase, paying the full small amount upfront is normal.
Should I choose a local company or an offshore one?
Location matters less than relevant experience, communication and contract terms. A local firm makes in-person workshops easy; a remote one may offer better rates or specialised skills. What matters is overlapping working hours, a clear communication rhythm, access to staging and code throughout, and a contract enforceable where you operate.