CI

Continuous integration: automatically building and testing every commit so breakage is caught within minutes, not at release time.

Continuous integration means every push runs the gauntlet: a service checks out the code, installs dependencies, builds, runs the test suite and lints, and reports green or red within minutes. Broken changes are caught at the commit that caused them, while the author still has the context loaded, instead of on release night when the cause is buried under a week of work.

Why it matters to an indie builder: CI converts merge fear into routine. For a solo founder it is the second pair of hands that runs the tests you would skip at midnight; for a small team it is the referee that keeps main always deployable. And it is nearly free: GitHub Actions gives generous free minutes to public and private repos alike, and the configuration for a typical app is an afternoon of setup that pays back the first time a red X saves you.

A concrete example: a payments bug. A contributor changes a rounding function; three tests fail on the CI run; the fix is a two-line correction before merge, total elapsed time eleven minutes. The same bug without CI merges silently, ships in Friday's release, and surfaces Monday as 400 corrupted invoices and a morning of database surgery. The pipeline caught in minutes what production would have charged in days.

Common mistakes: slow pipelines, which teach developers to batch commits and skip checks, the exact behavior CI exists to prevent (parallelize and cache dependencies ruthlessly), flaky tests left to fail sometimes, which trains the team to ignore red, the fatal step, tests that assert on implementation details and break on every refactor, drowning signal in noise, and green-but-meaningless suites with no coverage of the money paths: payment, auth and data deletion must be tested before anything else is. The ci-adjacent tooling in the devops blocks on IndieBoot, from GitHub Actions to the test frameworks, assembles in an afternoon.