If you’re a business owner who’s hired a software developer or agency, there’s a real chance you’ve been screwed. Not always maliciously. Often it’s misaligned incentives, obscure communication, and information imbalance. The result is the same: six-figure bills for software that doesn’t solve the problem, projects that hover at “90% done” for six months, contracts that lock you into a perpetual rent relationship for code you funded. This article walks through the seven patterns the software industry uses against business owners, the warning signs to watch for, and the practical defenses that work. We started Pilot West Studios specifically to address this. We turn away about 80% of prospective clients, sometimes telling them not to build software at all. That’s the consultant-first model. Here’s what to look for.
The seven ways developers screw business owners
1. Scope creep by design
Vague initial scope creates gaps that get discovered midway through the project, requiring additional payments for what you assumed was already included.
Real example: A distribution company received a $1 million quote with a one-year timeline. The final cost was $2 million over two years, and nearly bankrupted the company.
Warning sign: Language like “we’ll figure out the details as we go” or “that’s typically a separate phase” applied to basic functionality you already discussed.
2. The jargon smokescreen
Technical terminology obscures decisions and prevents you from asking effective questions. Most owners avoid asking for clarification because they don’t want to look uninformed.
The reality: Business owners without IT departments need conversations without industry jargon. If a developer can’t explain a recommendation in plain English focused on business outcomes rather than technical features, that’s a signal.
Warning sign: Inability to explain why they’re recommending something, in language an operations manager could understand.
3. Hourly billing without accountability
Open-ended hourly arrangements create no incentive for efficiency. Slower work generates higher profits.
The pattern: Inherited projects routinely show hundreds of billable hours for work that would have taken a fraction of the time at a fixed rate.
Warning sign: Refusal to provide estimates, milestones, or caps on billing. Everything stays in “time and materials.”
4. The eternal “almost done”
Projects that perpetually hover at 90% completion while delays continue and billing keeps rolling.
Real example: The same distribution company stayed at “90% done” for six months. Continuous billing despite the prior $1 million investment. The “90%” never moved.
Warning sign: No concrete milestones with specific testable deliverables. Only vague progress updates that sound the same week to week.
5. Vendor lock-in
Developers retain ownership of source code, forcing clients into perpetual rent relationships for software they paid to build.
The pattern: Owners pay thousands annually, indefinitely, for vague “support” and hosting on code they funded. They can’t switch developers because the new developer can’t access the codebase. They can’t bring it in-house because they don’t own it.
Warning sign: Contracts that don’t explicitly transfer source code ownership, or that push toward “software as a service” models that prevent you from ever owning the work.
6. The “latest technology” upsell
Unnecessary cutting-edge technology that increases costs and creates long-term dependency on the developer who chose it.
Real example: Microservices architecture recommended for 50-user companies. Newest language versions pushed when stable older versions would do the job for half the maintenance cost.
Warning sign: Excitement about technology choices without a clear business explanation of why this stack and not a simpler one. If the answer is “it’s modern” or “it’s what we use,” that’s not a business reason.
7. No skin in the game
Developers get paid regardless of whether the software solves your actual business problem.
The pattern: Systems technically “delivered” per contract that fail to solve the business issue. The developer met the spec. The owner is left with an expensive non-functional tool.
Warning sign: No discussion of business outcomes, success metrics, or ROI. Only technical deliverables and feature lists.
Why this keeps happening (it’s not your fault)
Software development has no standardized pricing, no industry valuations, no transparency. You navigate this once or twice in a lifetime. The developer does it daily. They know exactly where the ambiguity lives.
The information asymmetry
You’re navigating software development once or twice in a career. Developers are doing it daily. They understand exactly where ambiguity lives in contracts and exploit those gaps systematically.
The misaligned incentives
The current payment structures create predictable problems:
- Hourly billing. Slower work increases profits.
- Scope creep. More building generates more billable hours.
- Complexity. More dependence means more lock-in.
- Vague specifications. Easier to justify timeline overruns.
- Withheld ownership. Permanent recurring revenue.
None of those align with you getting a cost-effective solution.
Why “good” developers stay quiet
Ethical developers exist. They tend to stay quiet because they don’t want to trash their industry, their existing referrals keep their schedule full, and they assume quality work proves itself. The result: the loudest voices in the industry tend to be the ones with the worst practices and the biggest marketing budgets.
Red flags to watch for
Before you hire
Refuses fixed pricing or hourly estimates with caps. Everything stays vague “time and materials.” Responses sound like “we’ll know more once we start.”
Can’t explain in plain English. Heavy jargon without business translation. Makes you feel inadequate for asking.
No similar project portfolio. Can’t provide relevant case studies or references. Only shows technical portfolios without business outcomes. (Industry experience isn’t essential. Understanding your business is.)
Talks technology before understanding the business. Excitement about technical choices comes before problem consultation. Leads with features instead of consultation questions.
Pushes expensive custom solutions when simpler alternatives exist. Skips exploring off-the-shelf options. Never discusses what you don’t need.
Rushes toward coding immediately. Resists discovery and documentation investment. Suggests “let’s build something and see what happens.”
During the project
Milestones slip continuously without clear explanation. “Just a few more weeks” repeats indefinitely with no accountability.
Can’t demonstrate working features regularly. Everything stays “in progress” or “almost done.” No testing until completion.
Scope expands without timeline or budget adjustments. Unannounced features appear in the work. Originally-included features suddenly need extra payment.
Becomes defensive about questions. Treats your concerns as micromanagement. Demands trust without demonstrating accountability.
Avoids documenting decisions or changes. Everything is verbal. No change records, no decision trail.
In the contract
Vague scope of work. High-level language without specifics. Substantial room for later interpretation.
Missing source code ownership clause. Doesn’t explicitly state IP ownership. Includes ongoing licensing fees for software you paid to build.
No clear acceptance criteria. Undefined completion parameters per milestone. No objective way to evaluate “done.”
Payments heavily front-loaded. 50% or more required before work starts. No holdbacks tied to final approval.
No deadline remedy provisions. All risk lands on you for developer delays. Zero penalties or exit clauses.
Unlimited change order clauses. Minor modifications trigger additional fees. No distinction between fixing the developer’s mistakes and adding new requirements.
We’d rather lose projects than watch businesses fail. Telling clients NO to mid-project additions, even when service businesses naturally want to say yes, is how you protect the original problem from getting buried in feature creep.
How to protect yourself
1. Document everything before you start
This is the single most protective measure.
Document in detail: the specific problems you’re solving, the current processes (step-by-step), what success looks like (in measurable terms), what’s in scope and what’s explicitly out of scope.
Why it matters: undefined problems can’t be fixed. Defined problems can. And once defined, scope creep arguments evaporate because you can both look at what was agreed.
Real example: A Wisconsin membership organization processed member submissions manually for weeks each season. Before any code was written, they documented their entire process: data collection, processing procedures, decision points, required output. That documentation became the blueprint, prevented scope creep, and let them ship a form-improvement solution that saved weeks per season.
Important caveat: Sometimes scope creep reflects unclear initial definitions, not developer dishonesty. Owners who change requirements weekly share the responsibility. Ethical developers will push back: “let’s finish what we committed to before adding features.” That pushback is what to look for.
2. Demand plain English
Require an explanation of every technical decision in business terms.
Not: we’re using AWS Aurora.
But: Instead of running servers in your office, we’ll use a managed database service. Your team can access it from anywhere, automatic backups happen continuously, you don’t have to maintain hardware, and the system grows with you as you scale.
If they can’t explain it in plain English, either they don’t understand it themselves, or they’re deliberately obscuring it. Both are signals.
Script you can use: Explain this like you’re explaining it to my operations manager. What’s the business reasoning, what trade-offs exist, and why is this the right choice for our specific situation?
3. Pay for deliverables, not time
Compensate results, not hours.
Better payment structure: 20% to 30% upfront for discovery and planning. 40% to 50% distributed across milestone deliverables. 20% to 30% as a holdback until final acceptance.
Each milestone must deliver testable functionality. Not “the database is 80% done.” Instead: “you can log in, create users, and run these specific reports.”
Include objective acceptance criteria. Define “done” precisely per milestone. Allow one to two weeks of testing before payment release. Reserve the right to request fixes before approving.
4. Insist on code ownership
The contract must explicitly state: Client owns all source code, intellectual property, and assets created during this project upon final payment.
Why it matters even if you’re non-technical: you avoid being trapped. If the relationship deteriorates, you can transition to other developers. If the developer’s business fails, your project doesn’t restart from zero.
Demand: source code repository access (GitHub, GitLab), administrative credentials to all systems, complete documentation (user-facing and technical), zero ongoing licensing fees for your own software.
5. Get a second opinion
Before a major project, get two or three firm proposals.
Compare more than price: how each approached understanding the problem, what they said you don’t need, how they explained technical decisions, what risks they identified, how they structured the project.
If you’re already in a project and concerns surface, an independent technical audit ($2K to $5K) can prevent a $200K disaster. Sometimes those audits confirm “you’re fine, you’re in the messy middle.” Sometimes they’re “exit immediately before you lose more.”
6. Start small
Don’t bet the business on an unproven relationship.
Phase 1: Discovery and planning ($5K to $15K). Document requirements. Create specifications. Establish ROI. Get detailed estimates.
Phase 2: MVP, the minimum viable product (30% to 50% of total budget). Build core functionality only. Test the relationship. See actual working software.
Phase 3: Expand based on results.
Why this works: you test the relationship before committing to the full investment. Problems that surface in early phases are limited in cost.
7. Look for developers who turn work away
Counterintuitively, this is the strongest signal of ethical practice.
Developers who regularly say:
- You don’t need custom software. Use this SaaS tool.
- Your ROI doesn’t justify this investment yet.
- You’re not ready until you complete X.
- We’re not the right fit.
These developers are prioritizing your interests over their revenue. We do this constantly at Pilot West. We turn away about 80% of prospective clients. The ones we do work with come back with referrals because the conversation was worth their time even when we didn’t take their money.
What ethical development actually looks like
They tell you what you don’t need
The best developers start by trying to talk you out of expensive custom builds. They explore: would existing software with modifications work? Would a SaaS combination solve it? Does the ROI justify it? Are you ready for this?
A real example: a client with PDF order forms causing constant errors thought they needed a full system rebuild. We built a better order form for a fraction of the cost. They thanked us for not selling them the bigger project.
They explain WHY before WHAT
Every technical decision comes with a business rationale you can understand.
Not: we’re using React with Node.js and PostgreSQL.
But: these technologies let us build faster, cost less long-term, and scale more easily. Here are the trade-offs, and here’s what maintenance looks like.
They show working software early and often
No vague “trust us, it’s coming along” updates. You interact with working features through weekly or bi-weekly demos, test environment access, clickable and testable functionality even when it’s not polished. This is what prevents end-of-project disasters where the delivered software doesn’t match what was agreed.
They have skin in the game
Risk-sharing mechanisms exist: milestone-based payments where you don’t pay until you approve, holdbacks tied to final acceptance, performance guarantees on critical metrics, fixed-price contracts on defined scopes.
Better still: developers who measure success by business outcomes, not just technical deliverables. Reduce reports from 8 hours to 15 minutes. Recover weeks of seasonal productivity. Integrate previously siloed systems. That’s success, not “code shipped on time.”
You own everything
From day one, you have source code repository access, admin credentials to all systems, documentation created during development, and clear IP ownership in the contract. If the developer disappears, you don’t.
Success metrics defined upfront
Before code is written, define what success looks like.
Not: deliver a user management system.
But: reduce new user onboarding time from thirty minutes to five.
Not: integrate the payment processor.
But: increase successful checkout completion from 70% to 90%.
Business outcomes, measurable, agreed upfront.
The uncomfortable truth
Sometimes developers aren’t entirely to blame. Owners who hired the cheapest bid and then complained about quality. Owners who changed requirements weekly and then blamed scope creep. Owners who refused to invest in documentation and then expected specific results. Owners who ignored obvious red flags because of sunk-cost fallacy.
Hard truths: cheap, fast, good — pick two. Unclear requirements create exploitation space. Time invested in process saves money and heartache.
Ethical developers will catch and push back on these patterns: let’s finish what we committed to before adding more. The cheapest option will cost more long-term, here’s why. Let’s document this properly before writing code.
We’d rather lose a project than watch a business fail. Saying “no” to mid-project additions is hard. Service businesses naturally want to say yes. We don’t, because the original problem matters more than chasing exciting new features that water down the result.
What to do next
Start with the problem, not the solution. Document exactly what’s broken, what it costs, and what success looks like. Do this before talking to any developer.
Get multiple opinions. Compare approaches and communication, not just pricing. The cheapest bid usually has reasons.
Look for red flags. One or two warning signs should be enough to walk away. The early indicators are usually accurate.
Test the relationship before betting big. Start with discovery or a small phase. Assess communication, problem-handling, and follow-through before major commitment.
Trust your gut. If something feels off, it usually is. If they make you feel stupid for asking questions, they’re not your partner.
Common questions
How do I tell the difference between scope creep I caused and scope creep the developer is exploiting?
Look at the artifact: did you both sign off on a scope document at the start, in plain English, with measurable success criteria? If yes, anything not in that document is genuine new scope. If you’re adding it, it’s your scope creep. If they’re saying “that was always implied,” it’s theirs. The document is the arbiter.
What’s a fair fixed price for a software project?
For a focused MVP that ships in 3 to 6 months, $50K to $200K is a reasonable range depending on complexity. Larger systems run higher. Subscription-style engagements (a senior US team for a flat monthly rate) often work better than fixed-price for ongoing work because they preserve flexibility without the developer profiting from delay.
What if I’ve already paid most of the money and they’re holding the project hostage?
Get an independent technical audit ($2K to $5K) before paying anything else. Sometimes the audit reveals the work is salvageable. Sometimes it reveals you should walk away and find a new developer to start fresh. Either way, you’ll have data instead of just feelings.
How do I check if a developer actually owns the code they wrote for me?
Look at your contract. The IP ownership clause should be explicit. If it isn’t, that’s a problem and you should ask in writing for clarification. Also: do you have admin access to the code repository? Can you log into the hosting account? If the answer to either is “no,” you don’t actually own the work even if the contract says you do.
What does Pilot West actually do differently?
We turn away about 80% of prospects. We work on a flat monthly subscription, not hourly billing. You own the code from day one. Senior US developers, capped at two clients per developer maximum (full capacity available if you want it). Sixty-day money-back guarantee if we’re not the right fit. Working software shipped in weeks, not months. Plain English, no jargon. We tell prospects “don’t build” more often than we tell them “let’s build.”
You’re not foolish for getting burned. The system disadvantages you. But you’re not powerless. Now you know what matters.
If you want an honest assessment of whether your situation calls for a custom build, an integration, or a configured off-the-shelf platform, our Custom Enterprise Software page covers what we actually do, or book a free thirty-minute consultation. We’ll tell you if we’re not the right fit. We’ll tell you if you’re not ready. We’ll point toward better solutions if needed. Consultants first, developers second.
