/toolsPurpose-built tools

The tools I use
to run my projects.

I don't use these tools because they're trendy: I built them because I needed them. Monitoring, finance, client tracking, security, and deploys - all running on this very site. Each case study tells the real problem that started it and how I solved it. The same discipline I apply here is what every client gets.

Monitoring, SLOs, and error budgets

SRE-style observability, built from scratch

The problem

Running client sites without knowing they're down until someone complains. Generic uptime services don't catch a broken deploy that responds 200 with the wrong page.

The solution

A custom check engine: every probe validates the HTTP status, expected response content, and a latency threshold. Failures group into incidents (from first failure to first success), and SLOs and error budgets are computed over that history, Google SRE-style.

Recreation of the panel with illustrative data - real data is never published.

In production

Per-service SLO with burn rate: not just "how much it went down," but how fast the error budget is being spent.
Instant push alerts to my phone via ntfy when a service goes down or degrades.
Monitoring for TLS certificate and domain expiration.
The data feeds the public status page: what you see there is exactly what I see.

Astro API routesDrizzle ORMTursoexternal cronntfyView the live public status →

Per-project costs and P&L

Knowing what it costs to run each thing, down to the cent

The problem

Hosting, domains, database, email: every project piles up services billed differently. Without a record, it's impossible to know if a project is profitable or what it costs to maintain per year.

The solution

A registry of services per project (and account-wide) with cost and billing cycle, cross-referenced against revenue that is collected, pending, and projected. The result is a per-project P&L: real margin, not a guess.

Recreation of the panel with illustrative data - real data is never published.

In production

Normalizes billing cycles (monthly, annual) into a comparable cost.
Revenue in three states - collected, pending, projected - to separate real cash from expectation.
The P&L and money-handling logic has its own battery of unit tests.

Drizzle ORMTursoVitestView the P&L in the panel demo →

Client tracking portal

Transparency as a practice, not a promise

The problem

A client who doesn't know where their project stands asks over WhatsApp, and the answer gets lost. Trust erodes in the silence between updates.

The solution

Every project has a tracking view where the client sees progress without asking: milestones, interactions, and briefs. Public project pages show only what's marked visible; the rest stays in the panel.

Recreation of the panel with illustrative data - real data is never published.

In production

Per-client interaction log: what was discussed, what was agreed, when.
Structured briefs that document requirements before any code is written.
Fine-grained visibility control: each piece of data decides whether it is public, client-facing, or internal.

Astro SSRDrizzle ORMauth with allowlist

Encrypted credentials vault

Project secrets, never in plain text

The problem

Each project's credentials (API keys, environment variables) tend to end up in notes, chats, or loose files - the worst possible place.

The solution

A vault inside the panel that encrypts every value with AES-256-GCM before it touches the database. The encryption key lives outside the database, in the server environment: a database dump exposes no secrets.

Recreation of the panel with illustrative data - real data is never published.

In production

Authenticated encryption (GCM): a tampered value doesn't silently decrypt, it fails.
Panel backups that preserve encryption: secrets travel encrypted in the backup too.
The /admin route requires a session with an allowlist revalidated on every request, at every layer.

AES-256-GCMnode:cryptoAstro middleware

CI/CD with health check and rollback

Deploying without fear because the pipeline watches

The problem

A deploy that passes tests can still break production. If nobody's watching in the following minutes, the site stays down until someone notices.

The solution

The GitHub Actions pipeline deploys, checks the live site's health, and if the health check fails, automatically rolls back to the previous deploy. Every run reports its result to the panel, which keeps the history: success, failure, or rollback.

Recreation of the panel with illustrative data - real data is never published.

In production

Post-deploy health check against the real site, not a mock.
Automatic rollback with no human intervention when the check fails.
Run history in the panel with a direct link to the logs of each execution.

GitHub ActionsVercelVitestView the live lab →

Controlled chaos engineering

Breaking the site on purpose to trust the alerts

The problem

How do you know your monitoring catches an outage if you've never seen one? Trusting alerts that have never fired is faith, not engineering.

The solution

A fault-injection module toggleable from the panel: extra latency, 500 errors, or a dead service, per route. It exists to verify end-to-end that monitors detect it, the incident gets logged, and the alert reaches my phone.

Recreation of the panel with illustrative data - real data is never published.

In production

Fail-open by design: if the chaos engine fails, the request passes through clean. Chaos can never become a real incident.
Mandatory TTL on every flag: no injected fault survives more than 15 minutes, not even by forgetting about it.
The panel and authentication are excluded by code: there is always a reachable panic button.

Astro middlewareTurso flags with TTLView the live experiments →

Security observability (custom micro-SIEM)

Knowing who is trying to get in, not just waiting until they do

The problem

Any site with a public IP gets automated probing from minute one: scans for other CMSs, config files, injections on every parameter. The normal reaction is to ignore the noise - but those 404s are the real attack surface, and dismissing them throws away a free signal.

The solution

A custom engine that runs in the middleware on every request: an OWASP Top 10-aligned classifier detects attack signatures, a two-layer durable rate limiter and a blocklist choke abuse, decoy endpoints confirm malicious intent, and an hourly cron aggregates events, statistically detects anomalies, and applies escalating automatic blocks.

Recreation of the panel with illustrative data - real data is never published.

In production

Fail-open at every layer: if the security sensor fails, the request passes through clean - it can never take down the site it protects.
Z-score anomaly detection over a 30-day baseline, not a black box: every alert can be explained in a sentence.
Blocks with mandatory TTL and escalation by recurrence (1h → 24h → 7d), never permanent by default.
The public showcase shows real aggregates with deliberate OPSEC: never full IPs, never rule names, never which routes are decoys.

Astro middlewareDrizzle ORMTursoexternal croncustom statisticsView Security Operations live →

Client portal

This is the panel I hand to every client

Project status with real uptime, invoices paid online, direct messaging, and documents. No signup required: it uses data from a fictional client, and you can test the payment with the simulated gateway.

Try the demo portal

The tool I use with you is the one I use with myself.

If we work together, your project joins this same system: SLO-based monitoring, visible tracking, encrypted credentials, and deploys with a safety net.

Let's talk about your project