Automated and end-to-end testing · Build
Automated tests that stop the build when something breaks
For teams that drop tests first under a deadline: unit, component and end-to-end tests, wired into CI. Our own design system runs 678 of them.
EngagementHourly · remote
Hours9–18 CET · 4 h overlap
StackTypeScript · unit and component tests · end-to-end suites
Proof2 case studies
The service in 4 parts
01 · Who it’s for
A team whose tests are the first thing dropped under a deadline, or a product with no tests at all and a release button nobody wants to press.
02 · What we’ve built
- 678 tests across 62 suites in our cross-platform design system, covering the web, a SPA and native.Case study 01 →
- Two tests that check the emitted style directly, added after a layout bug crashed the app on a phone while typecheck, native tests and the production export had all passed. We proved them by putting the bug back and watching them fail on the exact property.Blog post →
- On a US marketplace for truck services, once the rules were enforced in CI, the team stopped writing tests by hand and generated them with Claude Code.Case study 03 →
Our end-to-end work so far is on two products of our own, still in development and without external users: 331 tests in one, 16 end-to-end suites in the other.
03 · How we work
01 · PROVEN TO FAILWe check each new test by reintroducing the bug it is meant to catch and making sure the test goes red.
02 · READABLEWritten so your team can read and extend the tests after we leave, as well as run them.
04 · Stack
TypeScriptunit and component testsend-to-end suitesheadless browser checksCI
Proof
Where we’ve done this before
Case study 01 · Platforms74 / 678678 tests across 62 suites in our cross-platform design system, covering the web, a SPA and native.Read the case study →WritingTesting a design system on a real page: 7 components and 8 gapsTwo tests that check the emitted style directly, added after a layout bug crashed the app on a phone while typecheck, native tests and the production export had all passed. We proved them by putting the bug back and watching them fail on the exact property.Read the post →Case study 03 · Platforms~50%On a US marketplace for truck services, once the rules were enforced in CI, the team stopped writing tests by hand and generated them with Claude Code.Read the case study →
FAQ
Questions about this service
Yes, but so far only for our own products, which are still in development. We haven’t run an end-to-end project for a client.
Whatever they don’t check for. On our design system a native test stayed green for a screen that could not open on a phone, because the test renderer never asks whether a component exists on the device. The fix was a check that fails if anything other than View or Text is rendered.
Yes, provided the checking is automatic. AI moves the work from writing tests to reviewing them, so generated tests only save time when the hooks and CI do most of that checking.
Yes. We start where a failure would cost you the most.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.