An ingot is refined material, ready to be made into something useful. The point of an engagement is to leave you holding something solid that you own outright.
You describe the problem in your own words. I ask what you have tried, what it costs you today, and what happens if nothing changes. By the end of it you should have a clear view of how it would be built — the shape of the solution, the likely sequence, and where the risk actually sits. That view is yours to keep and act on however you like.
The problem becomes a written specification: what gets built, what explicitly does not, the architecture, the assumptions it depends on, and a fixed price against a date. Where a question cannot be settled on paper, it gets settled with a prototype rather than an argument. You own this document whether or not you proceed.
Work lands in your repository from the first week, with a running deployment you can open. No four-week silence followed by a reveal. Where a decision turns out differently than the specification assumed, you hear about it when it happens, not in the final invoice.
Source in your GitHub organization, pipelines that run without me, secrets in your key vault, and documentation written for whoever inherits it. Plus the unglamorous part: how to redeploy, what breaks first, and what to check when it does.
Some clients keep a monthly block of hours for changes and improvements. Some take the code and never call again. Both are fine outcomes — a build that requires me permanently in order to keep working was not finished properly. Day-to-day IT support is a different craft to building, and where you need it I will introduce you to people who are genuinely good at it.
These are on the website because they are easier to keep when they are written down somewhere a client can point at.
You get a recommendation on approach before anyone mentions a contract: what to build, what to assemble from capability you already own, what order to do it in, and where the risk sits. That advice stands on its own — it is worth having whether or not I am the one who implements it.
I do not want custody of your API keys, tenant credentials or passwords. Configuration ships as templates with blank fields for you to populate in your own key vault or app settings. Nothing sensitive goes into a repository, ever.
Open-ended hourly billing puts the risk of my estimating errors onto you. Where scope is knowable, it is priced as a fixed number. Where it genuinely is not, you get a capped discovery phase first so it becomes knowable.
Applications request the narrowest permission that does the job, declared explicitly so your administrators approve them consciously. Read-only where read-only suffices. Your tenant admin should never be surprised by what a tool I built can reach.
Proposals, status and documentation are written to be read by whoever has to make the decision, not to sound impressive. If a document needs me present to explain it, it is a bad document.
Work happens in sessions we book, and every active build has a standing weekly checkpoint. Email gets a reply within two business days. There is no on-call arrangement and no phone queue — attention that is always available is attention that is always divided, and you get a better answer from someone who sat down to think about it than from someone replying between two other things.
The smallest thing that proves the idea gets built first. Specifications are always wrong somewhere, and the cheapest place to discover that is in week one on something real rather than in month three on something finished.
Bring the problem, not a requirements document. Forty minutes is usually enough to know whether there is something here worth building.