The O'Brien & Son Story

My mother founded O'Brien & Son, Inc., an exterior remodeling company, at the birth of her first son. For nearly four decades, O'Brien & Son specialized in windows, siding, shutters, gutters, soffit, and fascia, building a reputation for quality craftmanship and attention to detail.

When she closed the business in 2025, I inherited more than just a domain name. I inherited a legacy of building things properly and excellent customer service. Rather than let obrienandson.com fade into internet history, I saw an opportunity to pivot from physical construction to digital transformations.

The name remains. The commitment to quality craftmanship remains. The focus has simply shifted from exterior remodeling to software architecture.

This site is my workshop. A place where I can demonstrate systematic engineering, sound architectural principles, security-conscious designs, and experiments with new and emerging technologies. Like O'Brien & Son has done in the past, what I build here is meant to last, to be maintained, and to withstand scrutiny.

My Background

I'm a software architect and security leader with a track record of building production systems that handle complexity without collapsing under their own weight. My experience bridges the gap between software development and security engineering bringing the best practices into full-stack system design for the continuous delivery of value to my customers.

Most recently, I serve as a Senior Solutions Architect for Security at a Fortune 500 Agriculture and Energy Cooperative. Part of my responsibilities are leading security architecture reviews, establishing secure development standards, working with and across engineering teams to build systems that balance security requirements, business capabilities, and development velocity. Prior to that, I held roles focused on web development, DevSecOps, and automation.

What drives my work: I believe that security and quality are not features that you bolt on at the end. They are architectural decisions you make at the beginning. The best systems are designed with their constraints in mind, not retrofitted to accomodate, or bandage, them later.

I've spent my career in the messy intersection between "make it ship" and "make it secure," and I've learned that the right archictecture can enable both possibilities to co-exist. Backend-first development , clear API contracts, separation of concerns, and systematic thinking about authorization aren't just ideals; they're how you avoid architectural debt that cripples projects years down the line.

Technical Approach

I build from the domain model outward.

Too many projects start with the UI or with vague "let's just get something working" prototypes that calcify into production systems. My approach is different. I start with listening to understand the problem statement deeply. Once the problem domain is understood, model the entities and relationships correctly, implement business logic at the appropriate layer, and then build the presentation layer as a mechanical exercise in consuming a well-designed API.

This isn't about perfectionism, and by no means does it mean that the customer shouldn't see something until the end of the process; this is about reducing rework. Every hour spent in upfront design saves three to five hours of refactoring later. Every authorization rule at the API layer is one less security vulnerability in the UI. Every data transfer object, DTO, designed for its specific purpose is one less breaking change when requirements evolve.

Core principles I work from

• Solve the customer need - without solving a customer need, everything is purely academic
• Security as architecture, not afterthought - Authentication, authorization, and data protection decisions are made during design, not post-deployment or from penetration test results
• Backend-first development - Business logic lives in services, not controllers or UI components
• Contract-first APIs - OpenAPI specifications written before implementation, defining clear boundaries between layers
• Separation of concerns - DTOs for transport, entities for persistence, view models for presentation—each with distinct responsibilities
• Test coverage where it matters - Focus on business logic and authorization rules, not getters and setters

Current Work

I continue to work in application security and software architecture, focusing on building systems that balance security requirements with engineering velocity. But I'm an entrepreneur at heart, and this site serves as my workshop for exploring design patterns, demonstrating architectural thinking, and building side projects that solve real problems.

What drives this work: The best way to stay sharp is to build. Not proof-of-concepts or toy applications, but complete systems with real complexity: multi-tenancy, authorization, data modeling, API design. The demonstrations on this site represent production-quality engineering applied to problems I find interesting.

Whether it's a lacrosse management platform I built to help manage an 8U Girls lacrosse team, a security tool designed to address a gap I've identified, or an architectural pattern I want to prove out, I'm always working on something. That entrepreneurial mindset extends beyond side projects; I am always interested in conversations about interesting problems, innovative approaches, or opportunities to build something meaningful.

Areas of focus:

• Backend-first architecture and microservice API design
• Security architecture across application, API, and infrastructure layers
• Domain modeling for complex business workflows
• Authorization patterns for multi-tenant systems
• Systematic approaches to reducing technical debt

This site is not about showcasing what I've done professionally. It's about demonstrating how I think through problems, make architectural decisions, and build systems that can be maintained and extended over time.

Building things properly takes time. This is where I take that time.

I'm always open to conversations about challenging problems, innovative projects, or opportunities to collaborate on something worthwhile. Connect with me on LinkedIn.

Note: I'm not interested in vendor solicitations, staffing agency cold outreach, or sales pitches. If you're reaching out about actual engineering work or collaboration, I'd love to hear from you.