Is Cheap Custom Software Too Good to Be True?

Is cheap custom software any good, or is the price itself a warning?

The price on its own is not evidence either way, which is the uncomfortable part. Two suppliers can quote $1,500 against the same brief: one removed 250 hours of hand-typed boilerplate, the other removed the code review, the tests and your ownership of the repository. The invoice looks identical. The software does not, and you find out roughly four months later.

There is a useful distinction between cheap and affordable, and how to tell cheap from affordable development works through the buying signals in detail. This article takes the narrower question: what specifically goes wrong, how badly, and what you can verify before any money changes hands.

One framing worth discarding immediately is "you get what you pay for". That is a heuristic about markets in equilibrium, and software delivery is not currently in equilibrium. When a production method changes, price and quality decouple for a period, and that period is now. The heuristic is not wrong so much as out of date, which is why it has to be replaced with checks rather than instincts.

What actually goes wrong on cheap builds?

Six failures account for most bad outcomes, and every one of them is a failure of omission. None are visible in a demo, because a demo shows the happy path and all six live off it.

Security debt is the failure that compounds rather than simply hurting once. Veracode's 2025 State of Software Security, based on 1.3 million applications, reports that half of organisations carry critical security debt, that average remediation time has risen from 171 to 252 days over five years, and that more than 70% of critical security debt comes from third-party code. A build assembled quickly out of dependencies nobody checked inherits all of that on day one.

The AI-specific version of this is now measurable. DORA's 2025 State of AI-assisted Software Development, based on responses from nearly 5,000 technology professionals, found AI adoption relates positively to software delivery throughput and negatively to delivery stability — more change, less reliably. GitClear's 2025 research, analysing 211 million lines of changed code from 2020 to 2024, found copy-pasted lines rose from 8.3% of the total to 12.3% while refactored lines fell from 24.1% to 9.5%. Fast generation without review produces duplicated code nobody can maintain, which is exactly what the review step exists to catch.

Why can a low price be legitimate at all?

Because the hours changed. In a controlled experiment by researchers at Microsoft Research, GitHub and MIT Sloan, developers with an AI assistant completed a standardised programming task 55.8% faster than the control group, finishing in 71 minutes against 161. Applied across the repetitive parts of a build — scaffolding, forms, CRUD endpoints, admin screens, test fixtures — that compounds into most of the hours a traditional quote is paying for.

Set that against the market and the size of the claim becomes clear. FullStack Labs' 2026 Software Development Price Guide reports 65.7% of custom software projects fall between $30,000 and $100,000, with only 14.1% under $30,000 at the time of writing, and Clutch puts the average project at $132,480 over about 13 months. A fixed $500 to $2,500 price sits far outside that distribution, and the only defensible reason is a different production method: AI writing the first draft, senior engineers reviewing, testing and hardening every build, and no bench or management layer to fund. If a supplier cannot state their mechanism in one sentence, treat the low price as unexplained.

The dishonest version uses the same tools and skips the second half. Prompt, paste, invoice. That is the entire difference, and it is why every check below is about the review step rather than about the number. Our process is written down for precisely this reason, so it can be checked rather than believed.

How do you tell the two apart before you pay?

With a decision tree rather than a gut feeling. Every branch below is answerable in one email, and a supplier who evades any of them has already told you something useful.

The order matters. Price terms and ownership come first because they are the two answers that stop being negotiable the moment a deposit clears, and they are the two that decide whether a bad outcome is recoverable at all.

EVALUATING A LOW QUOTE

  Is the price FIXED in writing, with the scope itemised?
      NO  -> it is an estimate. Stop. The low number is marketing.
      YES v

  Will the code live in YOUR repository and YOUR cloud from day one?
      NO  -> you are renting software you paid to own. Stop.
      YES v

  Can they NAME the senior engineer who reviews before release?
      NO  -> nobody is checking the machine's work. Stop.
      YES v

  Are there automated tests, and can you watch them run?
      NO  -> every future change is a gamble. Negotiate them in.
      YES v

  Can you use a staging build yourself before final payment?
      NO  -> you are buying screenshots. Stop.
      YES -> the low price is probably method, not corner-cutting.

What are the ten checks, and how does PINCLER answer them?

Here is the full protocol with the answer a legitimate supplier gives. Copy it into an email and send it to every bidder, including us. Any supplier who treats the list as an insult has answered it.

PINCLER's answers, on the record so they can be held against us: the price is fixed in writing between $500 and $2,500 before work begins; the repository is yours from the first commit and the system runs on your cloud and your database; a named senior engineer reviews and signs off every release; the bug-fix warranty runs 14 to 60 days depending on tier; and there is no handover fee, because there is nothing to hand over that you did not already own.

Two of these matter more than the other eight. Ownership decides whether a bad outcome is recoverable, and a named reviewer decides whether a bad outcome happens at all. Who owns your code goes through the ownership terms line by line, and what humans check in AI-assisted code review sets out what that review actually consists of.

What should a cheap price honestly not buy?

A supplier who will not name their limits has not found them. Ours are specific, and they are the same limits whether the project is quoted at $500 or at the $2,500 ceiling.

What the band does buy is one core workflow with standard integrations, tested, deployed to your accounts and documented, typically in 10 to 20 days. Bigger ideas get split into phases inside the same ceiling rather than quoted higher — there is no $9,000 tier waiting behind the published one. The catalogue of what fits, with prices and timelines, is at what you can build.

• Compliance programmes: SOC 2, ISO 27001, PCI Level 1 scope or formal HIPAA validation.
• A dedicated standing team, or guaranteed engineering capacity in a future quarter.
• Round-the-clock on-call cover and contractual uptime commitments.
• Migration of large undocumented legacy datasets out of systems with no API.
• Independent third-party penetration testing — we harden the build, but we are not an audit firm.
• Open-ended scope, or discovery work where nobody yet knows what is being built.
• Multi-year roadmap ownership with a standing backlog and a permanent squad.

When is a cheap build genuinely the wrong purchase?

Cheap is not always the wrong answer, but there are cases where it clearly is, and a supplier who wants to be trusted should say so before taking a deposit rather than after.

The test is dependency, not budget. If the software failing quietly on a Saturday night would cost you money, customers or a licence, buy the version that comes with an audit trail — even if you could easily afford the cheaper one. If it would cost you an afternoon, the cheaper one is the rational purchase and the extra $28,000 buys you nothing you will use.

• Regulated or safety-critical software where audit evidence is part of the deliverable, not an optional extra.
• Anything storing card data in PCI scope, or clinical records requiring formal validation.
• Systems where a single night of downtime costs more than the entire build.
• Long modernisation of a large legacy codebase — the setting where AI assistance has been measured to slow experienced developers down.
• Projects where the requirements genuinely do not exist yet and someone has to be paid to discover them.
• Anywhere you need a supplier large enough to indemnify you against a serious loss.

What mistakes do buyers make evaluating a cheap quote?

These are the seven that repeat. Each one is a habit rather than a lack of technical knowledge, which is why they catch experienced buyers as often as first-timers.

• 1. Judging by the demo. Demos show the happy path, and every failure in this article lives somewhere off it.
• 2. Accepting "we use AI" as an explanation. Everyone uses AI now — DORA found 90% of respondents use it at work. The question is who reviews the output.
• 3. Not asking where the repository lives until after the first payment, at which point the answer stops being negotiable.
• 4. Treating a warranty as a nice-to-have. It is the only mechanism that keeps a supplier interested in defects after your money has cleared.
• 5. Confusing a low fixed price with a low estimate. One is a ceiling; the other is an opening bid, and fixed price versus hourly billing explains who carries the difference.
• 6. Assuming the person in the sales call writes the code. Ask who, by name, then ask again at kickoff and compare the answers.
• 7. Skipping the ten checks because the supplier seems pleasant. Pleasantness and engineering discipline are unrelated variables.

PINCLER's perspective: what a hard ceiling forces

PINCLER is an AI-first custom software development studio. We build business systems — internal tools, dashboards, booking systems, CRMs, integrations and AI agents — with AI producing the first draft and senior engineers owning architecture, security, review and release. Every project is fixed price between $500 and $2,500, and that ceiling is the constraint the whole model is built around.

A hard ceiling changes behaviour in a way an hourly rate does not. If a build overruns, we absorb it, so scoping accurately matters more to us than it does to the client. Across our 79 documented projects the median was $1,450 and the median delivery 13 days, with the full range 3 to 30 days and 33 of the 79 shipping within a fortnight. Those are invoiced transactions rather than survey responses, which is the only reason they are worth quoting at all.

The tooling record is deliberately unromantic: GPT was used on 76 of the 79 projects, Cursor on 75 and Claude Code on 63, with a human senior engineer reviewing all 79. Typical builds include an AI customer support chatbot, an online booking and appointment system and a third-party integration and data sync. Whether machine-written code belongs in production is a question in its own right, and is AI-generated code safe to put in production answers it properly rather than in a paragraph.

The bottom line

Cheap custom software is too good to be true when nobody can tell you what was removed. It is a legitimate purchase when the answer is "the typing hours", the code lands in your own repository, and a named engineer reviewed it before release. That is a checkable claim rather than a promise, which is the whole distinction.

Run the ten checks on every bidder, including us, and treat evasion as data. If you want to see the answers applied to a real brief, our process sets out each step, and a 30-minute call produces a written fixed quote within a working day.