How to Avoid Getting Burned by a Software Developer — Red Flags to Watch For

Photo: Unsplash — to use

The ₹15 Lakh Nightmare That Happens Too Often

Every week, at least one business owner contacts me with the same story: they paid a developer or agency lakhs of rupees and received nothing usable in return. No working software. No source code. No documentation. Sometimes the developer simply disappeared. Other times, they delivered something so buggy and poorly built that starting over was cheaper than fixing it.

This is not a rare occurrence. In the Indian market, where the custom software development industry ranges from world-class companies to individuals working from their bedroom, the risk of hiring the wrong developer is real and significant. A Kochi-based manufacturing company recently told me they spent ₹18 lakhs over 14 months with a developer who kept showing "progress demos" that were actually static mockups — no real code was ever written. By the time they realized, the developer had closed his company and was unreachable.

The good news: bad developers and agencies display consistent warning signs. If you know what to look for, you can protect yourself before signing a contract. Here are the red flags I have seen repeatedly over 12 years in this industry.

Red Flag 1: Unrealistic Promises and Instant Estimates

Any developer who gives you a firm price and timeline before thoroughly understanding your requirements is either inexperienced, desperate, or planning to change the numbers later. Legitimate software estimation requires understanding your workflows, data, integrations, user roles, and business rules. This takes days, not minutes.

Here is what an unrealistic promise sounds like: "Yes, we can build your entire ERP system in 6 weeks for ₹5 lakhs." A real ERP system takes 4–8 months and costs ₹15–40 lakhs depending on complexity. Anyone promising to build one in 6 weeks for ₹5 lakhs is either going to deliver garbage or come back with "additional charges" that triple the original estimate.

What a trustworthy response looks like: "I need to understand your requirements in detail before I can give you an accurate estimate. Let me schedule 2–3 sessions to map your workflows. After that, I will give you a detailed proposal with a range estimate that accounts for complexity." This might not be what you want to hear, but it is the honest answer. Any estimate given without proper discovery is fiction.

Another variation: "We will match any competitor's price." This is not how custom software works. Every developer has different cost structures, team sizes, and quality standards. A developer who matches any price is either planning to cut corners or planning to surprise you with scope changes later.

Red Flag 2: No Code Access and Proprietary Lock-In

If a developer refuses to give you access to the source code repository during development — or says the code will be delivered "at the end" — walk away immediately. This is the most dangerous red flag because it creates complete dependency on the developer. If they disappear, underperform, or raise prices, you have zero leverage.

Professional developers set up a code repository (GitHub, GitLab, or Bitbucket) owned by you from day one. You may not understand the code, but you should be able to see commits happening regularly — this proves real work is being done. Weekly code commits are a minimum standard. If weeks go by with no commits, that is a sign no development is happening, regardless of what progress reports say.

Watch for developers who build on their own proprietary platforms or frameworks. "We use our own CMS" or "We have a proprietary framework that speeds up development" often means they are creating vendor lock-in. If the software only runs on their platform, you cannot move to another developer without rebuilding from scratch. Always insist on standard, open-source technologies that any qualified developer can work with.

Similarly, beware of developers who host everything on their own servers and accounts. Your domain, hosting, database, and email should be in accounts you own and control. The developer should have access to do their work, but you should have admin-level access at all times. If the relationship ends, revoking the developer's access should be a simple permission change — not a hostage negotiation.

Red Flag 3: Vague or Missing Contracts

A developer who resists putting detailed terms in writing is either planning to take advantage of ambiguity or is too inexperienced to understand why contracts matter. Either way, you lose. "We do not do formal contracts — we work on trust" is not a sign of a friendly, relationship-first company. It is a massive red flag.

A proper software development contract should include: detailed scope of work with specific features listed, payment terms tied to milestones, IP ownership clause transferring all rights to you, timeline with specific milestone dates, change management process, warranty period terms, termination clause with code handover provisions, and confidentiality obligations.

If any of these elements are missing, ask for them to be added. If the developer pushes back or says "we will figure it out as we go," find another developer. The contract protects both parties — a developer who does not want clear terms documented either does not understand professional practices or intends to operate in the grey areas that ambiguity creates.

Pay special attention to scope of work specificity. "We will build an e-commerce website" is not a scope of work. "We will build an e-commerce platform with product catalog (up to 500 SKUs), shopping cart, Razorpay payment integration, order management dashboard, customer accounts, and admin panel" is a scope of work. The more specific the scope, the less room for disputes about what was and was not included.

Red Flag 4: Poor Communication Patterns

How a developer communicates before you hire them is the best predictor of how they will communicate during the project. If they take 3 days to respond to your initial inquiry, expect 3-day response times during development. If they are vague and evasive during sales conversations, expect vague and evasive progress updates.

Specific warning signs: days-long gaps in responding to messages, inability to explain technical concepts in simple terms, avoiding direct answers to direct questions ("How many people are on your team?" should not require a 5-minute non-answer), no defined communication process or tools, and reluctance to schedule regular check-in calls.

A professional developer should define their communication cadence upfront: "We will have a sprint demo every two weeks, WhatsApp updates every Monday and Thursday, and I am available on WhatsApp during business hours with a 2–4 hour response time." If they cannot articulate their communication process, they probably do not have one — and your project will suffer for it.

Also watch for developers who communicate only through one person (often a sales person) and never let you speak to the actual developers. In small teams, this can be fine. But in larger agencies, if you never interact with the people writing your code, you have no way to assess technical competence or build a working relationship with the team that matters most.

Red Flag 5: No Verifiable Portfolio or References

A legitimate developer with experience will have a portfolio of completed projects they can show you — including live, working applications and satisfied clients you can contact. If a developer cannot show you any previous work or refuses to provide client references, proceed with extreme caution.

"We have built many projects but they are all under NDA" is sometimes true but often an excuse. While some enterprise clients do require NDAs, most small and medium business clients are happy to provide a reference. If every single project is under NDA, ask for anonymized case studies with results, or ask if you can sign an NDA to view their portfolio. A developer with nothing to show is either very new (not necessarily bad, but you should know) or has nothing worth showing.

When checking references, ask specific questions. Did the project finish on time and within budget? Were there surprise costs? Did you receive source code and documentation? How was communication during the project? Were bugs fixed promptly after launch? Would you hire them again? The last question is the most telling — a hesitant "yes" is often more informative than a definitive answer.

Also look for consistency across their online presence. Check their website, LinkedIn, GitHub, and Google reviews. A developer with a professional website but zero GitHub activity might be a sales-first operation that outsources the actual work. A developer with active GitHub contributions, technical blog posts, and genuine client testimonials on Google Reviews is much more likely to be the real deal.

How to Protect Yourself — a Practical Checklist

Beyond watching for red flags, take proactive steps to protect your business before, during, and after the development engagement. Here is a practical checklist that has saved many of my clients from costly mistakes.

Before signing: Get at least 3 proposals from different developers for comparison. Call 2–3 references from each shortlisted developer. Have a lawyer review the contract (₹10,000–25,000 well spent). Insist on milestone-based payments with no more than 30% upfront. Verify their portfolio includes live, working applications.

During development: Ensure code is committed to your own repository daily or weekly. Attend every sprint demo and review working software, not just screenshots. Request access to the staging environment so you can test features yourself. Keep all credentials and access details in a document you control. If you notice any red flags during the project, address them immediately and in writing.

After delivery: Verify you have access to all source code, databases, and hosting accounts. Ensure documentation covers system architecture, deployment, and maintenance. Test the software thoroughly before making the final payment. Confirm the warranty period terms and maintenance plan in writing. Change all developer access credentials to your own secure passwords.

Frequently Asked Questions