The rules I work under

Six rules

1. Confidential by default. NDA is standard. I never show your project, name or screenshots without written consent, which is why this site names no clients without permission.
2. Your code, your accounts. Code and data stay in your repository and accounts. AI tools run with training on your data turned off, and secrets never reach a model.
3. A handover you can use. Every project ends with the same checklist: a README that gets it running, one architecture diagram, written decisions, CI, a runbook and a recorded walkthrough. It is done when someone outside the project can run it from the docs.
4. Boring technology where it counts. I pick a stack you can hire for. Anything experimental needs your yes and an exit plan.
5. Approach matched to your risk appetite. Prototype, product or regulated: the level decides how much autonomy the agents get and how much review and validation each change needs.
6. Everything checkable. Every number on my pages links to its source. My tools are free, and the idea validator skill is open source (MIT).

Three risk levels

You pick the level on the call. It decides how much autonomy the agents get and how much review, validation and paperwork each change needs. Product is the default.

AI: three modes, you choose

• No AI

  Code written by hand, no model sees your repository. Slower and more expensive in hours, and sometimes the right call. I say so if I think it is not.

• AI-assisted (default)

  Claude Code and Codex work under project rules: hooks, lint and test gates, a human review on every pull request. In 2026 an agent opened about 30% of my merged pull requests and I reviewed about 85% of them.

• AI engineering

  We build agentic systems together: tools, MCP servers, evaluation loops, cost caps. The AI and agents page shows one running on this site.

Defaults in every mode that touches a model: training on your data turned off, zero-data-retention where the provider offers it, your accounts or my business accounts, and a list of models you approve. Before I start I send you a screenshot of the opt-out settings. AI-assisted work is labeled as such, to your team and to users where it matters.

What never reaches a model

Secrets, your customers’ personal data, production logs and any code you mark as off-limits stay out of every model until you approve it in writing, after the confidentiality and data-processing checks you need. I start from redacted documentation and synthetic data, and most work never needs more.

Code and data are separate. My development machine has no access to your production data. Diagnostics are anonymized or masked before they reach PostHog or any other analytics service. Customer data is treated as personal data by default.

Hours and response times

• Where and when. Wrocław, Poland. Office hours 9 to 5 CET (UTC+1, UTC+2 in summer), and I usually answer messages through the day. Three shared hours with the US East Coast, a full day with the UK and the EU.
• A reply within 24 hours means a full reply. On working days you get an answer with substance, and when it is a project issue, often a pull request or a fix. I do not send “received, will look” messages.
• Weekends. Messages from the weekend get an answer by Monday noon. Weekend work happens only by agreement, at twice the rate. I value work, and I value my family more.
• When I am booked. I never book more than eight hours of regular work a day. For clients I already work with I keep room for an urgent fix even when the calendar is full, mostly in the evenings.
• Async first. I prefer a quick written answer on Slack or email to a video call. Calls when they save time.

No SLA, no pager

I do not sell 24/7 on-call cover and I will not pretend otherwise. I have brought production up many times, and I have never been the person paged at 2 AM. That is the point: I build systems that do not need it. A deploy at 5 PM on a Friday should be boring.

If you need a formal on-call rota with guaranteed response times, I am not the right person and I say so on the call. The free SLA calculator helps you work out what you actually need.

One person, no subcontractors

The work is done by me. No substitution, no helpers, no agency behind the curtain. If you ever want a second pair of hands, we agree on it first and you meet them.

One person is also a risk, and I do not hide it. I get sick, my children need me, things happen. What I promise: early notice whenever I can see it coming, and a setup where my absence costs you little. Your code lives in your repository from day one, decisions are written down, and every project ends with a handover someone outside it can run from.

Confidentiality and agreements

• NDA

  Standard. I sign yours or provide a reasonable mutual one. No client is named anywhere without written consent.

• Data processing agreement

  When I touch personal data, we sign a DPA (under GDPR, an Article 28 agreement) before any access.

• Access

  Only through accounts you control, with the least privilege that does the job, revocable in one click. No production access from development machines. Nothing done by hand on production that could be code.

• Offboarding

  At the end I hand back access, delete local copies and confirm it in writing. The security page has the details.

Migrations and recovery

Rolling a database back is the last resort, never a routine. Point-in-time recovery is great when it exists (D1 and Postgres both have it), but any external side effect, an email sent, a subscription changed, a reminder clicked, survives the rollback and makes the world inconsistent. So I design forward: each service owns its data, every outbound action has an idempotency key, and billing or email providers stay the source of truth for what they did.

When a disaster recovery really happens: stop the world, restore, run consistency checks, reconcile the providers’ event history, and only then reopen processing. Every migration is rehearsed on a clone first, then repeated on production with the same steps. The Cloudflare page has the D1 specifics.

The handover checklist

• A README that gets the project running on a clean machine.
• One architecture diagram and the decisions written down with their reasons.
• CI with the gates that protected the work: lint, tests, security checks.
• A runbook: how to deploy, roll back, rotate a secret, read the dashboards.
• A recorded walkthrough, so the next person hears it from me.
• Done means someone outside the project can run it from the docs.