When I make a change to a website, I do not push it straight live. First it goes through a continuous integration pipeline on GitHub Actions that reviews it automatically. If anything fails, the change is not published.
Security first
The first check is that no key or password has slipped into the code (gitleaks) and that the new code does not introduce insecure patterns (static analysis with Semgrep). On top of that, dependencies are scanned every week for known vulnerabilities.
Trusted dependencies
External libraries are always installed at the exact recorded version, and third-party actions are pinned to a specific version. That way, a malicious or broken package update does not slip into your website on its own.
Clean, typed code
Linting, formatting and TypeScript type checking on the frontend and backend, plus dead code detection. These are cheap mistakes to fix when they are caught early.
Tests at several levels
Unit tests for the frontend and backend, API tests against a real database and end-to-end tests with Playwright that walk through the website the way a user would. The end-to-end tests are split across several machines in parallel so the wait stays short. Coverage is measured too, and the pipeline fails if it drops below the set minimum.
Only what was tested gets published
The deployment checks that the code about to be published is exactly the code that passed the pipeline. The frontend is deployed on Vercel and the backend on Fly.io.
What the client gets
Fewer surprises. Bugs are found by a machine before they reach your website, not by your visitors afterwards.
