About

The O'Brien & Son Story

My mother founded O'Brien & Son, Inc. when her first son was born. For nearly four decades, the company built a reputation across the Chicagoland area for windows, siding, gutters, soffit, and fascia. Quality craftsmanship. No shortcuts. Stand behind your work.

When she closed the business in 2025, I bought it.

Not the equipment. Not the client list. The name, and what it had spent forty years earning. Because O'Brien & Son had built what most businesses never achieve: a reputation where your work speaks before you do, and a standard you can actually be held to. Letting that disappear into internet history was not something I was willing to accept.

The tools are different now. The materials are different. The clients are different. The standard is not.

Where O'Brien & Son built from the outside in, I build from the inside out. Software architecture, security engineering, and backend systems instead of windows and siding. The commitment is the same: design it right, build it to last, and be the person who answers for it when something goes wrong.

This site is my workshop.

My Background

I am a software architect and security leader with a track record of building production systems that handle complexity without collapsing under their own weight. My work sits at the intersection of software development and security engineering, applied to full-stack system design for the continuous delivery of value.

I currently serve as Senior Solutions Architect for Security at a Fortune 500 Agriculture and Energy Cooperative, where I lead security architecture reviews, establish secure development standards, and work with engineering teams to build systems that balance security requirements, business capabilities, and development velocity. Prior roles focused on web development, DevSecOps, and automation.

What drives my work: Security and quality are not features 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 accommodate them later.

I have spent my career in the messy intersection between "make it ship" and "make it secure," and I have learned that the right architecture enables both. Backend-first development, clear API contracts, separation of concerns, and systematic thinking about authorization are not ideals. They are how you prevent the architectural debt that cripples projects years after the initial build.

Technical Approach

I build from the domain model outward.

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

This is not perfectionism, and it does not mean the customer waits until the end to see anything. It is rework reduction. 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 DTO designed for its specific purpose is one less breaking change when requirements evolve.

Core principles:

• Solve the customer need. Without a solved customer need, everything is academic
• Security as architecture, not afterthought. Authentication, authorization, and data protection are design decisions, not post-deployment fixes or penetration test remediation items
• 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. Test the business logic and authorization rules, not getters and setters

Current Work

I continue to work in application security and software architecture, building systems that balance security requirements with engineering velocity. But I am 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.

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 work on this site represents production-quality engineering applied to problems I find worth solving.

Whether it is a lacrosse management platform built to help manage an 8U Girls lacrosse team, a security tool designed to address a gap I identified, or an architectural pattern I want to prove out, I am 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 have done professionally. It is about demonstrating how I think through problems, make architectural decisions, and build systems that can be maintained and extended over time.

Engineering articles here follow a proof-based structure: proposition, constraints, evidence, and what the evidence actually says. The format is an homage to the PoC||GTFO articles that helped shape my early career. If the benchmark comes back negative, the post reports it. A falsified result is more publishable than a confirmed one.

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

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

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