How I Think About Problems
Most technical problems are actually people problems in disguise. Before writing a single line of code, I try to understand who is affected, why the current situation is not working, and what a better outcome actually looks like for them.
When a client came in with a restaurant running on paper tickets and a whiteboard for table status, the surface problem was “we need software.” The real problem was that staff were making decisions without shared context orders got lost, tables sat empty while guests waited. The solution was not just digitizing the workflow, it was designing around how information actually moves during a busy service.
I use the same pattern on every project: clarify the situation first, define what success looks like before touching the implementation, then work backwards from the outcome to the architecture. Documentation BRD, PRD, TRD is how I externalize that thinking so the whole team is solving the same problem.
The hardest part is usually not the code. It is knowing which problem is worth solving and which requirements are symptoms of a deeper issue. That clarity is what separates a working product from a technically correct one that nobody uses.
🎬 Introduction
Archive (2024) : Application video for the Apple Developer Academy.