Deciding through a technical test, not an assumption

Alternatives considered

Discarded

Keep the two initial choices without a concrete viability check.

Chosen

Run a reproducible technical test and replace the choices that fail in that environment.

Decision made

Use concrete technical tests before locking in foundational decisions. Two choices were reverted during development after reproducible viability problems were detected, and were replaced before building on top of them.

Rationale

The evidence from a test allowed the team to catch fragility early and kept that foundation from conditioning the rest of development.

Frequently asked questions

What did Pymerce decide about "deciding through a technical test, not an assumption"?

Use concrete technical tests before locking in foundational decisions. Two choices were reverted during development after reproducible viability problems were detected, and were replaced before building on top of them.

What's the difference between a technical spike and just assuming something will work?

A spike is a concrete, time-boxed test to check whether a technical choice actually works in the real environment before building on top of it. Pymerce applied this to two foundational decisions: instead of assuming they were viable, both were tested — and reverted after reproducible problems showed up.

What's the point of a viability test before building on a foundational choice?

To catch fragility early, while changing direction is still cheap. If Pymerce had built the rest of the system on an untested choice and it failed later, reverting it would have cost far more.

What happens if a foundational decision fails after you've already built on top of it?

That's exactly the risk this practice avoids: the two choices that failed were caught and replaced before the rest of the development depended on them — not after.