GradPlan / My notebook
What changed along the way.
Notes on decisions, proposed changes and lessons as GradPlan develops. Not just what changed, but why.
Notes from the process.
Entries distinguish proposals and retrospective accounts from released features. These entries use the available context, not a fabricated version history.
01Keeping the first release focused
How to prioritise a useful application journey without letting additional capabilities define the release.
Keeping the first release focused
How to prioritise a useful application journey without letting additional capabilities define the release.
The problem
The platform can expand in many directions. Each additional capability introduces development, support and validation work.
The options
Broaden the feature set before release, or focus on a coherent core workflow and keep additional plugins outside the immediate scope.
The approach
Prioritise the core journey using user value, feasibility, cost and effort. Record attractive ideas without treating them as release requirements.
What needs validating
Whether the core journey delivers enough value on its own, and where users encounter friction before asking for more features.
This is a retrospective scope account. It does not assert a release date, conversion improvement or completed experiment.
02Making reusable documents easier to find
Exploring a dedicated library without losing the relationship between documents and applications.
Making reusable documents easier to find
Exploring a dedicated library without losing the relationship between documents and applications.
The trigger
Reusable content needs an understandable home. Application-specific storage and a global library solve different parts of that problem.
The proposal
Create a dedicated library entry in the navigation, with explicit relationships to relevant applications.
The trade-off
Visibility and reuse improve only if the user can understand versions, ownership and which document belongs to which application.
The planned check
Ask a participant to locate an existing document and use it for another application. Record completion, wrong turns and help needed.
Proposal and test plan only. No measured usability result or implemented navigation change is claimed.
03Treating upload readiness as a release decision
Why the evidence needed to reopen a feature matters as much as the code change itself.
Treating upload readiness as a release decision
Why the evidence needed to reopen a feature matters as much as the code change itself.
The context
New document and interview-audio uploads were paused while readiness was reviewed. Local fixes alone were not sufficient proof of a verified production release.
The decision
Keep the pause in place pending appropriate verification, while communicating which permitted workflows remain available.
The principle
Distinguish implementation, deployment and verification. A change in one stage is not evidence of completion in the others.
The boundary
A public case study should explain the user impact and decision criteria without exposing sensitive security findings or internal implementation details.
This records the owner-reported September 2026 position. It is not a live status check or a claim that the feature has reopened.
04What would better CV feedback look like?
Defining an evaluation around faithful, useful suggestions rather than simply more polished wording.
What would better CV feedback look like?
Defining an evaluation around faithful, useful suggestions rather than simply more polished wording.
The question
Can a structured approach improve relevance and usefulness without inventing experience, qualifications or achievements?
The comparison
Compare a simple baseline with structured applicant evidence and job requirements, using the same synthetic inputs.
The checks
Review factual faithfulness, relevance, required editing, latency and cost. Include missing information, conflicting dates and unmet qualifications.
The reporting plan
Record the sample, configuration, rubric, failures and limitations. Keep offline output quality separate from any claim about hiring outcomes.
Evaluation design only. No models have been run and no scores, costs or response times are supplied in this portfolio.
No entries match this filter.
Questions for the next iteration.
Proposed priorities, not commitmentsNow
Validate the core journey
Clarify readiness and identify where the intended task becomes difficult.
Next
Improve the observed friction
Use specific feedback and checks to decide which changes matter most.
Later
Expand where evidence supports it
Consider additional capabilities without treating a longer feature list as progress.