Start a conversation
Capabilities

What Ingot Solutions does.

Four capability areas that overlap on purpose. Most engagements need at least two of them, and handing the seams between vendors is where projects fail.

01

Custom software development

Applications built to fit how your business actually runs, instead of reshaping the business around a product that nearly fits.

Most organizations reach a point where the off-the-shelf tool costs more in workarounds than it saves in licence fees. Three people maintain a shadow spreadsheet, an export gets re-keyed every Friday, and a process that should take four minutes takes forty. That is the point where a purpose-built tool pays for itself quickly. The judgment worth paying for is knowing which parts to build, which to assemble from capability you already own, and what order to do them in.

When it is worth building, it gets built small first. A working slice in front of real users beats a complete specification every time, because the specification is always wrong in ways nobody can see until someone tries to use it.

  • Line-of-business web applications

    React and TypeScript front ends over Node, Python or .NET services.

  • APIs and system integrations

    Making systems that were never designed to talk to each other do so reliably, including the failure cases.

  • Browser extensions and Office add-ins

    Manifest V3 extensions and Office.js add-ins, including the packaging and managed-deployment path.

  • SharePoint Framework web parts

    Properly built SPFx components that respect tenant permissions and degrade gracefully.

  • Modernization of existing systems

    Taking something that works but cannot be maintained and making it maintainable, incrementally.

02

Azure & cloud architecture

Right-sized Azure architecture from a Microsoft Cloud Partner who will tell you when the free tier is the correct answer.

Cloud architecture goes wrong in two directions. Over-engineering is the famous one: Kubernetes for an application with forty users, a microservice mesh where three functions would do. Under-engineering is quieter and more common — one virtual machine that somebody RDPs into, no pipeline, no backups anyone has tested, and a single person who knows how it was set up.

The right answer is almost always smaller than a consultancy would like to sell you. Several systems described in the case studies run on the Static Web Apps free tier and cost nothing to operate. That is a feature of the design, not a compromise in it.

  • Azure Static Web Apps, Functions and Container Apps

    Choosing the right one, which mostly means choosing the simplest one that fits the workload.

  • Entra ID and Microsoft Graph

    App registrations, scoped permissions, and authentication that uses the identity your organization already has.

  • CI/CD with GitHub Actions

    Deployment as a routine event rather than a Friday-night operation.

  • Cost review and simplification

    Reading the bill line by line and removing what is not earning its place.

  • Migration from on-premises and legacy hosting

    Moving workloads without a big-bang cutover.

03

AI & automation

AI features built the careful way: credentials server-side, output structured and validated, grounded in your own content, human review where the stakes justify it.

Two products and several client systems in, the pattern that works is consistent. Use the model for the judgment that genuinely requires judgment, and use ordinary deterministic code for everything else — it is cheaper, faster and testable. Ground the model in documents your organization has already reviewed rather than asking it to invent from nothing. Keep the API credential on a server that users cannot read. And where the output carries real consequence, ship it as a draft for a person to approve, and say so in the interface.

The failure mode to design against is not the model being wrong. It is the model being confidently plausible in a workflow that has no review step left in it.

  • Document drafting and extraction

    Generating content into your real controlled templates; pulling structured data out of unstructured PDFs.

  • Retrieval over your existing content

    Grounding output in your own SharePoint, document libraries and historical records.

  • MCP connectors to internal systems

    Letting an AI assistant query your live systems under real permissions, with no data copied anywhere.

  • Workflow automation

    Power Automate, Azure Functions and scheduled jobs that remove recurring manual steps.

  • AI feasibility review

    An honest assessment of whether a proposed AI use case will work, before budget is committed to it.

04

Microsoft 365 & governance

Making the platform you already pay for do more, and making it defensible when someone asks how it is controlled.

Nearly every organization is paying for more Microsoft 365 capability than it uses, and carrying more risk in it than it realizes. Storage quietly fills with a decade of file versions. Sensitive documents move around with no controls. Permissions accumulate until nobody can say who can see what.

This work is usually less about deploying technology and more about producing evidence and handover material — the tool that turns an argument into a number, and the runbook that lets the internal team keep operating it after the engagement ends.

  • Tenant storage analysis and remediation

    Finding where the space actually went, by site, library, file type and version history.

  • Microsoft Purview DLP

    Policy design, scoping and tuning so alerts stay meaningful enough to be acted on.

  • SharePoint architecture and modernization

    Site structure, permissions and provisioning that hold up as the organization grows.

  • Power BI and reporting integration

    Getting operational data in front of the people who make decisions with it.

  • Runbooks and executive briefing

    Documentation written for the person who inherits the system, and for the leadership team funding it.

Engagement models

Four ways to work together.

Pricing is quoted per engagement, not per hour of guesswork. If a project is not a good fit, you will hear that on the first call rather than after a proposal.

Fixed-scope build

A defined system, a fixed price and a delivery date. Scope is agreed in writing before work starts and changes are quoted separately rather than absorbed silently.

Best when you know what you need built.

Discovery sprint

One to two weeks to turn a vague problem into a specification, an architecture and a costed plan — with a working prototype where that is the fastest way to settle a question.

Best when the problem is clear but the solution is not.

Ongoing retainer

A recurring block of hours for maintenance, enhancement and being on the other end of the phone when something needs attention.

Best after a build, or where there is a steady flow of small work.

Technical advisory

Architecture review, build-versus-buy assessment, second opinion on a vendor proposal, or an AI feasibility check before budget is committed.

Best when the decision matters more than the code.

Questions

What people ask first.

How do you price work?

Per engagement, not per hour of guesswork. Where the scope is knowable it is quoted as a fixed number against a delivery date, because open-ended hourly billing puts the risk of my estimating errors onto you. Where the scope genuinely is not knowable yet, you get a capped discovery phase first so that it becomes knowable, and you own that specification whether or not you proceed.

What size of project do you take on?

Anything from a few days of advisory work to a multi-month build. The smallest useful thing gets built first regardless of the total size, because specifications are always wrong somewhere and the cheapest place to find that out is week one on something real.

Do you need access to our Microsoft 365 tenant?

Usually yes, and always at the narrowest permission that does the job — read-only where read-only suffices. Permissions are declared explicitly so your administrators approve them consciously in the admin centre rather than discovering them later. Your tenant admin should never be surprised by what a tool I built can reach.

Who owns the code at the end?

You do. Source lives in your GitHub organization, pipelines run without me, secrets sit in your key vault, and documentation is written for whoever inherits it. Work that only functions while I am attached to it is not finished work.

Will you have access to our passwords or API keys?

No, and I do not want them. 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.

Do you work on site or remotely?

Based in Calgary and working with clients across Canada. Most of the work is remote, which is what makes a fixed price sensible. On-site time for workshops, discovery or handover is arranged where it genuinely helps.

What if we already have developers?

That is common and often the better arrangement. Engagements frequently look like architecture review, a second opinion on a vendor proposal, an AI feasibility check before budget is committed, or building the one component your team does not have the specific platform experience for.

No obligation

Not sure which of these you need?

That is a normal place to start. Describe the problem in plain language and I will tell you which capability it actually needs, and how I would approach it.

Start a conversation See the work