One of the things I've learned from doing this work for a while: the clients who have the best experience are the ones who know what to expect before the project starts. Not because they're more accommodating — because they're prepared. They come to calls ready. They prioritize the right things. They don't spend the first three weeks figuring out how we're going to work together.

So here's exactly what the first two weeks of a new engagement at Pixelworx look like.

Before anything starts: the brief

Every project begins with a written brief. If you come to me without one, we'll build it together in the first conversation — but it exists before development scope is written or a contract is signed.

A good brief answers: what does your business do, who does it serve, what are you trying to accomplish with this project, and what does success look like? If you haven't worked through these yet, the process of writing a brief is valuable in itself — it forces clarity before we spend anything.

Week one: discovery and kickoff

Day 1–3: Discovery call. Usually 60–90 minutes. We go deep on business context, goals, technical constraints, timeline, and anything else that would affect how we approach the project. I ask a lot of questions. Good ones will be uncomfortable — they're supposed to be.

Day 3–5: Brief review and scope draft. I take the discovery conversation and turn it into a written scope of work: specific deliverables, explicit exclusions, milestones with dates, payment schedule. You review it, we revise it until it's accurate, and then we both sign it.

No work starts before this step. Not because I don't trust you — because ambiguity at the start costs both of us later.

End of week one: kickoff document. A one-page reference document that covers: the goal of the project in one sentence, the primary audience, the top three priorities for the build, the communication channel we're using (typically a shared Slack channel), the feedback cadence, and the first milestone.

This document lives in our shared folder and gets referenced throughout the project when decisions need to be made.

Week two: content gathering and first milestone

Days 6–8: Content request sent. I give you a specific list of what I need from you before design can begin: existing brand assets, copy for core pages, photos, competitor references, any must-haves or strong preferences on look and feel. The more of this you can provide before design starts, the faster the project moves.

Waiting for content is the most common reason web projects extend past their estimated timeline. Getting ahead of it in week one is the single biggest thing clients can do to keep a project on schedule.

Days 9–12: First milestone delivered. Depending on project type, this is either: initial wireframes (for complex applications), a mood board and design direction (for marketing sites), or a technical architecture draft (for backend-heavy work). This is our first real alignment check — does this direction match what you imagined?

End of week two: feedback window. You have three business days to review the first milestone and send consolidated feedback. "Consolidated" matters — one round of feedback per milestone, from all stakeholders who need to weigh in, not a rolling stream of updates over the following two weeks.

Why this works

None of this is complicated. It's just explicit. The feedback cadence, the content deadline, the scope document, the kickoff doc — these exist because the things that go wrong in web projects are almost always predictable, and most of them can be managed with a little structure upfront.

The goal of the first two weeks is to eliminate uncertainty about how the project runs before the real work begins. When that's done well, everything that follows is faster and less stressful for both sides.

If you have a project in mind and want to understand what working together would look like before committing to anything, get in touch. That first conversation is the beginning of this process.