Peter Fuller
Menu

Principal software engineer · Pflugerville, Texas

I build the second version fast so the third one is right.

Data, AI, and platform architecture

Customers rarely know what they want until they’ve seen two or three versions of it. I build those versions fast, test the hard assumptions along the way, and leave the team with production code and patterns they can own.

The title is VP, Product Architecture. The job is still writing and reviewing production code most days.

View selected work Download résumé

Selected work

Systems that had to survive production

These products are private, so I describe the decisions and controls rather than customer specifics.

Featured case study · Applied AI

Canvas lets product owners ship applications engineers never had to write

Constraint: A six-person team needed to deliver focused agency applications without displacing core-platform work or letting generated code bypass engineering controls.

Jul 2026production launch
3 agenciesseparate production tenants
~3,000producer records managed
2 modulesin production
6 engineerson the core platform team
~3 weeksidea to beta-ready

What I built

The MCP server, tooling, and delivery pipeline behind Canvas. The server gives an AI coding client a controlled set of tools: discover platform schemas, open an isolated development session, edit and preview a React module, read build failures, run specialist validation agents, and open a pull request. I did not write any of the applications.

Hardest problem

Keeping generated code grounded. The model only sees the schemas and files the tools expose, so the server decides what "correct" looks like for every module it helps build.

What reached production

Every Canvas module so far was built by a product owner, not an engineer. agency-roster and roster-connect help three insurance agencies manage producer rosters, reporting structures, licenses, and appointments. An IT helpdesk module for agency IT teams is in development the same way.

Controls

Generated code does not publish itself. Schema checks, isolated worktrees, build and test gates, human-reviewed pull requests, tenant enablement, and normal deployment controls stay in the release path.

Built with: C# · .NET 10 · ASP.NET Core · MCP · React · TypeScript · Nx · Vite · GraphQL · OData · git worktrees · Azure DevOps

Platform modernization

Decomposing a tightly coupled monolith into 25+ independently scalable services

Constraint: The platform had been built rapidly across multiple contractor teams, leaving blurred domain boundaries and a heavily shared database. Policy workflows reached directly into tasks, clients, and other domains; join-heavy queries crossed many tables, increased lock contention, and forced unrelated workloads to share the same scaling limits.

25+independently deployable services
~50standardized build pipelines
Independentdata and compute scaling

Work

I led the incremental decomposition of the application into services on AKS. We extracted one domain at a time, moved its behavior and data behind explicit APIs and events, and kept existing clients and tenant-specific deployments working throughout the transition.

Architectural decision

Each extracted service owns its data and runtime capacity. High-demand workloads can scale horizontally without scaling the entire platform, and their databases can be tuned and expanded independently instead of competing inside one shared schema.

Control strategy

Compatibility harnesses, feature flags, staged deployments, ordered runbooks, and explicit rollback plans made each extraction reversible. We could improve one boundary at a time without depending on a big-bang migration.

Result

Each extraction removes another source of cross-domain querying and shared-database contention. The platform now distributes load across more than 25 independently deployable services, with clearer ownership and finer control over application and database scaling.

Built with: C# · .NET · GraphQL · OData · AKS · Service Bus · SQL Server · Redis · Cosmos DB · Helm · Azure DevOps

Authorization and search

One access model across five services and more than two million documents

Constraint: Permission checks ran as recursive SQL behind a fragile cache. Changes took too long to show up, and the search index had to be kept in sync separately.

5 servicesshared access model
2M+indexed documents
Immediatepermission updates

Work

I replaced repeated recursive queries with an in-memory relationship graph and incrementally maintained access tables. The same relationships govern transactional services and document-level search filters.

Architectural decision

Do the graph traversal once, when a relationship changes, instead of on every request. Events carry each change to the access tables and the search filters, so both stay aligned with the source.

Result

Permission changes take effect immediately, and search applies the same authorization model as the source services.

Built with: C# · .NET · SQL Server · Azure Service Bus · Azure AI Search · Redis · GraphQL · relationship graphs

How I work

Build enough to find the truth

01 / Make it concrete

Build the risky path first

A running proof of concept exposes assumptions faster than an architecture deck. I test the uncertain boundary before asking a team to commit to it.

02 / Control the transition

Make change reversible

For work that crosses services, I define compatibility requirements, deployment order, failure cases, feature flags, and rollback steps before release.

03 / Create leverage

Hand off working patterns

I leave teams with production code, tests, documentation, and conventions they can reuse—not a diagram that requires me in every follow-up meeting.

Capabilities

The problems I keep returning to

Tools change. These problems don't.

Service and API design

Shape durable boundaries

Design services and contracts that can evolve without forcing every consumer to move at once.

C# · .NET · ASP.NET Core · GraphQL · OData · REST

Distributed data systems

Design for partial failure

Build asynchronous workflows that recover, preserve tenant boundaries, and explain what happened across services.

Service Bus · SQL Server · Redis · Cosmos DB · Blob Storage

Applied AI

Keep models grounded and bounded

Give models inspectable tools and real schemas, with validation and human review between generated output and production.

Azure OpenAI · Semantic Kernel · MCP · RAG · hybrid search

Modernization and delivery

Move production systems safely

Use compatibility tests, deployment sequencing, observability, and rollback plans to replace systems in controlled steps.

Azure · AKS · Kubernetes · Docker · Helm · Azure DevOps

Engineering enablement

Turn decisions into reusable practice

Prove architecture through reference implementations, test strategies, review standards, and tooling teams can carry forward.

React · TypeScript · Nx · Playwright · Vitest · xUnit

Experience

Where I've worked

2022—Present

VP, Product Architecture

Fieldtech Software

Hands-on architect for a multi-tenant insurance platform. I own the difficult platform changes, build the first implementation, review critical work, and help teams take over the resulting systems.

2016—2022

Director of Application Engineering · Senior Software Engineer · Application Support Developer

NFP

I moved from production support into architecture and engineering leadership. I helped start the platform’s .NET API and React client, then built the early multi-tenancy, identity, authorization, and search layers and its first CI/CD.

2007—2014

Captain, Field Artillery

United States Army

Led a 44-person Paladin howitzer platoon and a nine-person fire-support team. Deployed to Iraq in 2009–2010 and received the Bronze Star Medal.

Read the full résumé

Education

California State University, Bakersfield

Bachelor of Arts in English Literature · 2006

Contact

If the work is technically messy, I’m interested

I’m exploring principal and staff-level engineering work involving platform architecture, distributed systems, applied AI, or modernization that cannot be solved with a clean rewrite.

View LinkedIn Download résumé
Email
peter@fuller.dev
LinkedIn
linkedin.com/in/ptfuller/
Location
Pflugerville, Texas
Website
fuller.dev