Technology Selection

Technology Selection

Decides the stack, and writes down why, including what was rejected and what the choice costs.

dependency-selection decides whether to add one library to an existing project. This skill decides the foundations of a new one, where each choice constrains everything above it and is expensive to reverse.

1. Order of decision

Decide in this order. Each decision narrows the next.

1  Is a new project even required, or does something existing do this
2  Runtime and language
3  Persistence
4  Application framework
5  Authentication approach
6  Hosting and deployment target
7  Everything else: UI system, testing, tooling, observability

Deciding the UI library before the persistence model is how projects acquire a stack that nobody chose.

2. The decision record

Every major decision produces this, with nothing omitted:

Decision       what was chosen
Requirement    the requirement or constraint that drives it
Why            the reason, specific to this project
Alternatives   at least two, named
Rejected       why each one was rejected, honestly
Trade-off      what is worse because of this choice
Cost           licence, hosting, operational burden, recurring money
Reversal       what it costs to change this in six months

The Rejected lines are the test of the record. If every alternative was rejected for being obviously bad, the alternatives were straw men and the decision was made before it was evaluated.

The Trade-off line is mandatory. A choice with no downside was not analysed.

3. Criteria

Applied to each candidate, weighted by what the project actually needs.

Team and Operations are the two that get skipped and the two that determine whether the project survives handover.

4. Defaults, and when to leave them

The boring choice is the default. Leaving it requires a stated reason.

Each row is a place where projects acquire complexity that no requirement justified. The default is not always right; it is always the thing to argue against rather than around.

5. Refusals

Refused, with the reason stated once:

• a technology chosen because it is popular, new, or on a conference stage;
• a distributed architecture for a load that one process handles;
• a message broker with no asynchronous requirement;
• a cache before a measurement;
• a second database for a shape the first one handles;
• a framework the maintaining team has never used, without a stated reason that outweighs it;
• a technology whose licence conflicts with the project's distribution;
• an unmaintained project chosen out of familiarity;
• anything whose operational burden exceeds the team that will carry it.

6. Inherited stacks

When the stack is imposed by the client or by an existing system, the decision is still recorded, as inherited:

Decision     PostgreSQL
Source       imposed, the client's operations team runs PostgreSQL only
Consequence  no evaluation performed, and none needed
Risk         if the project later needs a document store, the constraint is
             renegotiated rather than worked around with a JSON column

Recording an inherited decision costs four lines and prevents the next engineer from assuming it was chosen freely.

7. Cost note

Every stack carries recurring cost. State it before approval, not after the first invoice.

| Item | Monthly | Scales with | Free tier |
|---|---|---|---|

Include hosting, database, object storage, mail, error tracking, any managed service, and any per seat tooling the project requires. A stack that is cheap at zero users and expensive at a thousand is a decision the user should make knowingly.

8. Protocol

1. Read the specification, the constraints and the surviving assumptions.
2. Ask question 1 of section 1 honestly.
3. Decide in the order of section 1.
4. For each decision, apply section 3 to at least two real candidates.
5. Write the record from section 2, including trade-off and reversal cost.
6. Check against the defaults table, section 4, and justify every departure.
7. Check against the refusals, section 5.
8. Produce the cost note, section 7.
9. Hand the decisions to architecture-proposal.

9. Auto-critique

Score from 0 to 5: decision order respected, real alternatives rather than straw men, trade-off stated for every choice, reversal cost stated, departures from the defaults justified, operational burden considered, cost note honest, inherited decisions recorded as such.

Threshold: no axis below 3, average at least 4. A decision whose only stated reason is popularity, familiarity or novelty is an automatic failure.

10. Interfaces

• Upstream: requirements-analysis, clarification-gate.
• Lateral: dependency-selection for individual libraries inside the chosen stack.
• Downstream: architecture-proposal, validation-gate, devops-core.