Documenting Development Projects
Create a project doc immediately when starting work — don't wait until the end. Use this skeleton:
Markdown# Project: [Name]
- Requestor / Stakeholder:
- Goal / Problem being solved:
- Tools/Platform: (SharePoint / PowerApps / Cursor / other)
- Start date:
- Approach:
- Key decisions & why:
- Assumptions/constraints:
- [Date] - What was built/changed - Why - Notes/blockers
- What was tested:
- How (manual/automated):
- Results/issues found & fixes:
- Environment:
- Steps taken to deploy:
- Rollback plan (if any):
- Where things live (repo, SharePoint site, PowerApps environment):
- Known issues / tech debt:
- Next steps / recommendations:
Fill in sections as you go, not retroactively.
Progress:
- Step 1: Capture project details as soon as they're known
- Step 2: Document the plan before coding starts
- Step 3: Log development progress incrementally (daily or per-milestone)
- Step 4: Record testing steps and outcomes
- Step 5: Document deployment steps
- Step 6: Write final handoff notes for the next developer
Step 1 — Project Details Record who requested it, what problem it solves, which platform/tools apply (SharePoint, PowerApps, Cursor, etc.), and the start date. Do this before any planning work.
Step 2 — Planning Write down the approach and reasoning for key decisions (e.g., why PowerApps over a custom app, why a certain SharePoint list structure). Note constraints or assumptions — this saves the next developer from re-deriving context.
Step 3 — Development Log Add an entry each time something meaningful happens: a feature built, a design change, a blocker hit and resolved. Keep entries short but specific (date, what, why). This is the section most often skipped — don't wait until the end to reconstruct it from memory.
Step 4 — Testing Document what was tested, how (manual click-through in PowerApps, code tests in Cursor, etc.), and what issues came up. Include steps to reproduce any bugs found and how they were fixed.
Step 5 — Deployment Capture exact deployment steps (e.g., publishing a PowerApp, promoting a SharePoint site, pushing code to production via Cursor/git). Include environment names/URLs and a rollback plan if something breaks.
Step 6 — Handoff Notes Summarize where everything lives (links to SharePoint sites, PowerApps environments, repos), known issues, and recommended next steps. Write this section assuming the next developer has zero prior context.
Example 1: Input: A PowerApps project to automate a leave-request form for HR, requested by HR manager, built and deployed over 2 weeks. Output:
Markdown# Project: HR Leave Request Automation
- Requestor: HR Manager (Jane)
- Goal: Replace manual email-based leave requests with a PowerApps form
- Tools: SharePoint (data list), PowerApps (form/app), Power Automate (approval flow)
- Start date: 2024-03-01
- Approach: SharePoint list as backend, PowerApps canvas app as front end, Power Automate for manager approval notifications
- Key decisions: Chose canvas app over model-driven for faster UI customization
- Constraints: Must work on mobile via PowerApps mobile app
- 2024-03-02 - Created SharePoint list "LeaveRequests" with columns for dates, type, status
- 2024-03-04 - Built PowerApps form UI, connected to SharePoint list
- 2024-03-06 - Added Power Automate flow to notify manager on submission
- 2024-03-08 - Fixed bug where date validation allowed past dates
- Manual testing of form submission, approval flow, and mobile view
- Found: notifications not triggering for multiple approvers — fixed by updating flow trigger condition
- Published PowerApps app to HR security group
- Verified SharePoint list permissions restricted to HR team
- Rollback: revert to previous manual process (documented separately)
- App: [PowerApps link] | List: [SharePoint link] | Flow: [Power Automate link]
- Known issue: approval flow occasionally delayed by ~5 min (Microsoft platform limitation)
- Next steps: add reporting dashboard for leave balances
- Document as you go, not after the fact — memory fades and details get lost.
- Keep entries dated and specific; avoid vague notes like "worked on app."
- Always link directly to artifacts (SharePoint site URL, PowerApps app ID, repo/commit in Cursor) rather than describing their location in prose.
- Write the handoff section as if the next developer has never seen the project.
- Note why a decision was made, not just what was done — this prevents future developers from re-litigating settled choices.
- Waiting until project completion to write documentation from memory — leads to missing steps and inaccurate testing notes.
- Documenting only the happy path and omitting blockers, bugs, or failed approaches (these are valuable context).
- Leaving out exact deployment steps, forcing the next developer to reverse-engineer how the project went live.
- Assuming platform-specific knowledge (e.g., PowerApps/SharePoint terminology) is understood — spell out configuration steps explicitly.