Page three

What I'd actually do.

Fifteen to twenty hours a week is not enough time to be vague with. Here's how I'd spend the first of them, what the standing work looks like after that, and how I work — including the AI tooling I've been building, since your posting raises it directly.

Weeks one and two

Earn the keys slowly

A part-time contractor's first job is to stop being a cost. Roughly 30 hours to go from nothing to closing tickets without supervision.

Read the money path first
Memberships, firing fees, supplies, class payments, private event balances. Every route, job, webhook and model those touch. If I only understand one subsystem in week one, it's this one, because it's the one where a bug costs a studio real money and costs you a phone call.
Ship three small fixes
Pick the smallest real tickets in your backlog, not warm-up tasks. Three merged PRs tells us both more about whether this works than two weeks of onboarding.
Write down what surprised me
Every new engineer sees the seams for about three weeks and then stops noticing them. I'll keep that list and hand it over, whether or not I ever get to act on it.
Learn Stripe on your codebase
Named honestly on page one: I've built subscription billing, not against Stripe specifically. The fastest way through that is your existing integration and the API docs, not a side project.

After that

The standing work

Your posting lists seven responsibilities. This is how I'd hold each one.

Reliability and performance
Find the slow and the flaky before a customer does. Query plans, N+1s, queue backlogs, jobs that fail quietly. My Psicología y Mente year was mostly this, on a system carrying 200,000 users.
Customer-reported bugs
Reproduce first, always. A bug I can't reproduce is a bug I haven't understood, and a fix on an un-reproduced bug is a guess with a commit message. Then a regression test named after the report.
Internal staff tools
The tools your team uses to fix things for studios. These get built badly everywhere because nobody's watching. I'd rather they were the calmest screens in the product — see page two for what I mean by calm.
Features on your stack
Laravel and Vue Options API, in your conventions, not mine. I match the codebase I'm in. A contractor who forks a competing pattern is a maintenance bill, not a hire.
Stripe integration
Webhook idempotency, retry and dunning behaviour, reconciliation between your records and theirs. The failure modes matter more than the happy path, and they're where billing bugs actually live.
Code review and planning
I review for correctness first, then for whether the next person will understand it. I'll say when I think something's wrong, and I'll drop it when you've decided.
Simplification
The line in your posting I liked most. Every ticket is a chance to leave that file smaller. Not a rewrite — a rewrite from a part-time contractor is a bad trade for you.

How I work

On the AI question

Your posting asks for someone who understands the fundamentals rather than someone leaning on generated code. Agreed — and I'll go further, because AI tooling is what I've spent the last stretch building, which is exactly why I don't trust it unsupervised.

Two things I'm building right now, both aimed at the same problem: giving a model enough access to be useful and not one inch more.

pluk · github.com/yondifon/pluk

Production access without handing over the keys

A macOS menu bar app that turns the services you already run — Postgres, MySQL, SQLite, Linear, Sentry, servers — into local MCP endpoints an AI client can use. The server runs on localhost, credentials never leave the machine, and every integration carries its own policy, so an agent debugging a production issue can read what it needs and nothing else.

The part that matters for a job like this one: every query is logged. When a model touches production, there's a line saying which integration, which statement, and whether it succeeded. That's the difference between using AI on a live system and gambling on one.

pluk showing grouped integrations for a project and a log of every SQL statement run through them, each marked ok or error.
pluk. Integrations grouped per project, each labelled local or production, and a full log of every statement that went through them.

Inter · inter.desgn.space

Delegation with a diff at the end of it

Inter hands a bounded piece of work to a background agent in its own git worktree, with an explicit scope, and gives it back as a branch, a diff and a run cost. Nothing is merged by the tool. Every task ends with me reading the changed files.

It's a fast way to do the boring half of a ticket. It is not a way to skip understanding the code, and the workflow is built so that skipping isn't available: the output is a diff I have to review, the same as any other engineer's.

Inter showing a delegated task with its activity log, the tests it ran, and the ten changed files with line counts.
Inter. One delegated task, everything it ran, the reviewer's verdict, and the ten files it changed — which is where I start reading.

The working rule

AI writes the draft; I own the diff. Nothing reaches your review that I can't explain line by line, and nothing reaches production that I haven't read. If you'd rather I didn't use any of it on your codebase, say so and I won't — it's your repository.