The ripple effect: a change in one corner of the system breaks something in the opposite corner, and nobody notices until a customer complains. The older the product, the more each ripple costs. Test automation puts a check in the ripple's path that fires within minutes of every change, rather than a week later in the form of a lost order.
This is a track from the corporate growth block. It is added once the product is live and moving from MVP to MMP and MLP, and releases become regular. The guide price for the track in the Ingello price list is $4,700.
What manual checking costs
While the system is small, someone can click through it before every release. Then there are dozens of scenarios, several roles, more than one integration, and a full manual check takes days. The team starts checking selectively, and bugs reach users. Or releases become rare and large, which makes them even riskier.
What the work includes
The price list describes the track in three lines: introducing automated tests, cutting the cost of manual functional checks after changes, and reducing the risk of the ripple effect when the product is extended. In practice this means several levels of checks:
- Business rule tests: calculations, discounts, statuses, transitions between states. Fast and cheap, so they make up the largest share.
- Tests of exchange with external systems: payments, CRM, delivery services. Responses from external services are stubbed, so a test does not depend on someone else's uptime.
- End-to-end scenarios in the browser: sign-up, ordering, payment, work in the account area. We use Playwright for this.
- An access matrix test: which screens and actions each role is entitled to.
- Test data that looks real: generated with Faker, without copying real customers.
- Running every check on each code change in a CI/CD process, set up during the deployment and infrastructure stage.
What to cover first
Not everything at once. Start where a bug costs money: calculations, access rights, checkout, exchange with external systems from integrations. A test for the colour of a button almost never pays off.
It is also worth covering the access matrix with a test. It is the only reliable way to keep permissions from drifting during changes, and it directly supports security.
How the rollout works
- Review: together with you we list the scenarios where a bug costs money and rank them by the cost of failure.
- Preparation: we set up the test environment, data generation and automatic test runs.
- Coverage: we write tests from the most expensive scenarios down to the less important ones and show each batch working.
- Handover: a report on what is covered and a list of scenarios worth covering next.
What you get
- A suite of automated tests for money-critical scenarios, built into the release process.
- A report after every change: what was checked and what failed, with the exact location.
- The ability to release more often and in smaller pieces, which is safer.
- A safety net for refactoring and for new developers who do not yet know every connection in the system.
The economics are simple
A manual check costs the same every time. An automated one costs a lot once and almost nothing afterwards. The break-even point arrives sooner the more often you release changes.
How much it costs and what drives the price
The guide price is $4,700 for the track. Scope depends on the number of money-critical scenarios, roles and integrations, and on how testable the code is. If business logic is smeared across templates and controllers, targeted refactoring comes first, otherwise the tests turn out brittle. If another team built the project, the first step is an audit: $800 or $2,400.
Do not confuse this track with the testing and handover stage (from $800 to $4,700). That stage checks and fixes what was built to the specification before the project is handed over. This track creates a mechanism that repeats the checks by itself on every later change.
What breaks if you cut corners
- Customers find the bugs, and each one costs an order, a review or a support call.
- Releases get postponed because there is no time for manual checks.
- Access rights quietly drift apart: an employee sees what they should not.
- Refactoring becomes a lottery, and people stop improving the code.
An example from our practice
In our Fractal technology, tests are built into the process of producing systems itself. The generator is checked against reference schemas, and Playwright end-to-end scenarios are built from the generated screens. As a result, every new prototype or module gets a basic interface check straight away, without anyone writing scenarios by hand. More in the case study on the AI developer that writes to an architecture.
The same approach works outside product code. In our news pipeline, headline rules (a search title of up to 60 characters, the brand suffix exactly once) are enforced by a test, not by an editor's attention. A rule fixed in a test is not forgotten when people change.
Where to go next
Related tracks: refactoring and documentation. The map of all stages is in the app development strategy.
In a free consultation, an Ingello architect will work out which scenarios in your system cost money when they fail and suggest where to start coverage. Afterwards you receive a price and timeline estimate broken down by stage. Discuss product quality.
