← Reflective analysis of developing a digital outcome

Tools and techniques decisions

The most predictable decision category, and the easiest to over-describe instead of analyse.

Categories a tools/techniques decision usually falls into

• Language or framework — chosen for a specific capability the alternative lacked (e.g. a framework with built-in form validation versus writing it by hand).
• Data storage — a database versus a flat file versus a spreadsheet, and what integrity or querying need drove the choice.
• Hosting and deployment — where and how the outcome runs, and what that meant for cost, availability, or who could access it.
• Version control and workflow — how changes were tracked, and whether that made recovering from a mistake possible or not.
• Third-party libraries or assets — using an existing tool versus building the equivalent yourself, and the trade-off in time versus control.

Exam-style A tools decision that traces to a specific consequence You chose a specific charting library instead of drawing the graphs yourself with raw code. Write the decision up as analysis. DECISION: used an existing charting library rather than writing custom drawing code. ALTERNATIVE REJECTED: hand-coded drawing, which would have given full control over appearance but cost far more development time for a feature that was not the outcome's main purpose. REASON: the project's value was in the data it presented, not in custom graphics, so time was better spent on the data model and the ten actual users who would read the charts. INFLUENCE ON THE OUTCOME: the charts render correctly on both desktop and phone screens for free (the library handles responsiveness), which a hand-built version at this timeline would not have managed. COST: less visual control — one chart type the project needed was not available in the library, so a workaround was needed for it, and the library's update introduced a rendering bug that had to be fixed mid-project. ✓ The named cost (loss of visual control, a mid-project bug) is what makes this analysis rather than a description of what tool was used. ✕

Naming the tool is not the decision

Writing "I used React" or "I used MySQL" names a TOOL, not a decision. The decision is the comparison: what you rejected, and why this one served the project's actual requirements better. A sentence that could be true of any project using that tool has not yet reached the specific decision the schedule is grading.

Signs a decision is worth writing up

• It had a genuine ALTERNATIVE you seriously considered and rejected — not something you never actually thought about doing differently.
• It had a COST as well as a benefit — a decision with no downside was probably not a real decision.
• You can point to a SPECIFIC, named part of the outcome it changed, not "it made things better" in general.

✓

Keep a running decision log while you build

The best 91909 answers come from projects where decisions were written down AS they happened, not reconstructed from memory in the exam. A one-line note each time you choose one approach over another ("used library X over hand-coding because...") gives you real, dated evidence months later instead of a guess at what you were probably thinking.

Practise just this