While decades of research into formal verification have brought provable correctness guarantees closer to being a part of developers' everyday reality, provable guarantees about algorithmic complexity are harder to come by. This is not for lack of effort. Algorithmic complexity and program cost don't play nicely with abstraction, and so they can prove a difficult target for the kinds of compositional analysis that formal tools handle best. However, the classical algorithm analysis technique known as amortized analysis [75] is promising in this regard: it allows one to selectively break abstraction barriers to precisely and compositionally calculate program costs.In this thesis, we leverage amortized analysis to make two contributions which make some progress towards our goal of provable cost guarantees for the masses.We begin by taking a cue from the interactive theorem proving school of software verification.We develop a functional language called LambdaAmor, which provides a rich refinement type system for in-language amortized cost analysis. We begin with a previously-developed core calculus called λ-Amor [64], transform it to an algorithmic type system which is amenable to implementation, and subsequently implement the language in OCaml.Next, we move to considering a more lightweight method of analyzing the cost of programs, namely the extract-and-solve method of recurrences. This technique is already used (explicitly or otherwise) by practitioners of functional languages, and regularly included in introductory CS curricula. However, the technique is informal, error-prone, and not immediately applicable to amortized cost analysis. Following on work by Danner et al. [19], we formalize the process of amortized analysis by recurrence extraction as a language-to-language translation, and use this to prove the technique's correctness. v 1. INTRODUCTION 7 This is somewhat inaccurate: the presence of a sum construct in the language of index terms breaks linearity, but this is rarely a problem in practice. 8 The ∀j ∶ N... being irrelevant is crucial here: since one cannot pattern match on the value of j, the cost of the computation must be uniform in j.10 Alternatively, this can be thought of as being analogous to width subtyping for records.