How do you write and run an RFC, record decisions as ADRs, set technical strategy, and decide between build, buy and an Apple API?

A design document or RFC exists to get the right decision made by the right people with the context to judge it. A good one has: the problem and why now, goals and non-goals, the options considered (at least two real ones, including “do nothing”) each with honest costs and risks, the recommendation and why, the migration and rollout plan, the riskiest assumptions and how to test them cheaply, security, privacy and accessibility impact, the operational plan (metrics, flags, ownership) and open questions. Circulate it early to the people affected, set a review deadline, separate comments on the problem from comments on the solution, and decide who has the final say (a named approver) so it does not stall. An Architecture Decision Record (ADR) is the short, immutable outcome: context, the decision, the alternatives rejected and the consequences, with a status (proposed, accepted, superseded). It lives in the repository next to the code so that “why did we do it this way” has an answer years later, and a later decision supersedes an ADR instead of rewriting history.

Technical strategy is more than a list of projects. A useful shape is a diagnosis (what is actually wrong or at stake: slow builds, fragile releases, duplicate stacks), a guiding policy (the approach that addresses it, which also says what you will not do) and coherent actions that reinforce each other, tied to the business outcome. For build, buy or use an Apple API, make the criteria explicit and weigh them (the lab applies a weighted score): is it a differentiator for the product, time to market, total cost of ownership including maintenance and upgrades, integration and lock-in risk, security and privacy exposure, the vendor’s or framework’s direction and track record, and the team’s skills. A system framework is usually the right default for commodity capabilities (it is maintained for years, integrates with the platform and costs no binary size), a vendor for undifferentiated and complex ones (payments, auth, analytics) with an exit plan, and building only where it creates a lasting advantage. Revisit decisions on a schedule and after surprises, and write down what would make you reverse the call.