How to hire engineers by the week

Booking an engineer for a week sounds like a small transaction, and mechanically it is: pick a specialty, pick the days, pay for the days. What trips teams up is everything around the transaction. A badly scoped week produces a polite report and no shipped work. A well scoped one is the cheapest way we know to find out what a team can do for you.

We’ve watched both kinds happen from the provider side, so this is a field guide: what it costs, how to scope it, what to have ready on Monday morning, and the failure modes we see most.

What a week costs

Pricing is day rate × days. Ours are published from-rates per specialty, with actual proposals usually at or under them, but the shape is what matters, so here are three common configurations at list price:

The week	Who’s on it	Cost
Fix-and-ship week	1 full-stack ($350/day × 5)	$1,750
Feature week	1 full-stack + 1 UX designer ($350 + $250) × 5	$3,000
Launch-prep week	Full-stack + DevOps + QA ($350 + $450 + $250) × 5	$5,250

For calibration, a fully loaded senior hire runs roughly $4,400 a week whether or not there’s work that week (math in the true cost of hiring), and agencies mostly won’t return email for a one-week engagement.

The full rate list covers eleven specialties, from graphic design at $150/day to ML at $500/day. Mix per the work, not per the org chart you imagine having someday.

Scoping: the part that decides everything

A week is 40 hours. The teams that get the most out of one treat that as a feature, because a hard boundary forces the question every project should start with: what’s the smallest complete thing worth shipping?

Good week-sized scopes we’ve seen work:

• Ship the Stripe integration, including the failure cases and a test plan
• Take the signup flow from figma-file to production behind a feature flag
• Stand up CI/CD and staging so deploys stop being a founder ritual
• An audit week: a senior engineer reads the codebase and delivers a written map of what’s fragile, what’s fine, and what to do first (founders skip this one and usually shouldn’t)

Bad week-sized scopes, all real:

• “Work on the app.” On what? Toward what? Booked days evaporate into orientation.
• “Rebuild the backend.” That’s a quarter, not a week. Slice it or don’t start it.
• “Pair with our CTO when he’s free.” He was free four hours that week.

The test: can you write the week’s outcome as a sentence with a verb and a deliverable? “By Friday, password reset works and is deployed.” If you can’t write the sentence, the week isn’t scoped yet, and the fix takes thirty minutes of thinking, not a meeting.

What to have ready before Monday

The difference between a week that starts producing Monday afternoon and one that starts Wednesday is almost always access and context, prepared or not:

1. Access, done the Friday before. Repo, staging environment, error tracker, whatever the work touches. Day-one access requests are the classic silent day-killer.
2. A written brief. One page. What the product does, what this week ships, where the bodies are buried (“auth is weird, ask before touching it”). Twenty minutes of founder time, saves a day of archaeology.
3. A decision-maker with a response time. Questions will come up. If answers take a day, a five-day week has three days in it. Name one person; agree they answer within a couple of hours during the week.
4. A definition of done you’d defend. Merged? Deployed? Tested against what? Write it in the brief so Friday isn’t a negotiation.

That list is also a decent test of any provider you’re evaluating: a good one will ask you for most of it unprompted. (Our onboarding for a first week is largely this list with checkboxes.)

What the week itself should look like

You set direction; the crew runs the work. A rhythm that works and doesn’t eat your calendar:

• Monday: 30 minutes. Walk the brief, confirm the Friday sentence, hand over context.
• Midweek: one async check-in. Written, short: what’s done, what’s next, what’s blocking. If a demo makes sense, it happens here.
• Friday: a demo of the shipped thing and a written summary: what shipped, decisions made, what we’d do next week if there is one. The written part matters more than the meeting; it’s the context that survives.

Total founder time: under two hours. If a provider needs more of your week than that to run a week, the coordination is the product and you’re the one supplying it.

After week one: the actual point

The first week answers a question a sales call can’t: what is this team like when it’s working? Code quality, communication, how they handle the unexpected. Everything after that is scheduling to match your roadmap: book the same crew for a sprint when there’s a push, a standing two days a week for maintenance, or nothing during a quiet month. Add a specialty for a week when the work calls for one, stand it down after. The elasticity math, and what it does to a seed budget, is worked through in burn rate math.

The one thing to insist on, with us or anyone: continuity. The value of week five is that the people already know your codebase from weeks one through four. A provider that can’t guarantee the same crew is reselling week one to you repeatedly.

The mistakes, ranked by frequency

1. No Friday sentence. Unscoped weeks produce updates instead of software.
2. Access on Monday. Half a day gone, every time.
3. The absent founder. Nobody available to answer “A or B?” so the crew guesses, and Friday’s demo is a coin flip you could have called.
4. Scope stuffing. Six weeks of work “since we’re paying anyway.” The week ships nothing complete instead of one thing whole.
5. Treating it as an interview with expenses. A week that produces working software is the best interview, but only if you scope it as work rather than as a puzzle audition.

Avoid those five and a booked week is a strangely low-risk instrument: a real deliverable, a live evaluation of the team, and a one-week exit if you didn’t like it. The planner prices yours before anyone asks for your email, which is how we’d want to be sold to, so it’s how we sell.