How We Choose Our Tools
We don’t build software in-house if the domain is not a core differentiator of our business and we can find a trustworthy, high-leverage, philosophically aligned product, service, framework, or library (or one that can be wrapped up in a philosophically-aligned interface) because focus is precious and we’ve got more than enough hard problems ahead.
Given a new server-side application domain with typically read-heavy workloads and evolving requirements, we use SQL databases for persistence because they are sufficiently malleable, have ACID transactions, and yield high performance on evolving workloads without frequently requiring us to choose a representation for performance reasons.
We use database-backed job queues for enqueuing background work from RDBMS-backed apps because it ensures that no job is ever successfully enqueued as a result of an aborted transaction, while ensuring that every job resulting from a committed transaction is ultimately worked or otherwise accounted for.
We invest in building native apps for iOS and Android mobile phones because native experiences tend to be better than web experiences on mobile, and mobile-specific implementations ensure that we are building the best experiences for small screens. They allow us to meet the high latency and production values expectations of mobile customers, and to provide an incredibly low-friction channel for customer interaction.
We never roll our own cryptosystems, we seek security solutions that don’t rely on cryptography where it can be avoided (like not storing sensitive information we don’t need at all), and we strive to choose the highest-level, tightly-integrated services, libraries, and tools that can possibly solve our problems in close consultation with security engineering because crypto is hard.
When cryptography is needed, we seek out crypto anchored solutions like KMS because they provide a chokepoint on exfiltration of sensitive data.