How an engagement actually runs, week to week. None of this is unusual — but it's worth writing down, because most of what goes wrong in consulting arrangements goes wrong here rather than in the code.
Before anything starts
Scope, in writing. Every engagement begins with a written description of what's being built, what isn't, and what "done" means for each piece. For anything substantial that's the output of a paid discovery block; for smaller work it might be a page of email. Either way it exists before I start, and neither of us is relying on memory of a conversation.
Deliverables, named individually. Not "the platform" but the specific things you'll be able to see, run, and evaluate — a working ingestion path, an API your frontend can call, a deployed environment, a written architecture document. Named separately so progress is visible rather than a single bar that sits at 80% for a month.
What's explicitly out. The list of things I'm not doing matters as much as the list I am. Most scope disputes are really disagreements about an assumption nobody wrote down.
Assumptions and dependencies. What I'm expecting from your side — access, environments, decisions, someone available to answer questions — and what happens to the timeline if those arrive late.
Week to week
A written update every week. What shipped, what's in progress, what's blocked and on whom, and hours used against the estimate. It goes out on the same day each week whether or not the news is good. If the project is behind, the weekly update is where you find out — not the invoice.
A standing weekly call. Usually thirty to sixty minutes to review progress, resolve decisions, and reprioritize. Short or cancelled when there's nothing to discuss; I'd rather give you the time back than hold a meeting for its own sake.
Daily standup if your team runs one. If you have a daily and it's useful for me to be in it, I'll be in it. If your team doesn't work that way, we won't invent one.
Async by default otherwise. Slack, email, or wherever your team already talks. I don't need a meeting to unblock a question, and I'd rather answer in writing where the answer stays findable.
Tracking the work
Your tools, at whatever depth you want. If you already run Jira, Linear, GitHub Issues, or YouTrack, I work in it. If you don't have anything, I'll bring GitHub Issues and give you access.
How granular that gets is your call, and clients genuinely differ. Some want every task ticketed, estimated, and moved across a board so they can watch it in real time. Others want none of that and are happy with the weekly update. Both are fine. What I won't do is track the work somewhere you can't see it.
Time tracked in Harvest. Meticulously, against the project and its parts. You get an itemized account of where the hours went — what was worked on, for how long, and against which deliverable. On an hourly arrangement that's the difference between an invoice you can check and one you have to take on faith.
Billing
Monthly, net 30. Invoiced at month end with the Harvest breakdown attached, so the hours are reviewable line by line rather than arriving as a single total.
No surprises in the invoice. If a project is trending over its estimate, you hear that in a weekly update while there's still time to cut scope, extend the timeline, or accept the overage deliberately. An invoice is a bad place to learn something you could have known three weeks earlier.
Fixed-price work bills against milestones rather than hours, on the schedule we agree when the scope is set.
How it ends
A documented handover. Every engagement closes with the material your team needs to own what was built: architecture documentation, runbooks, environment and deployment notes, and the reasoning behind the decisions that aren't obvious from reading the code.
A walkthrough with your engineers. Documentation alone rarely transfers a system. We sit down together, go through it, and I answer questions until your team is genuinely comfortable — not until the document is delivered.
Everything in your accounts, already. Code, infrastructure, and credentials live in your repositories and your accounts from day one, not migrated at the end. There's no moment where I hand over the keys, because I never held them exclusively.
The goal I'm working toward is that you don't need me afterward. If you want ongoing support, a retainer is available — but it should be a choice you make because it's useful, not because the system is unmaintainable without its author.
Questions
If your organization has a process this needs to fit inside — procurement, security review, a particular methodology — tell me and we'll work out how it maps.