That’s the problem day-rate work is built to solve.
The simplest way to describe how I work: 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. You don’t wade in. You jump.
My lane is web development and visual strategy: online experiences, 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 to put 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 online experience 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 I 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 the day starts, the prep is done. You’ve filled out a workbook. There’s been a planning call. The materials and access are in. So when the day starts, I’m already in the water.
I turn everything else off and focus on your work. The day opens with a check-in 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 the direction needs to shift mid-day, I raise it with you directly, 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: an online experience, a Design Guidelines document, a course added to LearnDash, a survey wired up to payment. Something concrete enough that what done looks like is obvious going in.
It doesn’t fit when the conversation starts with “I’m 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.
