Decide what to build. Then build it properly.

• A real production deployment, not a demo environment. Containerized services behind a load balancer with HTTPS, an encrypted database, credentials injected from managed secret storage, centralized logging, and an automated build-and-deploy pipeline.
• Live bank connectivity, hardened against real data. A full sandbox-to-production cutover followed by the edge-case arc you only get with live institutions: pagination fixes to retrieve complete history, per-account separation, merchant name cleanup, fallbacks for masked descriptors, and incremental sync that can safely re-run.
• Bank credentials encrypted at rest using a managed key service, with a verified end-to-end encrypt and decrypt path.
• A disciplined refactor under load. A 7,400-line monolith decomposed into a compact entrypoint plus twelve focused feature modules, executed as small shippable migrations that never took the application offline.
• A staged front-end rewrite. Eleven independent React applications replacing legacy pages one at a time, with a unified light and dark theme and shared data adapters, avoiding a risky big-bang rewrite.
• Security as a first-class concern. Hardening against the standard attack classes with a dedicated automated security test suite, request forgery protection, content and header policies, rate limiting, and a public transparency page.

• System modeling. A two-band model (the user journey above, the engine services beneath) with typed edges distinguishing user paths from data reads and writes. Every node carried an explicit list of the platform capabilities it required, which is where the build decision actually lived.
• The platform constraint was categorical, not effort-based. The incumbent platform is built for publishing; the product is an application whose value sits in its logic. I identified the specific structural failure points and recommended a split that preserves the existing site for marketing, so no prior work was discarded.
• Target architecture. A layered design in which every component is annotated with the capability it implements, plus an annotated repository tree mapping folders to architecture nodes.
• Bounding the AI. Personalization designed as three ordered stages (deterministic filtering, then recall, then model reranking of a bounded shortlist), so selection stays explainable, fast enough for a notification tap, and degrades to the deterministic stage on failure. Live personalization was separated from content generation, keeping generated material behind human review given the sensitivity of the audience.
• Instrumentation strategy. Product-critical data the product's logic depends on belongs in the client's own database; behavioral research tooling is a solved problem worth buying. Mirrored event naming across both, with field-level masking on sensitive input.
• Stack chosen against real constraints. Selected for the client's existing proficiency rather than theoretical uniformity. A learning curve on the hardest component is a schedule risk, not a virtue. I explicitly declined an extra abstraction layer whose cost exceeded its benefit at that scale.
• Market position and risk, stated plainly. The points of genuine differentiation, and the corresponding risk named directly: an unoccupied category also means an unvalidated demand curve. I named adjacent wedges with demonstrated willingness to pay as lower-risk entry paths.

Deliverables built as working artifacts: interactive where the content is a graph, printable where it is a document, so they serve review sessions and handoff equally.

• Three-stage classification before any action. Label detection, then model confirmation, then a language-processing fallback, routing each ticket to a specialized handler for that category. Typing the ticket before a handler runs is what keeps the action space bounded and the behavior auditable: an agent that can do a known set of things is a system; one that can do anything is a liability.
• Multi-provider model abstraction across three vendors. Switching models is a configuration change, not a rewrite. Given how fast the frontier moves and how often pricing shifts, this is the single decision I'd most defend eighteen months later.
• The hard one: automated production data loads. Orchestrates a full multi-step pipeline: it refreshes staging from production, remaps and fetches referenced input files from vault storage (with polling, because the transfer is asynchronous), executes each load script while parsing live job status, and chains directly into the code-patch workflow when a request needs both a data load and a deployment.
• Surgical configuration patching. Rather than flagging a diff for a human to review, the patch handler edits only the affected sections of the target configuration. That's the difference between an assistant that makes work and an agent that finishes it.
• Scheduling, immediate or future-dated. Backed by a schedule table with its own management page, so time-based operations are queued and visible rather than remembered.
• Observability built for the humans supervising it. An analytics dashboard for volume and processing-time trends, a live visualization of what the system is doing at that moment, and a retrieval-backed chat interface for natural-language search across historical ticket data.
• Reliability hardening, the unglamorous half. Race conditions in asynchronous remote file transfers, database reset scripts made non-interactive across nested remote hops, version-control staging edge cases. This is the work that decides whether a team actually lets an agent touch production.

Details generalized. Available in fuller technical depth under NDA.