The long version of the About page: how the arc went, what the work looks like day to day, and what I hold to when building systems.
A BA in environmental studies from Prescott College first, then remote sensing and GIS: satellite imagery and parcel maps as the raw material for decisions about land, water, and who owns what.
Analysis turned into building across two county assessor's offices, where parcel and land-records work became .NET engineering. At Yavapai County it started with ArcObjects add-ins in 2008. At Archuleta County, where the assessor's office also held all of the county's GIS data, I built and maintained the two public sites people outside the building actually used: a county web mapping application with the assessor's parcel data on it, and an assessor records website. Both were full-stack builds: .NET with ASP.NET and C#/VB.NET, SQL Server, JavaScript, and API work, with HTML, CSS, and Bootstrap on the front end, and the mapping application on the ArcGIS JavaScript API over ArcSDE and PostgreSQL. I did some Python scripting there as well, and the MCPD in 2012 certified the .NET side.
I started working for the Southern Ute Indian Tribe in 2014 as a GIS analyst and .NET developer, building the Land Management System for the Tribe's Department of Energy: the C#/.NET tooling landmen use to query and edit oil-and-gas lease records inside the enterprise content system, and running the GitHub Enterprise Server behind it. The work widened into SQL Server, .NET, JavaScript, and the APIs holding it together, and in 2018 into Southern Ute Shared Services as an architect. That is where it became platform work as much as application work: Azure applications and APIs, SharePoint Online on the far side of the ECM migration, the Power Platform estate to administer and govern, the standards and reusable patterns projects start from, and now the AI practice on top of all of it.
One thread runs through all of it: data integration and API work, which started at Archuleta County and grew at Southern Ute. It meant evaluating and interrogating APIs and building integrations with GIS and non-GIS systems, from SOAP services early on to REST, and later working with the GitHub REST and GraphQL APIs among many others. Each step added a layer without dropping the one underneath, and that is still the habit: the person who understands the data, the infrastructure, and the code ships systems that hold up.
Southern Ute Shared Services supports tribal government, oil and gas, private equity, legal, and court case management. I design, build, deploy, and maintain a portfolio of production cloud applications there, on Azure App Services, Function Apps, and B2C behind Front Door, with SQL Server and GitHub Actions. That includes REST APIs built as Azure Functions and .NET Minimal APIs, secured by JWT and Microsoft Identity, with observability in Application Insights. It also means owning the migrations nobody wants to touch: legacy modernization is most of what an architecture role actually looks like here.
Identity and access runs through all of it as its own thread: Azure B2C and Microsoft Identity behind the applications, MSAL on the front ends, JWT on the APIs, and the standards that keep the next service using the same patterns instead of inventing its own.
Python carries a large share of that work. I build production data pipelines in Python with pandas, SQLAlchemy, and ArcPy, alongside .NET, using API calls to extract data from the many products used across the Tribe. Real-time integrations and scheduled ETL workflows automate critical business processes and standardize data flow and reporting across platforms, and they are built with structured logging and correlation IDs, so a failure can be traced end to end instead of guessed at.
SQL Server sits under most of it. I design the schemas, views, and stored procedures these applications and pipelines run on, and I do the query performance work when a report or a nightly job starts dragging. Architecture decisions that ignore the shape of the data get paid for later, at the database, usually by somebody else.
The Microsoft Power Platform is mine to run as well: administering the environments, managing the on-premises data gateways, setting DLP policies, governing connectors and tenant-wide settings, and building the line-of-business Power Apps and 25+ Power Automate flows that sit on top of them. Governing a platform other people build on is a different problem from building an application, and it is the one that keeps a citizen-developer estate from turning into a shadow IT estate.
Power Gateway came out of that: a JavaScript application on MSAL.js that unifies discovery and launching of Power Apps and Power Automate flows across environments, pulling from several API sources, running in an isolated App Service Environment, shipped by GitHub Actions through a self-hosted runner, with unit and integration tests. I was the only engineer on it, AI-assisted throughout, which is the same practice I ask the rest of the engineering team to work inside.
GIS is still current work, not just the route in. An ArcGIS Online integration links hosted feature services to oil and gas asset records, cutting the manual entry that used to keep them in sync. A real-time utilities outage notification system was prototyped in Experience Builder and Power Automate. Custom mapping web apps and reusable widgets put self-service maps in front of internal users instead of routing every question through me.
A lot of the work sits upstream of code. I own the architecture itself: current state, target state, and the transitional steps in between, tied to where the business is actually going, along with the decision records, the API and authentication standards, and the reusable patterns that make the next project cheaper than the last one. A decision record that lists only the upside is marketing, so the risks go in it too, each one with the mitigation next to it. Some of that work is a diagram for executives, some of it is a code review with a developer, and some of it is getting a team to agree on how they will actually work.
I run initiatives end to end: engaging the customer, discovering what they actually need behind what they asked for, running buy-versus-build analysis with real level-of-effort numbers, evaluating and selecting vendors, then implementing and project-managing the result from proof of concept to something the business can run without me. That is IT leadership more than it is coding.
A good part of it is making other people faster: mentoring through design reviews, code reviews, and pair programming, on system design, code quality, and testing discipline, and building the templated build systems and documentation that let other developers extend the tooling themselves rather than queue behind me. The measure of the work is whether it still runs when I am not the one running it.
I help set the organization's AI vision and strategy, and I handle the half that decides whether any of it lands: awareness, training, and governance. I rolled out GitHub Copilot across the engineering team, along with the wider productivity tooling, and I build the AI-assisted engineering practice our engineers work inside. I also build the proofs of concept, including agentic AI that reasons over our enterprise document repositories.
The technology is new; the process of getting an organization to adopt something is not. It is the same process I would run for anything else.
I'm focused on where AI meets real engineering: intelligent document processing, RAG pipelines, and AI built into the workflows teams already use. But the AI is the newest part of a longer list:
AI-assisted engineering sits inside that list, not above it. What it unlocks is systems built by far fewer people in far less time, which changes which ideas are worth starting at all. None of it holds without the discipline behind it and a human in the loop: constraining agents so their output is something you would sign your name to, and encoding each catch so the next session starts smarter. Wherever AI lands, an answer has to cite something a person can go and read, and the worst anyone can get out of attacking it should be a wrong answer, not changed data.
I focus on outcomes. If it works, scales, and supports the people using it, that's a success.
Languages: C# / .NET 8–10, Python (FastAPI, pandas, SQLAlchemy), JavaScript/React, T-SQL
AI & ML: RAG architecture, embeddings, agentic workflows, Copilot Studio, TensorFlow, vLLM, QLoRA fine-tuning
Geospatial: Sentinel-1/2 and Landsat pipelines via STAC, rasterio, GeoPandas, geospatial ML (Random Forest, spatial cross-validation, NDVI phenology, change detection), PostGIS, MapLibre GL, ArcGIS platform
Data: SQL Server, PostgreSQL, Qdrant, Redis, Entity Framework, Dapper, ETL/ELT
Cloud & DevOps: Azure (App Service, Functions, Front Door, B2C, Application Insights), GitHub Actions, Docker, .NET Aspire
Practices: TDD, integration testing, observability (tracing, structured logging, correlation), AI-assisted engineering (Claude Code, GitHub Copilot)