When Tapin Wallet needed XRP Ledger support, the easy path was pulling in an existing client library and moving on. I did not take it. I wrote the address derivation, the binary transaction codec, and the signing flow from scratch, in plain Java, with no external XRPL dependency at all.
That decision cost time up front. It also taught me things a library would have quietly hidden from me. XRPL amounts encode differently depending on whether they are native XRP or an issued currency, and getting that wrong does not throw a friendly error, it produces a transaction that looks fine until the network rejects it. Field ordering in the binary codec is not arbitrary either, it follows a specific canonical sort that has to be implemented exactly right or every signature you produce will be invalid.
I would do it again
None of this was about distrust of the existing libraries. It was about trust boundary. A hand rolled implementation, one I fully understand line by line, is a smaller trusted surface than a dependency I have to take on faith, especially for code that touches private keys and moves real value. On a constrained mobile runtime, it also meant one less thing that could fail to load correctly.
I do not default to writing everything from scratch. Most of the time a well audited library is the right call. But for the parts of a system where a subtle bug means someone loses money, understanding every line yourself is worth the extra time it costs.