Short answer: Every Friday before noon we send a progress report with the same five fields, plus staging links and a 3-minute video, so clients learn progress, risks and "decisions we need from you" in 10 minutes. Since adopting it, delay risks surface about 2 weeks earlier on average, and weekly meetings have shrunk from an hour to under 30 minutes.
The problem: without a fixed progress report, delays usually surface a week before launch
On projects without written progress, bad news gets postponed until it can't be postponed anymore. We once took over a booking system whose previous team only said "on track" in LINE each week, until six days before launch they admitted the payment gateway application hadn't been submitted. Launch slipped five weeks. The client had already bought ad slots, and the loss far exceeded the development fee.
Our approach: a five-field report every Friday, with data pulled automatically from GitHub
In one sentence: the system drafts the report, the project lead adds judgment, and it reaches the client at a fixed time. The flow:
Thursday 17:00 freeze the week's progress → GitHub Actions pulls closed issues and milestone completion → the project lead writes "risks" and "decisions we need from you" → record a 3-minute Loom demo of new features → send by email plus a LINE summary before Friday 12:00 → client replies with decisions → decisions enter Monday's work queue
The report always has five fields:
| Field | Content | What the client can do with it |
|---|---|---|
| 1. Done this week | Each item links to the staging site | Try it the same week and give early feedback |
| 2. Next week | 3–6 items mapped to milestones | Line up internal staff for testing |
| 3. Status light | Green/yellow/red + completion and hours used | Decide at a glance whether to step in |
| 4. Risks | Each states "could delay by X days" | Prepare alternatives early |
| 5. Decisions we need from you | Each with a deadline and "impact of a late reply" | See exactly where you're the bottleneck |
Why we do it: written reports replace meetings, deadlines replace "let's discuss later"
We chose "written report + short meeting" because it fixes both information gaps and blurred accountability. Three trade-offs shaped the design:
- Async first: owners rarely free up an hour a week for meetings, but 10 minutes of reading is doable; weekly calls cover only yellow lights and decisions.
- Bad news first: the light rules are fixed. A milestone forecast to slip 3+ business days turns yellow, 5+ turns red, and red triggers a phone call the same day instead of waiting for Friday.
- Decisions have deadlines: every decision item says something like "if we don't hear back by 10/28, launch moves 2 days." Causes of delay become visible and don't turn into disputes later.
How it runs: tools, schedule and report template
Three tools tie the process together, and the project lead spends about 45–60 minutes a week.
- Step 1 | GitHub Projects for work items: each feature is an issue under a milestone, labeled
feature,bugorchange-request. See the GitHub Projects documentation. - Step 2 | GitHub Actions on Thursday: a scheduled GitHub Actions workflow pulls the week's closed issues, milestone completion and open change requests into a Markdown draft.
- Step 3 | A 3-minute Loom: demo only the one or two most important screens of the week.
- Step 4 | Send and archive: the full version goes by email, a three-line summary by LINE, and the report is saved to the project's
docs/weekly/folder.
Schedule and template excerpt:
# .github/workflows/weekly-report.yml (excerpt)
on:
schedule:
- cron: "0 9 * * 4" # Thursdays 17:00 Taiwan time
# docs/weekly/2026-W43.md (template)
## Status: [YELLOW] | 62% complete (plan 70%) | 58% of hours used
## Done this week
- Member login (staging link)
## Next week
## Risks
- Payment gateway review pending, may delay 3 days
## Decisions we need from you
- Refund rule A or B | due 10/28 | late reply: launch moves 2 daysThe cost: an hour a week, and the pressure of putting it in writing
This isn't free; here are three honest costs.
- Time: 45–60 minutes per project per week, about 12 hours over a 14-week project, included in our quotes.
- Nowhere to hide bad news: a red light in the report is an official record, so the team has to get used to admitting problems first.
- Clients must invest too: 10 minutes of reading and replies to decision items each week; delays from unanswered items are recorded.
When it doesn't fit: too short, too urgent or too big
Weekly reports suit projects of 4+ weeks with a steady rhythm.
- 1–2 week jobs: use one plan at kickoff and one report at close.
- Firefighting around launch: switch to a daily 15-minute stand-up and resolve issues the same day.
- Large multi-vendor programs: they need a dedicated PM and an integrated schedule; one weekly report isn't enough.
Why clients should care: every payment maps to visible progress
A fixed weekly report shows what your money bought before you pay, and lets you handle delays early.
- Quality: you can try the staging site every week, so issues surface in week 3 rather than at acceptance.
- Schedule: risks appear about 2 weeks earlier, giving you time to move ad slots or find alternatives.
- Cost: "completion vs hours used" sits next to the light, so budget top-ups don't appear out of nowhere.
If you want to do this too: four suggestions for other teams
- A fixed time matters more than the format: send at the same time every week so clients build a reading habit.
- Fix the light rules in advance: use days, not feelings, to decide yellow and red.
- Every completed item must be clickable: "done" without a staging link isn't done.
- Every decision needs a deadline and an impact: it's the most valuable field in the report.
Where we've used it: two anonymized cases
- A cram-school chain booking system (14 weeks): the week-6 report flagged yellow, "payment gateway review takes 10 business days." The client submitted documents the same day, and the system launched on time before enrollment season.
- A manufacturer's ERP integration (10 weeks): a "part-number rules" decision went unanswered for two weeks; the report spelled out the resulting delay, the client assigned an internal owner, and the next six weeks had no slips.
Frequently Asked Questions
How often should an outsourced project report progress?
Weekly written reports for projects of 4+ weeks. Around launch, switch to a daily 15-minute stand-up.
What should a progress report include?
At least five fields: done this week, next week, status light, risks, and decisions needed. Completed items should link to staging.
When does a project turn red?
When any milestone is forecast to slip 5+ business days. Three or more days is yellow, and red triggers a same-day phone call.
Does writing weekly reports cost extra?
It takes about 45–60 minutes a week and is included in ScriptWalker's quotes at no extra charge.
Next step: get the full template, or join us
ScriptWalker (a Taiwan-based Laravel/Flutter custom development studio) includes a fixed weekly report on every project; websites start at NT$15,000 and custom systems at NT$80,000. Whether you want the report template, want to work with us this way, or are an engineer who likes a "risks first" culture, get in touch:
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p