Build a solution
Define what the platform cannot do, build it on SharePoint Framework, Azure Functions or an integration, and hand it over with its tests.
- A working solution
- Tests and documentation
- A handover to your team
When the platform does not do what the work needs, build the missing piece. Matt designs and develops SharePoint Framework solutions, Azure Functions and integrations, with Claude Code and Codex working under tests and human review.
See how it is built
Connect Microsoft 365 to the systems the business already runs, through APIs, Azure Functions and custom connectors. Give each integration an identity with only the access its job requires, and an owner who knows it exists.
Claude Code, Codex and GitHub Copilot can contribute changes to a repository. The repository keeps the work available for inspection and further development.
Each tool still needs its own instructions, access and checks. A shared destination does not make their behaviour identical.
Move repository changes through tests that address the intended behaviour. Useful tests give the team evidence about what the change actually does.
Carry lessons from failures into the next iteration. A passing test result supports review but does not make the whole release decision.
Human review checks whether the change serves its purpose and fits the surrounding system. It is a distinct decision after the automated checks.
Give the reviewer enough context to assess the result. That includes what changed, what was checked and what remains uncertain.
Governed access defines who and what can act on the repository. Keep that responsibility explicit as the next iteration begins.
Check the authority for the next action before work continues. Permission to propose or test a change does not automatically include permission to release it.
Coding tools, a repository, tests, human review and governed access form a repeatable delivery pattern. Each contributes a different part of the control.
Use failures and review findings to improve the shared way of working. The next change should benefit from what the team has already learned.
Claude Code, Codex and GitHub Copilot can contribute changes to a repository. The repository keeps the work available for inspection and further development.
Each tool still needs its own instructions, access and checks. A shared destination does not make their behaviour identical.
Move repository changes through tests that address the intended behaviour. Useful tests give the team evidence about what the change actually does.
Carry lessons from failures into the next iteration. A passing test result supports review but does not make the whole release decision.
Human review checks whether the change serves its purpose and fits the surrounding system. It is a distinct decision after the automated checks.
Give the reviewer enough context to assess the result. That includes what changed, what was checked and what remains uncertain.
Governed access defines who and what can act on the repository. Keep that responsibility explicit as the next iteration begins.
Check the authority for the next action before work continues. Permission to propose or test a change does not automatically include permission to release it.
Coding tools, a repository, tests, human review and governed access form a repeatable delivery pattern. Each contributes a different part of the control.
Use failures and review findings to improve the shared way of working. The next change should benefit from what the team has already learned.
Matt builds with Claude Code, Codex and GitHub Copilot. The code lives in a repository, passes tests and gets human review before release. The agents speed up the work; the tests and the review decide what ships.
Set the development scope for Claude Code, Codex and GitHub Copilot around the work they may perform. The organization still owns the decisions about code, data and release.
Configure and test the controls each tool supports. Shared policy intent needs separate checks wherever identities, permissions or execution environments differ.
Access controls determine who and what can reach the repository. Assign access around the work that each person or tool needs to perform.
Review those assignments as the team and workflow change. Agent-assisted development still needs a clear owner for access decisions.
Data controls define the information available to development work. Consider that scope alongside repository access.
Make the rules understandable to the people maintaining the workflow. Controls need to be configured and checked in the tools that enforce them.
Repository changes proceed to human review. That decision considers the result in the context of the task and its access and data boundaries.
Retain useful review findings with the working method. They help the next iteration address the same responsibility more clearly.
Tool choice, repository access, data scope and human review belong to the same delivery process. None of them removes the need for the others.
Start with explicit responsibilities and verify the controls in the actual environment. Expand the workflow only with a clear understanding of what those controls cover.
Set the development scope for Claude Code, Codex and GitHub Copilot around the work they may perform. The organization still owns the decisions about code, data and release.
Configure and test the controls each tool supports. Shared policy intent needs separate checks wherever identities, permissions or execution environments differ.
Access controls determine who and what can reach the repository. Assign access around the work that each person or tool needs to perform.
Review those assignments as the team and workflow change. Agent-assisted development still needs a clear owner for access decisions.
Data controls define the information available to development work. Consider that scope alongside repository access.
Make the rules understandable to the people maintaining the workflow. Controls need to be configured and checked in the tools that enforce them.
Repository changes proceed to human review. That decision considers the result in the context of the task and its access and data boundaries.
Retain useful review findings with the working method. They help the next iteration address the same responsibility more clearly.
Tool choice, repository access, data scope and human review belong to the same delivery process. None of them removes the need for the others.
Start with explicit responsibilities and verify the controls in the actual environment. Expand the workflow only with a clear understanding of what those controls cover.
Decide which repositories, credentials and environments coding agents may use, and which of their actions need review. The same controls apply to the people and the agents working on the code.
Older custom code often blocks a move to the cloud. Find out what it does, then package and validate the replacement before deployment, with AI assisting and a person deciding the release.
For a law firm, Matt converted 10 C# web parts and 3 web-service applications into SharePoint Framework and Azure Functions. For a national insurer, a purpose-built transpiler moved a website between platforms in two weeks with no specialist needed.
Discovery gives planning a grounded picture of the migration. Identify the work and its dependencies before choosing the delivery approach.
AI can assist with that preparation. People remain responsible for judging whether the plan fits the systems and the business.
Estimates turn the proposed work into a basis for scheduling and decisions. Keep their assumptions connected to what discovery has established.
AI assistance can help organize the material. An estimate still needs review when the scope or understanding changes.
Packaging prepares the migration work for a controlled delivery. It gives validation something specific to examine.
Keep the package aligned with the plan and its assumptions. Preparation is useful when another person can understand what is intended to run.
Validation checks the prepared work before deployment. Its result gives the responsible person evidence for the next decision.
Keep that decision explicit. AI assistance supports the work, while a person decides whether the proposed deployment is ready.
The human decision gates deployment in this pattern. Proceed on the basis of the validated work and the agreed scope.
Keep responsibility visible during the change. A working deployment still needs the handover that lets others understand and operate it.
Handover carries the result of delivery into ongoing use. The receiving team needs to understand the system and the decisions that shaped it.
Keep useful knowledge available after the migration task closes. That continuity supports the next piece of work.
Discovery, planning, estimates, packaging, validation, deployment and handover form one delivery path. AI assists across the work while the deployment decision remains human.
Judge the approach by the evidence for the actual migration. The diagram describes a working pattern without promising a particular duration or saving.
Discovery gives planning a grounded picture of the migration. Identify the work and its dependencies before choosing the delivery approach.
AI can assist with that preparation. People remain responsible for judging whether the plan fits the systems and the business.
Estimates turn the proposed work into a basis for scheduling and decisions. Keep their assumptions connected to what discovery has established.
AI assistance can help organize the material. An estimate still needs review when the scope or understanding changes.
Packaging prepares the migration work for a controlled delivery. It gives validation something specific to examine.
Keep the package aligned with the plan and its assumptions. Preparation is useful when another person can understand what is intended to run.
Validation checks the prepared work before deployment. Its result gives the responsible person evidence for the next decision.
Keep that decision explicit. AI assistance supports the work, while a person decides whether the proposed deployment is ready.
The human decision gates deployment in this pattern. Proceed on the basis of the validated work and the agreed scope.
Keep responsibility visible during the change. A working deployment still needs the handover that lets others understand and operate it.
Handover carries the result of delivery into ongoing use. The receiving team needs to understand the system and the decisions that shaped it.
Keep useful knowledge available after the migration task closes. That continuity supports the next piece of work.
Discovery, planning, estimates, packaging, validation, deployment and handover form one delivery path. AI assists across the work while the deployment decision remains human.
Judge the approach by the evidence for the actual migration. The diagram describes a working pattern without promising a particular duration or saving.
Bring the gap the platform does not fill, or the old code holding back a move. We scope the smallest build that closes it.
Define what the platform cannot do, build it on SharePoint Framework, Azure Functions or an integration, and hand it over with its tests.
Find out what older custom code does, plan its replacement, and move it to SharePoint Framework or Azure with validation before each release.
Software your team can run and change.
Matt designs and develops in TypeScript, React and C#, on SharePoint Framework and Azure, and builds this website with Claude Code and Codex.
Start with what the platform cannot do for you today.