Most of what slows a project down isn’t the work itself. It’s the stuff around the work. The back-and-forth emails. The stall while someone tracks down a login. The decision that sits in an inbox for a week. The context being rebuilt every time the project moves between people.
That’s the problem day-rate work is built to solve.
The simplest way to describe how I work is this. Day-rate work for defined scope. Solution engagements for scoped problems. This post is about the first half.
Day-rate work is what it sounds like. You book a day, or a few days, and I do the work. No project plan, no discovery phase, no layers between you and the person doing the work. Just a calendar block and a defined thing to deliver by the end of it.
My lane is web development and visual strategy. Websites, Design Guidelines, template systems, hosting, the visual systems teams use day to day. Positioning, structure, and voice come into it when the build needs them — you can’t put together Design Guidelines without some voice work, you can’t build a homepage without making structural decisions, but the headline is dev and design.
How long is a day-rate engagement?
However long the work actually takes. One day, three days, five days. The point isn’t the number. The point is that the scope is clear enough that we can put it on the calendar instead of writing a project plan.
Some work fits inside a single day. Some needs a few consecutive days because it’s foundational and the pieces build on each other. Compressing it cuts corners. Stretching it loses momentum. A few consecutive days is usually the right shape.
The unit is the day. The number depends on the work.
What this has looked like recently
A paid survey for a client, built in Gravity Forms, the kind where respondents pay to access the results. Three days, end to end.
A Design Guidelines document for a team that already had most of it figured out. One day, because the work was translating what they had into a proper working reference rather than building it from scratch.
A long-running client who needed additions to their site plus a bit of strategy around what to do next. Day-rate, as needed.
A LearnDash client who needed help adding a course. One day.
These look different on the surface, but the shape underneath is the same. The scope is clear before we start. The work is something I can sit down and do. The number of days follows from what’s actually involved.
The stuff around the work
By the time we sit down, the prep is done. You’ve filled out a workbook. We’ve had a planning call. The materials and access are in. So when the day starts, we start.
I turn everything else off and focus on your work. We kick off together so I can ask questions, walk through documents, and confirm priorities. Then I go off and build, with you available to answer the questions that come up. If we need to shift direction mid-day, we shift, because we’re doing it together, in real time, not over a thread that takes three days to resolve.
That’s what makes the time frame enough. A day is short enough to force decisions. A few days is short enough to keep momentum. Neither is long enough for things to drift. The constraint is part of the value.
When it fits, and when it doesn’t
Day-rate work fits when you can describe the deliverable. A website. A guidelines doc. A course added to LearnDash. A survey wired up to payment. Something concrete enough that we can both picture what done looks like.
It doesn’t fit when the conversation starts with “we’re not sure what we need yet.” That’s a scoped solution engagement, and it starts with the problem, not the deliverable.
When the scope is clear, day-rate is the right shape. The only question is how many days.