Freelance software development does work—but mainly under particular conditions. What often fails is the model of a small business buying a one-off custom application from an independent developer at a fixed price.
The central problem is not that coding is too expensive. It is that specifying, verifying, integrating, and maintaining custom software are expensive, while the value and scope are uncertain.
Why the default economics are difficult
1. The customer cannot specify the job in advance
A plumbing customer can often say, “Replace this water heater with that model.” The relevant interfaces, materials, and building codes are reasonably standardized.
A software customer says, “Automate our scheduling,” but that may conceal dozens of unresolved questions:
- Who may reschedule whom?
- What happens when records disagree?
- Which legacy system is authoritative?
- How are cancellations, refunds, and exceptions handled?
- What privacy rules apply?
- Does every employee follow the stated process?
- What does “integrate with Outlook” actually mean?
Much of the project consists of discovering the job. A fixed quote therefore forces the developer either to price in a large risk premium or to absorb scope risk. The customer, meanwhile, hears every clarification as an attempt to charge more.
This is an incomplete-contract problem: neither side can fully describe what is being purchased before work begins.
2. Customers cannot easily evaluate quality
A customer can see that an application appears to work, but usually cannot judge:
- Whether it is secure
- Whether its data model is sound
- Whether it will survive higher usage
- Whether dependencies are sustainable
- Whether another developer can maintain it
- Whether failures are handled correctly
- Whether the apparent result is held together by manual interventions
Low-quality and high-quality work can look identical at delivery. Their differences emerge months later.
That creates a market-for-lemons dynamic. Customers hesitate to pay for invisible quality, good engineers dislike competing with implausibly low bids, and reputation or institutional trust becomes more important than the code itself.
3. The cost is high relative to the customer’s willingness to pay
A competent independent engineer in a wealthy country needs to charge substantially more than an employee’s apparent hourly wage. Their rate must cover:
- Sales and unpaid consultations
- Time between projects
- Administration and accounting
- Health care, retirement, and taxes
- Equipment and software
- Training
- Failed or late-paying clients
- Liability
- Vacation and sick time
A developer who wants employee-equivalent compensation for 2,000 annual hours might have only 1,000–1,300 billable hours. Consequently, a sustainable rate can look exorbitant to a customer comparing it with a salary or a $50/month SaaS subscription.
Small companies often have real problems worth perhaps $10,000–$30,000 to them, but traditional custom development may cost that much before producing a robust first version.
4. Software competes with products that amortize development over thousands of customers
This is the deepest difference from plumbing.
A plumber cannot replace your physical pipe once and sell that same replacement to ten thousand households. A SaaS company can build scheduling software once and sell access repeatedly. Even mediocre generic software can be much cheaper than an excellent custom system.
So the independent developer is not merely competing with other developers. They are competing with:
- SaaS subscriptions
- Spreadsheets
- No-code tools
- Offshore agencies
- Existing manual processes
- “Good enough” features in Microsoft 365 or an ERP
- The option of doing nothing
Custom development wins only when the customer’s situation is sufficiently unusual or valuable.
5. Transaction costs dominate small projects
A nominally two-day implementation may require:
- Several sales calls
- Requirements discovery
- Contract negotiation
- Access provisioning
- Learning the customer’s systems
- Deployment setup
- Training
- Invoicing
- Support afterward
That fixed overhead makes small jobs unattractive to the developer and surprisingly expensive to the buyer. A plumber can often diagnose and repair a familiar physical system in one visit. A developer may spend days reconstructing a business’s undocumented digital environment before safely changing anything.
6. Every customer has a unique, decaying “site”
The journeyman’s digital job site may contain:
- Abandoned integrations
- Shared passwords
- Unreliable spreadsheets
- Undocumented business rules
- Unsupported dependencies
- Incorrect data
- A former contractor’s cloud account
- Employees whose actual process contradicts management’s description
This resembles renovation more than new construction: opening the wall reveals problems that could not have been quoted accurately.
Software platforms also change underneath the delivered system. APIs are deprecated, authentication requirements change, dependencies develop vulnerabilities, and customer workflows evolve. The job is rarely truly finished.
7. Maintenance does not fit the one-off-job model
Customers often think they are purchasing an artifact. In reality, they are creating a continuing operational dependency.
After delivery, someone must handle:
- Security updates
- API changes
- Backups and recovery
- Hosting incidents
- New regulations
- Employee turnover
- Feature requests
- Data corruption
- Questions from future maintainers
The original developer may be unavailable, while a new developer faces high takeover costs. This makes customers wary of being dependent on one person. It also creates awkward expectations that small fixes should be free because “you built it.”
A plumbing repair can fail later too, but software can require attention even when the original work was correct.
8. Fixed-price projects produce bad incentives
Under a fixed price:
- The customer benefits from expanding scope.
- The developer benefits from interpreting scope narrowly.
- Quality that is not in the acceptance criteria becomes a cost to the developer.
- Both parties are rewarded for arguing over whether something is a bug or a feature.
Under hourly billing:
- The customer bears the uncertainty.
- The developer appears to benefit from taking longer.
- Efficient use of automation can reduce the developer’s income.
- The final cost remains unknown.
Retainers, milestone contracts, value-based pricing, and shared-risk arrangements each solve parts of this, but none eliminates the fundamental uncertainty.
9. Customer acquisition is expensive and sporadic
A strong developer is not necessarily good at:
- Finding qualified buyers
- Establishing trust
- Explaining value to nontechnical managers
- Negotiating contracts
- Collecting payment
- Maintaining a referral network
Small custom projects require almost as much trust-building as large ones but produce much less revenue. Agencies survive partly by centralizing sales, project management, legal work, and reputation—but that overhead raises the price further.
This is why many nominal freelancers converge toward long-term staff augmentation: one client, months of work, hourly billing. Economically, they become temporary employees because that removes repeated sales and discovery costs.
10. The best engineers have attractive alternatives
An engineer can instead:
- Take a stable, well-paid job
- Join a startup for equity
- Build a reusable product
- Consult for large enterprises at high rates
- Become a long-term contractor
One-off local projects offer limited upside and substantial downside. If the engineer creates enormous value, the customer owns most of it. If the project overruns, the engineer bears much of the cost. Product businesses are risky, but at least software’s replicability works in the producer’s favor.
That selection effect can make it harder for buyers to find excellent independents, reinforcing the trust problem.
Where freelance development already works
So you are wrong if the claim is “freelance software development is not a viable business.” It plainly is. It works especially well when one or more of the preceding problems are controlled.
Long-term contracting
A developer joins a team for six or twelve months. The customer already has product management, infrastructure, requirements processes, and technical supervision. This is less like hiring a plumber for a repair and more like hiring an additional tradesperson for a construction project.
High-value specialist consulting
Security audits, performance engineering, database recovery, cloud migration, regulatory systems, and specialized integrations can support high rates. The problem is narrow enough to evaluate, and the cost of failure or delay is high.
Repeated work within a vertical
A developer who has built systems for twenty dental practices is not really starting from scratch on the twenty-first. They know the terminology, vendors, regulations, edge cases, and buyer. Discovery costs fall, reusable assets accumulate, and quoting becomes possible.
This is probably the closest current analogue to a software trade.
Productized services
Instead of “I build custom software,” the provider sells something bounded:
- “I migrate this class of application to this platform.”
- “I automate invoice intake for firms using these three systems.”
- “I perform a two-week agent-security assessment.”
- “I replace spreadsheet scheduling with this supported stack.”
Standardization turns uncertain consulting into a more legible service.
Agencies and trusted referral networks
Agencies bundle reputation, continuity, sales, design, engineering, and support. They can substitute another engineer if one leaves. The customer pays a premium partly to reduce key-person risk.
Relationships based on trust
Many independent consultancies thrive through referrals and repeat business. Once the client trusts the developer, adverse-selection and monitoring problems shrink dramatically. The freelancer becomes an outsourced technical department rather than a bidder for isolated jobs.
Platforms with tightly bounded tasks
Freelance marketplaces work tolerably for websites, scripts, data cleanup, plugin configuration, and other jobs with low consequences and relatively clear outputs. They work less well for systems central to a business unless the relationship becomes long-term.
Why plumbing is an illuminating but imperfect analogy
Plumbing has several institutional advantages:
- Standardized physical components
- Building codes and inspections
- Licensing and apprenticeships
- Local reputation
- Geographic protection from global competition
- Familiar categories of work
- Observable symptoms
- Established liability and insurance
- A clear distinction between installation and maintenance
- Assets whose interfaces change slowly
Software lacks much of this. There is no universally accepted code specifying how an internal scheduling application must be built. A developer in another country can bid on the job. The frameworks may change next year. The buyer often cannot inspect the work, and the work’s boundaries coincide with poorly understood organizational processes.
On the other hand, plumbing also has uncertain diagnosis, hidden conditions, change orders, poor-quality operators, and continuing maintenance. The analogy is not false; software is simply a less standardized and more rapidly changing trade.
What AI could change
AI could make the journeyman model viable by reducing the cost of implementation, documentation, testing, and adaptation. A single engineer might economically serve customers whose projects were previously too small.
But cheaper code alone does not solve the business model. It may even intensify some problems:
- More low-quality suppliers enter the market.
- Customers become less willing to pay for implementation.
- Generated systems proliferate faster than they can be maintained.
- Security failures become easier to create.
- Buyers have even more difficulty distinguishing reliable work from demos.
- A customer may ask, “Why am I paying you $20,000 if the model wrote it in an afternoon?”
The answer must be that the engineer is selling something other than code generation: diagnosis, safe integration, validation, accountability, and continuity.
For the model to resemble a mature trade, it likely needs supporting institutions:
- Standard service categories, so jobs can be compared and quoted.
- Technical codes, defining minimum security, portability, backup, and documentation requirements.
- Portable proof packages, enabling another engineer to inspect and assume maintenance.
- Credentials based on demonstrated work, not merely courses or model-specific trivia.
- Warranties and professional insurance, making accountability economically real.
- Reusable approved stacks, reducing unique dependencies and takeover costs.
- Local or vertical reputation networks, addressing the lemons problem.
- Maintenance contracts, rather than pretending delivery ends the relationship.
- Clear change-order procedures, separating discovery from implementation.
- Independent inspection, especially for security-sensitive systems.
A guild, union, professional association, franchise, or marketplace could provide these. “Union” may not be the exact economic form: unions primarily bargain with employers, while a guild or licensed professional association sets entry and quality standards, and a cooperative could pool sales, insurance, tools, and support. A successful institution might combine all three.
The likely viable model
The strongest version is probably not:
Hire a generic programmer to build anything you describe.
It is closer to:
Hire an accredited specialist who repeatedly solves this class of operational problem using a supported stack, provides independently checkable evidence, and warrants the outcome.
That person may look like a freelancer, but economically they are a small vertical integrator backed by agents and shared institutions.
The old freelance model sells hours of implementation. The journeyman model would need to sell bounded outcomes plus trusted stewardship. AI makes the labor economics more favorable, but standardization and trust are what make it a business.