Buyers who got burned by an offshore development company rarely spotted the problem on the sales call. Many of them described it afterwards, in public, and the same eleven patterns keep coming up.
None of this comes from our own projects. We are an offshore development company in Kathmandu, and a list of red flags drawn from our own client work would only contain the problems we had already decided to tell you about. So we read what buyers, engineers and managers wrote about offshore work in their own words, on forums where they were writing for each other rather than for a vendor.
Several of these patterns describe how parts of our industry make money. That is the reason to write them down, and the reason to apply every one of them to us.
Where these patterns come from
We read threads on Hacker News, on Reddit (mainly r/startups, r/ExperiencedDevs and r/webdev) and on Blind, the anonymous forum for verified employees of tech companies. The oldest thread we used dates from 2011 and the newest from August 2026. A pattern made the list only if it appeared as a first-hand account, from a buyer, an engineer, a manager or someone working inside a vendor, in at least three separate threads.
Forum evidence has known biases, and they shape how to read what follows. People post when something goes wrong, so these threads show what failure looks like, not how often it happens. Cheap engagements are overrepresented. Some "lessons learned" posts are vendor advertising in disguise, which r/startups moderators remove when they spot it; we used none of them, only independent replies posted underneath.
Some threads also slide from a behavior into a nationality. Where a comment did, we kept only the behavior, and we left out comments whose point was the nationality itself, because none of these flags is national: the same behaviors are reported about onshore consultancies, and one Hacker News commenter called the first flag below "consulting 101" when describing big-name firms in general. No number from a forum post is used here as a statistic. Where a poster gives one, it is labeled as that person's estimate of the teams they worked with.
Before you sign
1. The expert on the call disappears
The call goes well. A senior engineer answers every technical question with confidence, and after the contract is signed, the code is written by someone else. A manager who outsourced projects to several development shops wrote that "all of them would bring a technical lead to the initial interview, and all of them would pass the work to one or more junior devs" (Hacker News, 2024). On r/startups, a buyer who had worked with dozens of developers and agencies described a senior project manager on the first calls being switched for a junior two weeks later.
This is usually structural rather than one salesperson's lie. A services firm earns its margin on leverage, spreading each senior engineer across several less expensive ones, and a senior's hour is often worth more to the firm on the next sales call than inside your repository. Another commenter described the sequence plainly: the best people do the "design, prototyping, code samples, interviews, everything," and once the contract is in place the work moves down a tier (Hacker News, 2025).
Test it: ask for the names of the people who will commit code in the first month, talk to them before you sign, and write those names into the statement of work with a rule that nobody is replaced without notice and your agreement. The first question in our vetting guide covers what a real answer sounds like.
2. A different engineer shows up
This sounds paranoid until you read how many interviewers describe it first-hand. One interviewer listed a candidate whose lip movements did not match the voice answering, and another who gave great answers in the interview and then turned up for work unable to recall anything they had discussed: "Person we interviewed was not the same one who showed up for work" (Hacker News, 2025). An interviewer at a Fortune 10 company reported lip-synced video interviews as a common problem back in 2019.
It has since become a business. In January 2026, engineers on r/ExperiencedDevs compared LinkedIn messages offering them a cut of the salary for interviewing for jobs someone else would do, and the original poster found a registered company, describing itself as a software development company, whose job posting recruited people to sit video interviews "using U.S. engineers' names" while "one of our engineers will handle the projects 100%." One commenter in that thread said their own company had been targeted by schemes like it and had hired at least a few of the candidates.
Gartner counted as fraud either posing as someone else or having someone else pose as you (HR Dive, August 2025). The Justice Department case matters for anyone buying from a company rather than hiring a person: its June 2025 actions included searches of 29 known or suspected "laptop farms" in 16 states, and prosecutors said facilitators had built "front companies and fraudulent websites to promote the bona fides of the remote IT workers" (US Department of Justice, June 2025).
Test it: meet the named engineers on camera before you sign and again in week one, and ask each of them about something specific from the earlier conversation. Ask the vendor how it verifies the identity of its own hires, and whether they work from an office the vendor controls.
3. Nobody pushes back on anything
Every feature is possible, every deadline works, and the brief has no problems in it. Buyers describe what came next in almost the same words. One buyer wrote that the developers they had underpaid "ended up being 'yes' men who continually checked in catastrophic, unmaintainable code for simple problems" (Hacker News, 2018). A manager of several offshore teams warned that a team can do "literally nothing you want" and yet have "never questioned anything along the way".
It is easy to read this as a trait of the people. The more useful explanation is how a vendor sells and how its engineers are measured. In the sales phase every objection is a risk to the deal, and on delivery an engineer scored on tickets closed has little reason to open a question that delays one.
Test it: put one deliberate mistake into your brief before the scoping call, such as a deadline you know is too short or a shortcut you know is unsafe, and see whether anyone raises it. Then ask directly what in the brief worries them. A team that has nothing to say has either not read it or has decided not to tell you.
4. A fixed quote before the hard questions
A firm price arrives within days, before anyone has asked about your edge cases, integrations or data. The problems come later, as change requests. A consultant on r/startups recalled a client, about 15 years earlier, moving their project to an offshore vendor: asked to support a new browser version, the vendor did so, broke every other browser, and refused to fix it without more money because the requirement had never said the others should keep working. Someone who had worked with a few large IT services companies said their middle management held engineers back from doing the right thing, for example: "don't add logging to this new feature - it wasn't explicitly mentioned in the change request" (Hacker News, 2021).
A low fixed bid wins the deal, and the margin comes back through everything the quote left undefined. The vendor is not necessarily dishonest. It is pricing the uncertainty you have not resolved yet, and choosing to charge for it later rather than now.
Test it: ask for the written list of assumptions and exclusions behind the number, and for how change requests are priced. A quote with no assumptions has not removed them, only hidden them. A vendor that asks for a short paid discovery phase before committing to a fixed price is doing the opposite of this flag.
5. A rate that doesn't add up
Offshore rates are lower than onshore rates, but not without limit. Accelerance's 2026 outsourcing rate report puts senior developers in Asia at $31 to $41 an hour, and juniors at $24 to $31 (Accelerance, November 2025). A vendor billing a "senior" well below that band has to pay the engineer, its own overheads and its margin out of that lower rate, so either the seniority or the rest of the service is thinner than described.
Forum posters describe the result in their own numbers. A consultant on Blind estimated in 2019 that offshore contractors billed at half the in-house rate delivered about 35% of the output, and an engineering manager on Blind put their offshore teams, in 2023, at roughly a third of the productivity for a quarter of the cost, adding that "that cost goes up when fixing the work". Both are one person's estimate of teams they worked with, not a measured rate. The owner of an outsourcing company made the same point from the other side in 2011, listing "Oh we charge only $5 an hour" as a warning sign (Hacker News).
Test it: ask what the rate includes (code review, testing, project management, a tech lead's time) and how many years of experience each named engineer has. Compare the answer with the market band, and if the rate sits well below it, ask which of those things is missing. What offshore software development actually costs breaks down where the money goes.
In the contract
6. The accounts start in their name
The vendor offers to set up the repository, the hosting, the domain and the app store listing, and to transfer everything at the end. Reddit's r/webdev has years of threads from the other end of that offer: a shop that inherited a three-year contract at €380 a month with a developer who held its domain, and, in June 2026, a firm whose domain transfer form declared that all website files were its "sole property" and offered to sell them back.
Control of the accounts is leverage at renewal time, so "we will transfer it at the end" turns the transfer into a negotiation. The same threads carry a fair counterpoint from developers: files are sometimes held because an invoice was never paid. If you owe money, settle that before you call anything a hostage situation.
Test it: create the repository, cloud account, domain and store accounts in your own organization before the first commit, and invite the vendor in. Then read the ownership clause itself, because the contract decides who owns the code even when the repository is yours. Who owns the code in offshore software work covers what that clause should say.
7. Subcontracting nobody mentioned
You sign with one company and the work is done by another. A buyer who hires developers through a freelance marketplace reported repeated problems with subcontracting, and a reviewer on r/ExperiencedDevs described code whose commits showed "different distinct styles over time that indicate different people wrote it". It can happen inside a vendor without its own management knowing: the owner of a digital agency learned that an employee had been passing all of their work to someone else only when the unpaid subcontractor got in touch (Hacker News, 2018).
Even a disclosed handoff goes wrong when nobody on your side vets the second firm. One engineer described their large company agreeing to let a technology partner pass the back end to another firm; when they briefed that firm, its lead consultant offered to hire them to build it, not realizing they were the client (Hacker News, 2018).
Subcontracting is margin arbitrage. A vendor wins more work than it can staff and passes some of it down, each layer takes a cut and adds a handoff, and your NDA may not bind the firm that actually holds your code.
Test it: add a clause that forbids subcontracting without your written consent, attach a named personnel list, and require every person with access to use their own account in your systems, with no shared logins. Ask in plain words whether any of the work will be done by freelancers or another company.
In the first month
8. The "dedicated" developer has other clients
You are paying for a full-time engineer, and part of that engineer's week belongs to someone else. The most candid account came from inside a vendor: an employee of a nearshore development company wrote that some of its developers were "OE across 2+ projects", OE meaning overemployed, and some were overemployed with other agencies, "that we just ignore." In the same thread, a buyer who hires through a freelance marketplace advised dropping anyone who says they are full-time but slows down sharply after the trial week.
Someone who had an overemployed engineer on their team listed the symptoms: "they start going AWOL, miss important discussions, miss deadlines" (Hacker News, 2025). It happens inside the largest firms as well. In 2022 Wipro, which then employed more than 250,000 people, fired 300 employees it found moonlighting for competitors, and its chairman called it an "act of integrity violation" (TechCrunch, September 2022).
Test it: define "dedicated" in the contract as exclusive to your project during agreed hours, and ask the vendor how it detects and handles second jobs. Then watch the first two weeks: response times that follow an unexplained daily pattern, missed meetings and a drop in output after the start are the signals the forum posts describe.
9. Progress you only see in demos
Status reports are green for weeks, and then the demo shows less than the reports described. In a 2018 thread, one commenter recalled a contractor putting about 16 people on 60-hour weeks for roughly 12 weeks; the first joint demo showed interface templates with "very little, if any, code written under the covers". Another found that an overseas test team's build server had been marking most tests as passing and failing the rest at random, for more than a year and a half (Hacker News, 2018).
In 2025, an engineer at a consulting company that relies on offshore developers described the offshore side's code reviews and QA sign-offs becoming rubber stamps while management demanded velocity over every other metric. In 2026, a founder whose nearshore vendor had reached "95% completion to MVP" found it now seemed to be creating "2 new bugs for every bug they fix".
When I was consulting I had a build pipeline to production up as my #1 task.
The consultant who wrote that in 2018 was describing a habit that kept clients from being surprised, and it is the right one to ask for. A vendor measured on activity will produce activity: a government agency that paid its outsourced IT contractor for each resolved issue got a contractor that "created as many tickets as possible" (Hacker News, 2018). Working software in an environment you control is much harder to fake, and the last tenth of a project is where the unfinished work has usually been hiding.
Test it: from the second week, ask for working software on a staging environment you own, and have someone on your side run the test suite in a pipeline you can see. If nobody technical is on your side, pay an independent engineer for a day to build the project from a clean machine; our takeover guide explains why that single test says so much. Teams that treat testing as part of the engineering work will not find the request unusual.
10. Code its authors can't explain
The pull requests are large and arrive quickly, and nobody on the vendor's side can walk you through them. Before AI tools this looked like copy-paste: one engineer found an outsourced team that met a request for a different admin button by duplicating every file in the view (Hacker News, 2018). Now it looks like generated code nobody has read. One reviewer described, in 2025, finding a contractor's pull request still carrying the AI tool's placeholder, "//REPLACE THIS WITH YOUR API KEY", after which the team had to rotate its shared access keys.
Another reviewer described, in 2026, sending comments on a contractor's generated code, watching them go straight back into the model as a prompt, and getting "the same 2000 line ball of spaghetti back with even more issues" until they gave up and approved it. Developers as a whole are wary of this output. In Stack Overflow's 2025 survey, 84% of respondents used or planned to use AI tools, 46% actively distrusted their accuracy, and 66% named "AI solutions that are almost right, but not quite" as their biggest frustration (Stack Overflow, 2025).
The flag is not that a vendor uses AI. It is that code reaches you that nobody on their side understands, which means nobody on their side can maintain it either.
Test it: in the first week, ask the author of a merged pull request to walk you through it on a call and make a small change while you watch. Ask for the vendor's written policy on AI tools: which ones are used, where your code is sent, and who reviews what they produce.
11. New faces without notice
The engineers you onboarded are gone, and the people in their seats need the same explanations again. A client of one outsourcer described a small group of seniors they got to know and "a larger group of junior developers who rotated around projects as needed. We generally didn't know who the junior devs were" (Hacker News, 2017). Others describe the other half of the churn: "Whenever I've worked with offshore devs, the really great ones never stuck around," wrote one commenter in 2025, and the founder stuck at "95% completion" above blamed turnover inside the agency, because new developers did not understand the product's nuance and dependencies.
For the vendor, an engineer who knows your system well is also the best candidate for its next client. Without a contract term that makes moving them expensive, the incentive runs against you.
Test it: write a substitution rule into the contract, with notice, a handover period in which both engineers work together, and your approval. Each month, compare the people committing to your repository with the named team. The second question in our vetting guide asks what the last departure cost a client.
What isn't a red flag
Some things that look alarming on a first call are usually signs of a vendor telling you the truth. Several of them are the honest version of a flag above.
| What you notice | What it usually means |
|---|---|
| A higher rate than the cheapest quote | The price may include review, testing and a lead's time that the cheaper quote left out |
| A paid discovery phase before a fixed price | The vendor wants to price your project, not guess at it |
| "That deadline is not realistic" | Someone has read the brief and is willing to risk the deal to say so |
| The vendor turns your project down | It knows where its team is weak |
| No overlap with your working hours | Workable if handoffs are written and daily; see what a Kathmandu team looks like from New York, or from Toronto and Vancouver |
| Imperfect English on a live call | Nothing about the code; a reply pasted from a chatbot is the worse sign |
| Files held back over an unpaid invoice | A payment dispute, not a hostage situation |
The eleven flags on one page
| # | Flag | When it shows | Cheapest test |
|---|---|---|---|
| 1 | The expert on the call disappears | Sales call | Named engineers in the statement of work, met before signing |
| 2 | A different engineer shows up | Interview to week one | Camera calls with the named team, and questions only the real interviewee could answer |
| 3 | Nobody pushes back | Scoping | Plant one deliberate mistake in the brief |
| 4 | A fixed quote before the hard questions | Proposal | Ask for the written assumptions and change-request pricing |
| 5 | A rate that doesn't add up | Proposal | Compare with the market band and ask what the rate includes |
| 6 | The accounts start in their name | Contract | Create every account yourself before the first commit |
| 7 | Subcontracting nobody mentioned | Contract | No subcontracting without written consent; named accounts only |
| 8 | The "dedicated" developer has other clients | Weeks one and two | Define exclusivity; watch response patterns and output after week one |
| 9 | Progress you only see in demos | Weeks one to four | Working software on your staging, tests run where you can see them |
| 10 | Code its authors can't explain | Week one onward | Ask an author to walk through a merged pull request live |
| 11 | New faces without notice | Month one onward | Substitution rule; compare committers with the named team monthly |
No single flag proves a vendor is bad. What matters is what happens when you name it: a good vendor fixes it in writing, with a date, and a poor one explains why it is not really a problem.
Hold us to the same list
We are an offshore development company, so every flag here applies to us, and two of them, subcontracting (flag 7) and code ownership (part of flag 6), we can answer in writing before a first call. We do not use freelancers: the code we write for you is written by our own full-time and part-time employees. Every developer's employment contract assigns their work to the company, and in most of our contracts ownership of that code passes to you as it is written.
Test us on the other nine the way this list describes: flags 1 to 5 on the first calls and in the proposal, and the rest by watching our team work in the first month. We will sign a mutual NDA before that first call, or sign yours.
Questions buyers ask about red flags
Are offshore development companies riskier than onshore ones?
Not by nature. Several of these flags, including the senior who disappears after signing, are reported about onshore consultancies too. Distance makes them slower to notice, which is why most of the tests above are about seeing the work directly rather than hearing about it.
How many red flags should make me walk away?
Some should on their own: refusing to put accounts in your name, subcontracting you were not told about, or an engineer who is not the person you interviewed. Most of the others are fixable, and the vendor's response when you raise one tells you more than the flag itself.
Can I spot these without a technical background?
Most of them, yes. Flags 1 to 8 and 11 need no code reading, only questions, a contract and attention in the first weeks. For flags 9 and 10, paying an independent engineer for a day or two early in the project costs far less than finding out at the final demo.
What should I do if I spot one after signing?
Name it in writing, ask for a specific fix and a date, and make sure every account and credential is in your hands before the conversation gets difficult. If the project is already stalled, taking over a failed offshore project sets out the first 30 days.