Technology Selection Guidelines
These guidelines help engineering teams at Sanlam FinTech evaluate technologies consistently and make informed decisions that align with our organisational goals.
Evaluation Criteria
When assessing a technology for inclusion on the radar or for use in a project, consider the following criteria:
1. Maturity & Stability
- Is the technology production-ready or still experimental?
- How stable is the API and release cadence?
- What is the track record for backward compatibility?
2. Community & Ecosystem
- Is there an active open-source community or strong vendor support?
- Are there quality libraries, plugins, and integrations available?
- How easy is it to find documentation, tutorials, and Stack Overflow answers?
3. Organisational Fit
- Does it solve a real problem we face at Sanlam FinTech?
- Can our teams adopt it without excessive ramp-up time?
- Does it integrate well with our existing technology stack?
4. Licensing & Cost
- Is the licence compatible with our commercial use?
- Are there hidden costs (per-seat pricing, data transfer fees, vendor lock-in)?
- What is the total cost of ownership including training and operations?
5. Security & Compliance
- Does it meet our information security requirements?
- Is there a track record of timely security patches?
- Does it support audit logging and access control as needed?
Ring Definitions in Detail
| Ring |
Criteria for Placement |
| ADOPT |
Proven in production across multiple teams. Low risk. Recommended as a default choice. Teams should use this unless there is a compelling reason not to. |
| TRIAL |
Successfully used in at least one real project. Benefits confirmed but not yet widely adopted. Teams are encouraged to try it on appropriate projects and share feedback. |
| ASSESS |
Shows clear potential. Worth investing time in prototyping or proof-of-concept work. Higher risk — not yet proven within our organisation. |
| HOLD |
Not recommended for new projects. May be legacy technology being phased out, or something that was assessed and found unsuitable. Existing usage can continue but migration should be planned. |
Decision Principles
- Pragmatism over purity — Choose technologies that solve real problems effectively, not the theoretically perfect option.
- Team autonomy with guardrails — Teams are free to choose from ADOPT and TRIAL technologies. ASSESS technologies require discussion with a Principal Engineer. HOLD technologies require an exception.
- Evidence over opinion — Proposals should be backed by hands-on experience, benchmarks, or case studies — not just blog posts or conference hype.
- Reduce, don't multiply — Before introducing a new technology, consider whether an existing one already on the radar can serve the same purpose. Fewer technologies means less operational overhead.
- Reversibility matters — Prefer technologies that don't create deep lock-in. The cost of switching away should factor into every assessment.