What to Include in a Developer Status Report

Your commit message said "fix stuff" and now you need to explain to a client what "stuff" was. We've all been there.

A good status report answers three questions: What did you ship? What's next? Is anything blocking you? That's it. Everything else is optional. But most developers either dump in every commit from the last week or fire off a two-line "things are going well" and call it a day. Neither gives your client what they actually need: confidence that the project is moving and their money is well spent.

Lead with the Summary

Two to three sentences at the top. That's the whole summary. It's also the only part most clients will read, so make it count. Answer two questions: Are we on track? What's the biggest thing that happened?

Compare these two openings. "This week we shipped the password reset flow and started on the admin dashboard. We're on track for the March 15 milestone." versus "Various tasks were completed this sprint across multiple workstreams." The first one tells a client something useful. The second could be auto-generated by a bot, and it sounds like it.

Completed Work

This is where most developers trip up. You spent three days extracting a service class and optimizing Eloquent queries, and you want credit for it. Fair. But your client doesn't care about your query scopes. They care about what changed for their users.

Write each item from the client's perspective, not yours.

Good examples:

• Customers can now reset their password through a "Forgot password?" email link
• The product listing page loads 3x faster (down from 4s to under 1s)
• Invoices can now be exported as PDF directly from the dashboard
• Fixed a bug where some users saw stale pricing after a plan change

Bad examples:

• Merged PR #247 into main
• Refactored PaymentService to use Stripe's latest SDK
• Updated Vite config and added code splitting
• Fixed flaky test in the CI pipeline

The bad examples make perfect sense in a standup with your team. In a client report, they're noise. If you're not sure where the line is, writing reports that clients actually read goes deeper on translating dev work into plain English.

Work in Progress

Don't just say "working on the checkout flow." That could mean you opened the file today or you're one PR away from done. Be specific: "The checkout flow is about 60% done. Stripe payment processing works, and I'm building the order confirmation screen now. Should be wrapped up by Wednesday."

This kind of detail does two things. It shows the client that real progress is happening, and it gives them a concrete date to anchor on. It also protects you: if something slips, you've already documented what the plan was, which makes the delay conversation much easier.

Blockers and Decisions Needed

This is the section most developers skip. It's also the most important one.

Blockers are anything stopping you from making progress. Decisions needed are questions only the client can answer. The whole point of listing them is to get the client to do something, so make that action crystal clear.

Real examples:

• Waiting on Stripe API keys from the client's finance team
• Need sign-off on the Figma mockup before I build the settings page
• Still don't have SSH access to the staging server

Don't just list them, though. Say what you need and by when. "I need the Stripe API keys to continue the checkout integration. Could you send those by Thursday so we stay on schedule?" That's actionable. "Waiting on API access" is just a status. It doesn't tell the client what to do or when.

What's Coming Next

Two or three bullet points previewing next week's focus. That's all you need here. It shows there's a plan, and it sets expectations for what the next report will cover.

It also creates a lightweight accountability loop. You said you'd work on the notification system next week, and now your client will expect to hear about it. If priorities shift, your next report is the natural place to explain what changed and why.

What to Leave Out

Not everything you did this week belongs in the report. Here's what usually doesn't:

• Internal tech work. Refactoring controllers, updating npm packages, tweaking your CI config. If the client can't see or feel the change, skip it
• Hour-by-hour breakdowns. Unless the client specifically asked for time tracking, listing "2.5 hrs on migrations" adds noise, not value
• Excuses. If something took longer than expected, state the fact and the new timeline. Don't write three paragraphs about why
• Invisible bug fixes. You fixed a race condition in the queue worker. Great. The client never knew it was broken, so they don't need a line item about it

The filter is simple: would the client care? If not, leave it out. That's good communication in a nutshell: useful over comprehensive, every time.

Putting It All Together

A report with this structure takes five to ten minutes to write. Less if you keep quick notes during the week (even just bullet points in Notion or a pinned Slack message to yourself). The format works whether you're sending weekly, biweekly, or on whatever cadence your client prefers.

If it still feels like a chore, Rundown can generate the first draft from your Github commits, translated into plain-English summaries. You review, tweak, and send. Five minutes, tops.

The real payoff is cumulative. When your client gets a clear, predictable update every week, trust builds quietly in the background. They stop wondering what's happening. They stop scheduling "quick sync" calls. And your projects run smoother because of it.