What I Build

The technology surface is wide because senior engineering is a portable skill. The patterns that make a backend reliable, a frontend maintainable, an infrastructure stack predictable, and an AI platform observable are the same patterns transferred across stacks. 16 years of production work means the next stack is rarely a learning curve; it is usually a recognition.

• Backend services and APIs: Node.js, Python, PHP (Laravel), Go, TypeScript. REST, GraphQL, gRPC, server-sent events
• Frontend systems: React, Next.js, design systems, SSR/SSG, performance optimization, design system architecture
• Infrastructure: AWS, GCP, Kubernetes, Terraform, Docker, multi-region deployment, cost optimization
• Data pipelines and ETL: Postgres, BigQuery, Snowflake, dbt, Airflow, streaming with Kafka and Kinesis
• Real-time systems: WebSockets, queues, event streaming, pub-sub, CDC pipelines
• Authentication, authorization, and multi-tenancy: OAuth, OIDC, SAML, RBAC, row-level security, B2B SaaS isolation
• CI/CD and developer platforms: GitHub Actions, GitLab CI, internal developer platforms, monorepos, build optimization
• AI platform engineering: LLM gateways, prompt management, RAG infrastructure, agent observability, eval pipelines
• Performance engineering: profiling, query optimization, caching, CDN strategy, latency budgets
• Security and compliance baseline: SOC2 readiness, secrets management, audit logging, PII handling

When to Hire a Senior IC vs an Agency vs a Junior Contractor

The economics are real and worth thinking through. Agencies bill teams of 3-10 engineers at $150-$300/hr blended rate, with the senior actually thinking on a project alongside several juniors executing. Junior contractors run $40-$120/hr globally and produce code that requires senior review and frequent rework. A senior independent IC sits at $200-$500/hr and ships work that does not require senior review because they are the senior. Total cost of ownership often inverts the surface rate.

The decision is not which is cheapest per hour. It is which produces the lowest total cost over the next 12-24 months including the cost of rework, the cost of bad architecture decisions compounding, and the cost of slowing the internal team down with low-quality work that needs cleaning up.

• Hire an agency when: you need 5-15 engineer-equivalents of throughput, your team owns the architecture, and you can absorb the quality variance across the agency bench
• Hire a junior contractor when: the scope is small, well-defined, and someone on your team has the senior capacity to direct and review the work
• Hire a senior IC when: the work involves architecture decisions, technology choices, integration patterns, or sets the foundation for years of future build. The judgment is the deliverable
• Hire a senior IC when: your team is mid-level and needs a heavyweight to set patterns and unblock decisions, not just ship tickets
• Hire a senior IC when: you need rapid technology survey, vendor evaluation, build-vs-buy decisions, or technical due diligence
• Skip the senior IC for: pure ticket execution at scale, low-complexity feature shipping where your existing team is sufficient, or any work where the deliverable is volume rather than judgment
• Hybrid model that works: senior IC sets architecture and unblocks decisions; agency or internal team executes; senior IC reviews at milestones

Why Senior Engineering Compounds

The cost of bad early decisions compounds. Schema choices, API contracts, infrastructure shape, and authentication architecture decided in week three burn budget for years. A senior IC making the right calls at week three saves more than three additional teams of engineers spending the next two years fixing the wrong calls. This is not theoretical: I have audited at least a dozen production systems where a single early architectural mistake cost six to eight figures of cumulative engineering time to work around.

The patterns that matter most: data model boundaries (entity ownership, foreign key direction, what is in the same database vs separate), API contracts (versioning, idempotency, error shape), service boundaries (where to split, how to communicate, what to share), authentication and authorization architecture (especially for B2B SaaS multi-tenancy), and the infrastructure shape (single region vs multi, monolith vs services, queue topology). Each of these is approximately impossible to change cheaply after 12 months of production usage.

• Schema design: entity boundaries, foreign key direction, denormalization tradeoffs, decisions that propagate through every query for the next 5 years
• API contracts: versioning strategy, idempotency, error shape, pagination, decisions that propagate through every client integration
• Service boundaries: monolith vs services, where to split, how to communicate, what to share. Wrong splits compound exponentially
• Authentication and authorization: especially for multi-tenant SaaS, where wrong choices either leak data or block future features
• Infrastructure shape: single region vs multi, what to run vs what to buy, monolith vs services, queue topology
• Build vs buy: what to write in-house vs hand to a vendor, the most underrated senior engineer decision
• Observability: instrumentation built in from day one is 5x cheaper than retrofitted
• Security baseline: secrets management, audit logging, PII handling, foundation that is painful to add later

Open-Source Footprint and What It Says About How I Engineer

Open-source work is the most public proof of how an engineer engineers. Apiato is a PHP framework I authored, built on Laravel, that organizes code into a port-and-adapter Container architecture and ships with auth, API generation, and SDK tooling out of the box. It has thousands of GitHub stars and an active contributor community. Laradock is a Docker-based PHP development stack I maintain, used by hundreds of thousands of developers, with regular major releases over the past 9+ years.

Beyond those two, contributions are spread across the JavaScript, TypeScript, Python, and Docker ecosystems. The point of mentioning these is not the names; it is what consistent open-source maintenance over a decade proves about engineering discipline. Open-source work has public code review, public bug reports, public design discussions, and a backlog that does not let you cut corners. Anyone who has maintained a popular project for 5+ years has been forced to confront every category of failure mode in production engineering.

• Apiato: PHP framework on top of Laravel with port-and-adapter Container architecture, auth, API generation, generators
• Laradock: Docker development stack for PHP, used by hundreds of thousands of developers globally
• Contributions across JavaScript, TypeScript, Python, Docker ecosystems
• Public talks and writing on architecture, framework design, and developer experience
• 9+ years of open-source maintenance: every category of production failure has been encountered at least once
• Public proof of code review discipline, design judgment, and the willingness to maintain decisions over time

Backend Architecture and Distributed Systems

Most production incidents trace back to distributed-systems patterns the team did not internalize early. Idempotency on every write, retry policies with exponential backoff and jitter, circuit breakers on external dependencies, timeouts at every layer, observable error boundaries, and partial-failure tolerance are not optional in 2026 even for small teams. They are the difference between a system that survives the first traffic spike and one that does not.

The decisions that matter most at backend scale: choice of database (Postgres until something proves it cannot be Postgres), queue topology (managed SQS or RabbitMQ vs self-hosted Kafka, depending on volume and ordering needs), service split criteria (split for organizational scaling, not for technical scaling), and observability before optimization (you cannot optimize what you cannot see).

• Postgres-first: 95% of workloads under 10TB and under 100K queries per second are best served by Postgres
• Queue topology: SQS or RabbitMQ for most teams; Kafka only when you need replay, ordering guarantees, or high-throughput streaming
• Idempotency keys on every write endpoint: the single highest-leverage reliability pattern
• Retry policies: exponential backoff with jitter, distinguish retryable from terminal errors
• Circuit breakers on every external dependency: payment, email, SMS, AI providers
• Observability before optimization: tracing, structured logs, metrics from day one
• Service split discipline: split for team autonomy, not for premature scaling
• API contracts as durable interfaces: versioning, deprecation policy, change discipline

Frontend Systems and Design System Architecture

Frontend engineering at senior level is design system architecture, performance budgets, and the rendering strategy decisions that lock in for years. React and Next.js dominate the stack and are the right default for most product teams, but the choices that compound are the ones below the framework level: how the design system is structured, what the rendering boundary is, how data fetching is colocated with UI, and how the team writes consistent code at scale.

The patterns that matter: design system as a typed library with API discipline equivalent to a backend service, rendering strategy (SSR, SSG, ISR, RSC, client-only) chosen per route based on data freshness and SEO needs, performance budgets enforced in CI, and accessibility baseline built in from day one because retrofitting is 5-10x more expensive.

• React 18+ with Next.js App Router and Server Components for most product surfaces
• Design system as typed library: tokens, primitives, composed components, with API discipline
• Rendering strategy per route: SSR for personalized, SSG for static marketing, ISR for semi-dynamic, RSC where it fits
• Performance budgets enforced in CI: LCP, INP, CLS, JS bundle size, with hard fail thresholds
• Accessibility from day one: keyboard, screen reader, color contrast, motion preferences. Retrofitting is brutal
• State management: server state with TanStack Query or RSC, minimal client state with Zustand or built-in React
• Forms: react-hook-form with Zod validation, the most boring and most reliable stack

Infrastructure, DevOps, and Platform Engineering

Infrastructure decisions compound the fastest because they are simultaneously the most tedious to change and the most expensive when wrong. The right default in 2026 for most teams: AWS or GCP, Terraform for everything that has state, Kubernetes only when you need it (most teams do not), containerized workloads on managed services (ECS, Cloud Run, Fargate, App Runner), and observability and cost visibility built in from week one.

Cost optimization in cloud infrastructure follows the same shape as cost optimization elsewhere: visibility first, governance second, optimization third. Most teams skip the first two and try to optimize blindly, which produces inconsistent savings and no lasting discipline.

• AWS or GCP for most teams; Azure if your enterprise customer mix demands it
• Terraform for stateful infrastructure: VPCs, databases, queues, secrets, IAM, anything that survives a deploy
• Kubernetes only when you have a real need: multi-team platform, complex networking, advanced scheduling. Most teams should not
• Managed services first: RDS, Aurora, Cloud SQL, SQS, EventBridge, CloudWatch. Self-host only with reason
• CI/CD: GitHub Actions for most teams, with deployment pipelines per environment and rollback automation
• Observability: structured logs to CloudWatch or Datadog, tracing with OpenTelemetry, metrics with Prometheus or cloud-native
• Cost visibility from day one: tagged resources, monthly variance reports, alerts on growth not absolutes
• Disaster recovery as written runbook, tested quarterly, with RPO and RTO targets

AI-Adjacent Platform Engineering

In 2026 every senior engineering engagement touches AI infrastructure somewhere. The patterns that matter: LLM gateway in front of all model calls (Portkey, LiteLLM, or in-house) so you can route, cache, observe, and rate-limit centrally; prompt management as code (versioned, tested, with eval-gated rollout); RAG infrastructure with proper retrieval evaluation (recall@k, MRR, not vibes); observability for non-deterministic systems (full trajectory logging, not just outputs); and cost discipline at the gateway layer.

The senior engineering contribution is rarely the prompt itself. It is the platform: the LLM gateway, the eval pipeline, the deployment automation that routes prompts through CI like code, the cost dashboards, the guardrails, the rate-limit enforcement, the observability. These are engineering patterns I have built into production AI systems and continue to build into client systems.

• LLM gateway: central control point for routing, caching, rate limiting, observability, cost attribution
• Prompt management as code: versioned, eval-gated, deployed through CI like any other code change
• RAG infrastructure: chunking strategy, embedding model selection, vector DB choice, retrieval evaluation
• Agent observability: full trajectory logging, replay tooling, drift detection
• Evaluation pipelines: frozen eval sets, regression tests on every prompt change
• Cost discipline at the gateway layer: budgets, alerts, per-feature attribution
• Guardrails: input validation, output checking, PII redaction, prompt injection awareness
• MCP servers and tool infrastructure: exposing internal systems to agents safely

How I Engage

Engagement shapes vary by what the team actually needs. Architecture review and rewrite (1-3 weeks, fixed scope, written report) is the smallest engagement and the most common starting point. Hands-on implementation (4-12 weeks, retainer or fixed-bid) for greenfield builds, painful migrations, or rescues of stuck projects. Ongoing fractional senior engineer (1-3 days per week, multi-month) for teams that need senior judgment continuously but cannot yet hire a principal engineer full-time.

The first call is free. Walk in with the actual problem: a stuck migration, a system you are about to build, a vendor decision, an architecture you suspect is wrong, an AI feature that is over budget. You will leave with a written assessment, an opinion, and an honest read on whether bringing me in is the right call or whether the problem is solvable internally with a specific direction.

FAQ