Why Automated Testing Saves Money (Even on Small Projects)

Automated testing saves money in two ways: fewer bugs reach your customers, and every change after launch gets cheaper because nobody has to click through the whole app by hand before each release. The same logic holds on small projects, as long as the tests cover the parts of the app that make money or could do real damage when they break.

I'm a freelance full-stack developer based in Denmark. I build and maintain web apps, mostly in Laravel, where I usually write tests with Pest. Below is the business case as I'd explain it to a client, what to test first, and when tests aren't worth paying for.

The short answer

Think of automated tests as insurance that also makes you faster. You pay a premium while a feature is being built, and in return every later change costs less and carries less risk.

My rule of thumb: if the app will live longer than a few months and keep changing, tests for the critical workflows pay for themselves. If it gets binned after a demo, they don't. Testing is one part of a bigger delivery process, and you can see where it fits from first idea to production in my guide to the software development process.

What an automated test actually is

An automated test is a small piece of code that checks one specific scenario and answers yes or no. "A customer can log in with the right password but not the wrong one." "An order of three items with a discount code gets the right total, VAT included." "A user at one company can't open another company's invoices." The tests run every time a developer pushes a change, and if one fails, the change doesn't ship.

You'll hear about three kinds:

• Unit tests check one small piece in isolation, such as the function that calculates shipping. They're fast but say little about the app as a whole.
• Feature tests (often called integration tests) check a complete flow: a request comes in, data is saved, an email goes out. Laravel's documentation recommends that most of your tests be feature tests, since they give the most confidence that the whole system works (Laravel testing docs).
• Browser tests (end-to-end tests) drive a real browser and click through like a user would. They catch problems in how the pieces fit together, but they're slower and more fragile, so I save them for the handful of flows that matter most.

Laravel ships with Pest and PHPUnit ready to go, and it can swap emails, queues and calls to outside services for fakes during a test. A test can run a full checkout without contacting Stripe or emailing a real customer. That's one reason Laravel is my default, which I go into in why I use Laravel for most web apps.

Where the savings come from

The most useful study I know on this comes from Microsoft and IBM. Researchers followed four industrial teams that wrote tests before the code (test-driven development) and compared their products with similar projects built without it. Pre-release defect density fell by 40-90%, while the teams estimated that initial development took 15-35% longer (Nagappan et al., Empirical Software Engineering, 2008). Four teams at large companies isn't a law of nature, but the direction is clear: you pay a bit more up front and get far fewer bugs.

The other half of the case is speed. Martin Fowler, a well-known author on software design, argues that developers feel poor internal quality slowing them down within a few weeks (Fowler: Is High Quality Software Worth the Cost?). Code nobody dares change, because no safety net catches mistakes, is exactly that kind of drag.

A worked example in euros

Picture a small B2B customer portal with eight workflows that must never break: login, password reset, customer-specific pricing, placing an order, card payment, invoice download, user management and the nightly export to your accounting system. I'll use €100 an hour because it's a round number, not because it's anyone's quote:

• Without tests, someone has to click through all eight before every release. Done properly, that's easily 45 minutes. At two releases a month, that's 18 hours, or €1,800 a year, and it's tedious work that in practice often gets skipped.
• Tests for those eight workflows might take 2-3 days, roughly €1,500-2,400, depending on how tangled the pricing and payment rules are. After that, they run on every change without adding hours.
• One pricing bug that reaches customers can easily cost more than the tests: wrong invoices, credit notes, awkward calls with your best accounts, and an emergency fix at the worst possible moment.

So the manual re-testing alone roughly matches the cost of the tests within the first year. That's before counting a single prevented bug, or the time saved when a developer can clean up code without fear. Plug in your own numbers. For an app you'll run for years, the answer rarely changes.

What to test first on a small project

The number of tests matters less than where they sit. My priorities are the same whatever the size of the project, from most to least important:

1. Money. Prices, discounts, VAT, subscriptions, invoices and payments. A calculation error here hits revenue directly and is often found late. If you sell to customers in several EU countries, per-country VAT is a classic spot for quiet mistakes.
2. Access. Login, roles and who can see what. A bug here can show one customer another customer's data, which under GDPR can count as a personal data breach.
3. The core workflow. The one thing the app exists for: the booking, the order, the application. If that breaks, nothing else matters.
4. Integrations. Calls to your payment provider, accounting system or CRM, such as Stripe, Xero or HubSpot. Tests run against fakes so they stay fast and stable, while monitoring in production keeps an eye on the real connection.
5. Bugs you've already had. My rule of thumb is that every fixed bug gets a test that catches exactly that bug. It won't come back, and over time your tests cluster where the app is actually fragile.

What I usually don't test: layout and colors, copy that changes often, simple pages with no logic, and the framework's own features, which its maintainers already test. That time is better spent on points 1-3.

A word on test coverage, the share of your code the tests actually run through. It's a useful thermometer and a poor target. You can hit 100% with tests that check nothing important, and 60% can be plenty if it's the right 60%. Ask which of your critical workflows are covered instead. That question is also on my list of 12 signs of a healthy (or unhealthy) codebase.

How to add tests to an app that has none

No tests today isn't a reason to start over. This is how I approach code I take over without a safety net:

1. List the 5-10 workflows that must never break. That's a business conversation, not a technical one, and you know the answer better than your developer does.
2. Start with broad tests. Feature tests that exercise a whole flow from the outside catch the most and don't need clean code inside. They pin down what the app does today, quirks included, so you'll notice when a change moves something.
3. Run the tests automatically on every change, for example with GitHub Actions. A test that only runs when someone remembers is barely a test.
4. Keep the suite fast and reliable. DORA, a long-running research program on software delivery, recommends that developers get feedback from automated tests in under ten minutes and that flaky tests get fixed rather than ignored (DORA on test automation).
5. Grow coverage as you go. Every new feature and every bug fix comes with tests, so coverage grows where the app actually changes, without a separate big project.

Once the critical workflows are covered, two things suddenly get cheaper: cleaning up old code and keeping your framework and packages current. Both are risky without tests because nobody can see what breaks. That ties straight into technical debt and the cost of waiting, and into why you shouldn't put off dependency updates.

When tests aren't worth the money

Tests are an investment, and not every investment pays off. I'd skip them or keep them minimal when:

• It's a prototype meant to show an idea to investors or users and then be thrown away. Speed matters more here. Be honest with yourself, though: prototypes have a habit of ending up in production.
• It's a simple marketing website with no logic, where the worst case is a typo. A quick check after publishing is enough.
• The app will be retired within a few months and won't change again.
• The tests check implementation details instead of behavior. Tests that break every time a button moves cost more than they save, and then it's the tests that need rewriting.

Automated tests also don't replace trying new features yourself on a staging site before they go live. Tests check what you already know should work. A person notices what nobody thought of.

When not to hire someone like me for this

I offer maintenance and ongoing development of existing web apps, but you shouldn't hire me to write your tests if:

• you have an in-house developer who knows the system. Give them time to write tests rather than bringing in someone who first has to learn the codebase.
• the app is built on a stack I don't work with. I work with Laravel, PHP and JavaScript (React and Next.js), so for .NET, Java or Ruby on Rails you'll want a specialist.
• it's an off-the-shelf SaaS product you subscribe to. Then testing is the vendor's job.

Next steps

Start by finding out where your app stands. Take these questions to your developer or agency. The answers show whether you have a safety net or are paying for bugs instead.

If your app has no tests, or you'd like a second opinion on the ones it has, take a look at how I handle maintenance and development for existing web apps. I'm based in Denmark (CET), you deal directly with the developer who writes the code, and you get a reply within one business day.

Frequently asked questions

How can I tell if my app has automated tests?+

Ask your developer to run the test suite while you watch, or to send a screenshot of the latest run. You don't need to read code to do this. If the code lives on GitHub or GitLab, you'll often see a green check or a red cross next to each change, which means tests run automatically. If there's no tests folder and no automatic run, you have your answer.

How do I compare quotes when only one includes tests?+

Ask every developer which workflows they'll cover with tests and whether those tests run automatically on each change. A cheaper quote is sometimes cheaper precisely because testing was left out, and you pay the difference later in bugs and slower changes. To compare like with like, ask the cheaper developer to price the same test coverage, and make tests part of the deliverable rather than an optional extra.

Does AI-generated code need fewer tests?+

No, if anything it needs more. AI coding tools write a lot of code quickly, but they don't know your business rules, and they can break something that worked yesterday without telling you. Tests are the description of what the app must do, and AI-written code gets checked against it. Apps built fast with tools like Lovable or Bolt can easily have no tests at all, so that's one of the first things I look at.

What does it cost to add tests to an existing app?+

A first round covering the 5-10 most important workflows is usually a matter of days, not months. The price depends on the size of the app and how messy the code is, so treat this as a rough starting point. Ask for a fixed price on that first round. After that, coverage can grow alongside the regular work, so it never turns into a big project of its own.