When to Hire a Developer (and When You're Just Burning Money) — hiring
· 6 min read
← all share ↗

When to Hire a Developer (and When You're Just Burning Money)

The decision filter for build, rent, or hire — plus the contract detail that decides whether you own the software you paid for. A 'work made for hire' clause doesn't transfer software copyright; only a written assignment does.

Ownership and contract points here reflect US copyright law as published by the Copyright Office, checked August 5, 2026. It’s operational guidance from someone who writes these contracts, not legal advice — for anything consequential, have a lawyer read the agreement.

I get two kinds of messages.

The first: “Can you build this?” — and the answer is yes, but they could get 80% of it from a $30/month tool and one focused weekend.

The second: “I’ve been fighting this spreadsheet / no-code stack / half-built WordPress setup for nine months” — and the answer is also yes, but they should have called six months ago, before the workarounds calcified into policy.

Both are expensive. This is the filter that catches them.

Three lanes, not two

Most people frame this as DIY versus hiring a developer. Real life has three:

  1. Use a generic tool as designed. No customization, no glue. You adapt to the software.
  2. Configure and glue. Templates, automation tools, spreadsheets, site builders. You assemble.
  3. Custom build. Software shaped to your workflow. Someone writes code.

Money leaks when the lane doesn’t match the problem’s actual shape — and the most expensive error isn’t picking the wrong lane once. It’s staying in lane 2 for two years after the problem outgrew it.

Do the arithmetic before the argument

Three numbers, one afternoon, and most of these decisions answer themselves.

1. What you currently pay in software rent. Add up every subscription touching this workflow. Small businesses routinely find $150–$400 a month across tools they half-use — with a couple that exist only to paper over a limitation in another one.

2. What you pay in hours. Time the manual work honestly for one week: re-entering data, reconciling systems, fixing the thing someone sorted wrong. Multiply by your real hourly value — for an owner, that’s what you’d bill or what you’d pay someone competent, not minimum wage.

Six hours a week at $50 is $15,600 a year, and it’s usually invisible because it’s your own time and nobody invoices you for it.

3. What a scoped build costs. For one narrow workflow, a competent contractor is typically a few thousand to low five figures, plus hosting in the tens of dollars a month, plus a maintenance arrangement.

Now compare like with like over three years, not one:

Three-year costWhat you get
Stay manual~$47,000 of hours (at 6 hrs/week, $50)Nothing new; the tax recurs forever
SaaS rent~$9,000–$14,000A solved standard problem, someone else’s roadmap
Scoped customBuild + ~$1,500 hosting/maintenanceYour workflow, encoded — and a thing you now own and must maintain

The point of the table isn’t that custom wins. Often it doesn’t. The point is that “we can’t afford a developer” is usually said by businesses already spending more than the developer would cost, in a currency they don’t count.

Stay in DIY when…

  • The workflow is standard. Booking, invoicing, basic e-commerce, email capture. These are solved problems with mature tools, and your version of them is not special, however special it feels.
  • Failure is cheap. If the process breaks, you can fall back to a phone call and a notebook for a week without losing the business.
  • You’re still discovering the rules. If you can’t yet say what “done” looks like, a custom build will faithfully encode your confusion at considerable expense. Spreadsheets are excellent for figuring it out — that’s the line explored in the spreadsheet is not a business system.
  • The workflow changes constantly. Software is expensive to change and cheap to run. If the process is still moving weekly, wait until it stops.
  • One person does it and always will. Custom tooling earns most of its value at handoff — multiple users, turnover, delegation. A solo task done well in a spreadsheet is fine indefinitely.

DIY is how most healthy small businesses start. There’s nothing embarrassing about it, and plenty of businesses never need to leave.

Hire when…

1. The tool is load-bearing

If the spreadsheet or cobbled stack going down stops the business, you’re past DIY theatre. Load-bearing systems need validation, multi-user safety, an audit trail, backups, and the ability to be run by someone who isn’t the tribal elder who built it.

2. You’re paying a weekly tax in hours

You calculated it above. If it’s real and recurring, custom tooling frequently pays for itself inside a year — the same math as inventory sync across channels.

3. Off-the-shelf forces a bad process

SaaS is opinionated by design. When the tool’s opinions actively fight how you operate — and the workaround involves three people, a shared doc, and a prayer — configuration has hit its ceiling. Note the honest inverse: sometimes the tool’s opinion is better than your process, and the correct answer is to change the process. Ask which it is before you pay to encode your version.

4. Money, stock, or compliance accuracy is on the line

DIY that double-sells inventory, mis-tallies deposits, or leaks customer data isn’t frugal. It’s a deferred, larger invoice with a reputational component.

5. You’ve failed at DIY twice

Two abandoned attempts is data. It doesn’t mean you didn’t try hard enough — it means the problem is genuinely harder than the tools you’ve pointed at it, and the third attempt will end the same way.

The expensive middle

The worst outcome is neither lane. It’s half-custom, half-abandoned:

  • A developer who “started something” and went quiet
  • A no-code app only one employee understands, who is now on holiday
  • A plugin stack nobody will update because everyone’s afraid of it
  • A site that’s been almost done for fourteen months

This zone costs more than clean DIY or a scoped professional build, because it carries all the fragility of custom software with none of the ownership, documentation, or support. If you’re in it right now, the fix is rarely “keep going.” It’s to decide which lane you’re actually in and get there deliberately.

Who owns what you paid for

Here’s the part that costs small businesses the most and gets discussed the least.

Under US copyright law, when you commission work from an independent contractor, the contractor owns the copyright by default unless one of two things happens.

The first is “work made for hire.” That status applies to contractors only when the work falls into one of nine specific statutory categories — contributions to a collective work, parts of audiovisual works, translations, supplementary works, compilations, instructional texts, tests, answer material for tests, and atlases — and there’s a signed written agreement saying so. Both conditions are required.

Custom software is not among those nine categories. Neither is a standalone logo. So a contract that simply declares your web application a “work made for hire” does not do what the person who pasted it in thinks it does.

The second path is the one that actually works: a written assignment of copyright, signed by the owner of the rights being transferred. Transfers of copyright ownership generally have to be in writing and signed to be effective.

Practically, for anything custom you commission, your agreement should include:

  • An explicit assignment of copyright to your business — not only a work-made-for-hire recital, which may be inoperative for software.
  • Everything in accounts you own. Repository, hosting, domain, DNS, database, third-party API keys. The developer gets access to your accounts; you don’t get access to theirs.
  • A named deliverable list, including source code and deployment instructions, not just a running site.
  • Third-party components identified, with their licences, so you know what you own outright and what you’re using under someone else’s terms.
  • What happens if they disappear. Handover terms, and where the code lives if the relationship ends badly.

None of that is adversarial. Any competent contractor expects it, and the ones who resist are telling you something useful.

How to hire without getting burned

Make the first engagement small and sharp.

  1. One workflow. Not “digitize the company.” One painful process with a clear boundary.
  2. A written definition of done. What can a person do on day one that they couldn’t do before? If you can’t write that sentence, you’re not ready to hire yet.
  3. Your current process is the spec. The spreadsheet, the paper forms, the screenshots, the sticky notes on the monitor — you already wrote the requirements by living them. Hand those over rather than trying to write a formal document in a language you don’t speak.
  4. Ownership and access from day one, per the section above.
  5. Maintenance clarity in writing. Who updates it? What does a change cost? What’s the response time when something breaks on a Friday?

A good first project is boring on purpose: the appointment flow, the inventory sync, the quote request that lands in the right inbox. Boring is billable and boring ships.

Questions to ask, and answers to worry about

Ask: What would you do first? A good answer starts with watching how the work happens today. A worrying answer starts with a technology choice.

Ask: What’s the smallest version that’s useful? Good contractors reach for a smaller scope than you proposed. If the scope only ever grows, notice that.

Ask: What happens after launch? You want a straight answer about maintenance and cost. “It’ll just run” is not an answer; software rots as its dependencies, browsers and platforms move.

Ask: Who owns the code and where does it live? You want “you do, in your GitHub account, and here’s the assignment clause.” Hesitation here is the single most reliable red flag in this entire article.

Three worked examples

A two-van plumbing company scheduling by text. Standard workflow, cheap failure mode, one person doing it. Verdict: stay in lane 1 or 2. A booking tool with automated reminders solves this for the price of a tank of fuel — the build is in appointment reminders without renting a $200/mo SaaS. Hiring a developer here is buying a bespoke suit to mow the lawn.

A resale shop selling across three marketplaces from one stock pool. Money and inventory accuracy on the line, multiple systems that must agree, a recurring reconciliation tax, and a failure mode — overselling — that costs money and seller ratings. Verdict: lane 2 first, then lane 3 when the glue starts failing. Off-the-shelf sync tools exist and should be tried before commissioning anything; where they break is usually a quirk of how you handle bundles, condition grades, or returns.

A trades business with a quoting spreadsheet three people edit. Runs weekly, involves money, several people touch it, mistakes are embarrassing in front of customers, and everyone has developed private workarounds. Verdict: lane 3, scoped narrowly. Not “an app for the business” — a quoting tool that produces one correct number and one PDF, replacing exactly the spreadsheet and nothing else.

Notice the pattern: the trigger is almost never ambition. It’s multiplicity — more people, more systems, more money, more ways to be wrong.

A simple scorecard

Score each 0–2 (no / kind of / yes):

  • This process runs daily or weekly and involves money, stock, or customers
  • More than one person has to touch it
  • Mistakes are expensive or embarrassing
  • We’ve outgrown the current tool at least twice
  • We can describe the happy path and the edge cases out loud
  • The manual hours are worth more per year than a scoped build

0–4: stay with DIY or SaaS. Spend the money on marketing instead. 5–8: configure harder, or hire for one narrow automation rather than a build. 9–12: stop duct-taping. Commission the real fix, scoped tightly.

After launch: the part people forget to budget

Custom software isn’t a purchase; it’s an adoption. Plan for:

  • Dependency updates, a few hours a quarter, or it becomes unpatchable in about two years.
  • Small changes as the business changes. Budget a modest monthly retainer or an agreed hourly rate, and expect to use it.
  • Someone else being able to run it. Ask for a short written handover — how to deploy, where things live, what the failure modes are. Two pages is enough, and it’s the difference between an asset and a hostage situation.
  • An exit plan. If your contractor moves on, another competent developer should be able to pick it up. Standard tools, plain documentation, your accounts.

Businesses that skip this don’t discover the omission for eighteen months, and then rebuild — which is how a company ends up paying for the same system twice.

Where AI changes this, and where it doesn’t

Worth addressing directly, because it’s the live question in every one of these conversations.

What’s genuinely changed: the floor moved up. A determined owner with AI assistance can now produce a working internal tool that would have needed a contractor three years ago. Small scripts, one-off data cleanups, glue between two systems, a simple internal form — these are real DIY territory now, and pretending otherwise wastes your money.

What hasn’t changed: the things that made custom software expensive were never mostly typing. They were deciding what the system should do at the edges, keeping it running as everything underneath it moves, being on the hook when it’s wrong about money, and being able to hand it to someone else. Generated code doesn’t come with an owner.

The practical line: use AI to build things whose failure is cheap and whose lifespan is short. For anything load-bearing — money, stock, customer records, anything a regulator or a customer could hold you to — the question isn’t whether the code can be produced. It’s who is responsible for it at 6pm on a Friday in eighteen months.

That’s also the question to ask a contractor who’s clearly generating a lot of the work. It isn’t a problem in itself, provided they read it, own the result, and stand behind it.

What I’m not saying

I’m not saying developers are always the answer. Plenty of custom-app pitches are solutions hunting for a budget, and a substantial share of what people ask me to build should be a $30/month subscription and an afternoon of setup.

I’m also not saying DIY is embarrassing. I recommend it constantly, including to people who arrive expecting to hire.

What I am saying is: match the tool to the job’s seriousness, and notice when the job changed while you were busy. Almost nobody’s mistake was starting in a spreadsheet. The mistake was staying there for two years after it became the thing the business runs on.

If you’re sitting on a load-bearing spreadsheet or a stack of tools that only work while you’re watching them, tell us what breaks. We build the narrow thing that removes the pain — not a 200-feature platform you’ll resent in six months.

Sources

[read next]
hardware · aug 15
Nothing Phone (3) Review: The $799 Phone That Beats Both $899 Flagships for Small Business
wifi · aug 15
Your Guest Wi‑Fi and Your POS Are on the Same Network: The Small Business Wi‑Fi Security Setup That Actually Works