What I do - Everything between your code and your customers
Software development consulting, specializing in cloud-native .NET on Azure. The work covers the application, the infrastructure under it, and the pipeline that ships it, because splitting those across separate hires is how a project acquires a coordination problem you then have to manage.
Every engagement is quoted. Scope varies too much for a price list, and the only figure a list can honestly carry is the smallest job on it.
Azure infrastructure you can reproduce
Most cloud accounts were clicked together once, by somebody who has since moved on. Nobody can say what is running, who has access, or why the bill is what it is, and the test environment stopped matching production a year ago. I describe the infrastructure in Terraform, so an environment is something you can create again rather than something you are afraid to touch. Networking, databases, secrets in Key Vault, access controls, and the cost of each of it written down. The accounts are yours throughout, and so is the code that builds them.
A build and release you can undo
Releasing by hand from somebody's laptop is fine until the night it is not. I build the pipeline in Azure DevOps: the application builds on every change, the tests run, and a release goes out the same way every time and can be put back. Where that means untangling a deployment nobody documented, that is part of the work rather than a prerequisite for it.
How a deployment is delivered →Someone who runs it after it is live
Production is a job, not an event. Monitoring that tells you something is wrong before a customer does, a bill somebody reads each month, dependencies kept current, and a person to call when it breaks. This can be an engagement of its own or the tail of one, and it is the part small teams most often discover they need after the fact.
A codebase that has outgrown whoever built it
Whether the first version came from an AI coding tool or from a developer who has since left, the arc is the same: the code becomes bigger than anyone holds in view, and changes start breaking things nobody can see. You recognize it when a change works locally but will not go live, or a fix quietly breaks something else. That is not a reason to start over. I take over the code you already have, make it safe to change again, and build from there.
Why this happens, and what you can do about it →New builds and new features in C# and .NET
Something built from scratch, or a list of things an application you already have still needs to do. I learn how your code fits together and build the way the rest of it is built, so what I add reads like part of the app rather than something bolted to the side. Written to be handed back: documented, tested, and in your repository.
Framework upgrades, and mobile in .NET MAUI
Software ages. The versions underneath stop getting security fixes, and a rewrite is rarely the right answer. I upgrade older code in steps, so you end on supported foundations without one risky weekend. For mobile, one project that runs on both iPhone and Android rather than two builds to pay for and keep in step. I built and published UnityPay, which connects to real bank accounts, and Albie, a golf swing analysis app.
See UnityPay →Where this helps
- Nobody owns the infrastructure. The application is somebody’s job. The cloud account, the pipeline and the release are nobody’s.
- Releasing is manual and somebody dreads it. It goes out by hand, at night, and there is no way to put it back.
- Environments that have drifted apart. Test stopped matching production, so what passes there says nothing about what will happen live.
- Something new built from scratch. A site or an app you need built, taken from scoping to live.
- A feature you need built. Something your app still needs to do, built into the app you already have.
- An outdated framework or dependencies. Older code brought up to current, supported versions, safely and in steps.
- Code a previous developer left behind. An app you inherited, taken on and moved forward.
- Code that's hard to change. Tangled or fragile code reorganized, without changing what it does, so it is safe to build on again.
- Someone who stays with it. An app that needs someone reliable for ongoing changes and fixes as your business grows.
Built on .NET, comfortable across the rest
My core stack is C# and .NET, the same foundation a lot of business software is already built on, with .NET MAUI for cross-platform mobile. I also work across the rest of the stack: TypeScript and React on the front end, Node.js and Express for APIs, SQL Server and Postgres for data. And when the work is getting your app deployed, secured, and kept running, the language it’s written in matters far less. I take on apps built in just about any stack and get them live on infrastructure you own.
Every engagement is different, so this work is quoted rather than listed. It starts with a paid first milestone that produces a written plan — what has to happen, what it will cost to run, and how long it takes — and the rest is priced off what that found. Quoting the whole of a job before reading the code or the cloud account is how a fixed fee turns into an argument halfway through.
Twenty minutes, and nothing to prepare.
Tell me what you need built or fixed, and I'll tell you where I'd start.