{
  "_README": "Every FACT and NUMBER here comes from Mihir's CV (Aug 2026): 300k+ Azure SQL databases, 50% release cycle reduction, 55% automation coverage, SOC 2 and ISO 27001, Intune and MDM, the .NET Core and Blazor migration. Describe the functions led, never the headcount. The surrounding NARRATIVE (the problem framing and the reasoning) is written prose, not quoted from the CV, so read it and make it sound like you. Nothing here is invented data. House style: no em dashes, and no '&' anywhere that renders in the display serif.",

  "projects": [
    {
      "slug": "leading-engineering",
      "title": "Leading the Engineering Function",
      "subtitle": "Several disciplines, one accountability",
      "category": "Leadership",
      "year": "2021-Present",
      "org": "nimbus Cloud",
      "featured": true,
      "monogram": "LE",
      "summary": "Lead software development, quality engineering and CloudOps as a single function, owning technology strategy, delivery roadmaps, technical debt and the operational risk that comes with running the platform.",
      "problem": [
        "Development, quality and operations are usually three separate teams with a queue between each pair. That is a structural problem rather than an effort problem, and no amount of goodwill fixes a design where one team is a mandatory dependency for everyone else's delivery.",
        "It shows up as the same symptoms every time: quality discovered late, operations treated as a ticket desk, and engineers who never see a change all the way through to production."
      ],
      "approach": [
        "I run them as one function with one accountability. Development, quality engineering and CloudOps are planned together and measured on the same outcomes, rather than on handovers between them.",
        "Quality engineers sit with delivery, not downstream of it, so the people who care most about testability are in the room when the design happens. CloudOps builds paved roads rather than processing requests, and the measure of their success is how rarely anyone needs them.",
        "Above that sits the part of the job that is not code: technology strategy developed with product management, roadmaps that survive contact with commercial reality, deliberate management of technical debt rather than the pretence that it does not exist, and vendor contracts negotiated so the tooling budget goes where the leverage is."
      ],
      "outcome": [
        "Delivery, quality and operations plan as one group, which removed the queues that used to set the pace.",
        "Technical debt and SLA performance are reported automatically and reviewed like any other business metric, so the trade-offs get made deliberately rather than by default."
      ],
      "tags": ["Team Leadership", "Technology Strategy", "Agile Delivery", "Technical Debt", "Vendor Negotiation"],
      "impact": [
        { "label": "Functions led",  "value": 4, "suffix": "",  "caption": "Development, QA, CloudOps and security operations" },
        { "label": "Years leading",  "value": 5, "suffix": "+", "caption": "Head of Engineering since 2021" }
      ],
      "links": []
    },
    {
      "slug": "soc2-iso27001",
      "title": "SOC 2 and ISO 27001",
      "subtitle": "Compliance as engineering work, not paperwork",
      "category": "Security and Compliance",
      "year": "2021-Present",
      "org": "nimbus Cloud",
      "featured": true,
      "monogram": "SC",
      "summary": "Contributed to achieving both SOC 2 and ISO 27001 certification, with a focus on risk management, and authored the IT policies and procedures that turned the controls into how the business actually operates.",
      "problem": [
        "Enterprise and government buyers ask hard questions about security posture, and a security questionnaire is not something you can talk your way through. Either the controls exist and you can evidence them, or the deal stalls.",
        "The trap with certification is treating it as a documentation exercise. You can write a policy that describes a control nobody performs, pass an audit, and be no safer than you were. That approach also has to be redone from scratch every cycle."
      ],
      "approach": [
        "I treated the control set as an engineering backlog rather than a compliance one. Where a control could be enforced by a system, we enforced it by a system, so the evidence is a by-product of the control working rather than a separate artefact somebody assembles before an audit.",
        "Authored the IT policies and procedures covering MDM, Intune and Group Policy so that operational consistency has a written definition and a technical enforcement point behind it.",
        "Risk management was the part that mattered most. Identifying what actually threatens the platform and the customer data in it, deciding deliberately what to mitigate and what to accept, and revisiting that on a cadence rather than annually under pressure."
      ],
      "outcome": [
        "Both SOC 2 and ISO 27001 certification achieved, with the underlying controls running as normal operations rather than as an audit-time scramble.",
        "Security questionnaires became a retrieval exercise instead of a fire drill, which matters commercially when enterprise deals depend on the turnaround."
      ],
      "tags": ["SOC 2", "ISO 27001", "Risk Management", "IT Policy", "Audit Readiness"],
      "impact": [
        { "label": "Certifications", "value": 2, "suffix": "", "caption": "SOC 2 and ISO 27001" }
      ],
      "links": []
    },
    {
      "slug": "azure-sql-automation",
      "title": "Automating 300,000 Databases",
      "subtitle": "Where manual operations stop being viable",
      "category": "Cloud and Platform",
      "year": "2019-2021",
      "org": "MYOB",
      "featured": false,
      "monogram": "DA",
      "summary": "Eliminated manual database operations across more than 300,000 Azure SQL databases using Azure Functions, and built the archival, replication and failover automation around them.",
      "problem": [
        "At a few hundred databases you can operate manually if you have to. At three hundred thousand you cannot, and every routine operation that still requires a person is both a cost and an outage waiting for the right Tuesday.",
        "Audit data was a related problem. It accumulated indefinitely in expensive transactional storage because there was no automated path to move it anywhere cheaper."
      ],
      "approach": [
        "Moved recurring database operations into Azure Functions, using time-based triggers for scheduled work and durable functions where an operation needed to coordinate steps and survive a restart part way through.",
        "Built archival in Azure Data Factory: SQL audit data migrated out to storage tables, and a process that automatically moves records older than three months into blob storage. That took the growth curve off the expensive tier without losing anything.",
        "Around that, the resilience work: Azure SQL deployed with geo-replication, standby sync and tested failover, alerting through Azure Monitor, and Application Insights integrated across cloud services so a problem surfaces as a signal rather than as a support ticket."
      ],
      "outcome": [
        "Routine operations across the estate run without human involvement, which is the only approach that holds at that database count.",
        "Storage costs came off the growth curve, and audit data retention became an automated policy rather than a periodic clean-up project."
      ],
      "tags": ["Azure Functions", "Azure SQL", "Data Factory", "Terraform", "Application Insights", "Geo-Replication"],
      "impact": [
        { "label": "Databases automated",  "value": 300, "suffix": "k+", "caption": "Manual operations eliminated" },
        { "label": "Archival window",      "value": 3,   "suffix": " mo", "caption": "Automated move to blob storage" }
      ],
      "links": []
    },
    {
      "slug": "endpoint-management",
      "title": "Endpoint and Identity Governance",
      "subtitle": "Policy with an enforcement point behind it",
      "category": "Identity and Endpoint",
      "year": "2021-Present",
      "org": "nimbus Cloud",
      "featured": false,
      "monogram": "EI",
      "summary": "Established device management on Microsoft Intune and authored the MDM and Group Policy standards behind it, so endpoint compliance is enforced and evidenced rather than assumed.",
      "problem": [
        "Device posture in most growing companies is a mix of manual builds, tribal knowledge and a spreadsheet that was accurate on the day someone last updated it. Simple questions, like which machines are missing a patch, take a morning to answer.",
        "That is an operational annoyance right up until it becomes a certification requirement and a commercial blocker, at which point it becomes urgent."
      ],
      "approach": [
        "Built the practice on Microsoft Intune, with the configuration standards written down as policy rather than living in someone's head. MDM, Intune configuration and Group Policy documented together so the intent and the enforcement match.",
        "The design principle was that a policy without a technical enforcement point is a suggestion. Compliance state needed to gate access to company resources, not just show a red indicator on a dashboard nobody opens.",
        "This work fed directly into the SOC 2 and ISO 27001 control set, which is the efficient way to do it. One piece of engineering satisfying an operational need and an audit requirement at the same time."
      ],
      "outcome": [
        "Endpoint configuration is consistent by default and provable on request, rather than reconstructed under audit pressure.",
        "The evidence it produces shortens enterprise security reviews instead of stalling them."
      ],
      "tags": ["Microsoft Intune", "MDM", "Group Policy", "Active Directory", "Microsoft 365"],
      "impact": [],
      "links": []
    },
    {
      "slug": "release-cycle",
      "title": "Halving the Release Cycle",
      "subtitle": "Automated coverage as the thing that sets the pace",
      "category": "Quality Engineering",
      "year": "2016-2019",
      "org": "Ploytech",
      "featured": false,
      "monogram": "RC",
      "summary": "Built automated testing frameworks on Jenkins and Test Studio that cut release cycles by 50% while holding the quality bar, having first taken the organisation from ad hoc testing to over 55% automated coverage.",
      "problem": [
        "Testing sat at the end of the process, so it worked as a gate rather than as a feedback loop. The manual regression pass was the single thing setting how often the business could ship, and every release it got a little longer.",
        "The usual response to that pressure is to test less, which trades a visible delay for an invisible risk. That was not an acceptable answer."
      ],
      "approach": [
        "Started with coverage, because you cannot shorten a cycle you cannot trust. Built a C# testing framework from scratch, wrote regression suites in Telerik Test Studio, and used JMeter for load and performance, taking automated coverage past 55%.",
        "Introduced Jenkins for continuous integration and automated deployment so that coverage actually ran on every change rather than on request. Automation nobody triggers is just unmaintained code.",
        "Alongside the tooling, introduced Agile practice properly: Jira, Confluence and Service Desk, real backlog management, sprint planning, sizing, standups, reviews and retrospectives. The process change and the automation change only work together."
      ],
      "outcome": [
        "Release cycles halved, with the quality bar held rather than traded away.",
        "Regression moved from a scheduled event to something that happens continuously, which took the ceiling off how often we could ship."
      ],
      "tags": ["Test Automation", "Jenkins", "Telerik Test Studio", "JMeter", "C#", "Agile"],
      "impact": [
        { "label": "Release cycle time",  "value": 50, "prefix": "-", "suffix": "%", "caption": "Without lowering the quality bar" },
        { "label": "Automated coverage",  "value": 55, "suffix": "%+", "caption": "Up from ad hoc manual testing" }
      ],
      "links": []
    },
    {
      "slug": "infrastructure-as-code",
      "title": "Infrastructure as Code",
      "subtitle": "A platform you can rebuild from a repository",
      "category": "Cloud and Platform",
      "year": "2021-Present",
      "org": "nimbus Cloud",
      "featured": false,
      "monogram": "IC",
      "summary": "Moved cloud infrastructure into version-controlled code with ARM templates, Terraform, Python and PowerShell, automated deployment on top of it, and added the monitoring and SLA reporting that makes the platform legible.",
      "problem": [
        "Infrastructure that exists only in a portal is infrastructure nobody can review, reproduce or reason about. It drifts quietly, and the only person who understands the current state is whoever touched it last.",
        "The same gap existed in reporting. SLA performance and technical debt were discussed on the basis of impressions, because nothing produced the numbers on a regular cadence."
      ],
      "approach": [
        "Defined the environment as code using ARM templates and Terraform, with Python and PowerShell for the automation around them, so provisioning is reviewable in a pull request and repeatable rather than remembered.",
        "Automated cloud deployment on top of that foundation, which is the point where infrastructure as code starts paying back: the same definition produces the same environment every time, so a rebuild is a routine operation rather than an incident.",
        "Built monitoring and alerting across the platform, and automated the reporting on SLA metrics and technical debt so both are produced on a schedule and can be argued about with numbers rather than opinions."
      ],
      "outcome": [
        "Environments are reproducible from source, and infrastructure changes go through the same review as application changes.",
        "SLA performance and technical debt are now reported automatically, which turned two perennially vague conversations into measurable ones."
      ],
      "tags": ["Terraform", "ARM Templates", "PowerShell", "Python", "Azure", "Monitoring"],
      "impact": [],
      "links": []
    },
    {
      "slug": "platform-modernisation",
      "title": "Modernising to .NET Core and Blazor",
      "subtitle": "Improving scalability without stopping delivery",
      "category": "Cloud and Platform",
      "year": "2021-Present",
      "org": "nimbus Cloud",
      "featured": false,
      "monogram": "PM",
      "summary": "Migrated applications onto .NET Core and Blazor Server to improve scalability and performance, sequenced so feature delivery continued throughout.",
      "problem": [
        "A platform on an older framework accumulates a specific kind of cost. Hosting options narrow, performance work hits a ceiling you cannot raise, and the gap between the platform and the ecosystem around it widens every year.",
        "The obvious answer is a rewrite, and the obvious answer is usually wrong. A feature freeze long enough to rewrite a working product is rarely something a business can absorb."
      ],
      "approach": [
        "Migrated onto .NET Core for the runtime and hosting improvements, and to Blazor Server on the front end so the team could work in one language across the stack rather than maintaining two skill sets.",
        "Sequenced the migration so delivery continued alongside it. Modernisation that requires the business to stop is modernisation that gets cancelled halfway through.",
        "Paired it with the infrastructure as code and automated deployment work, since a modernised application on a hand-built environment only solves half the problem."
      ],
      "outcome": [
        "Scalability and performance improved on the migrated applications.",
        "The team works in a single stack across front end and back end, which widened who can pick up a given piece of work."
      ],
      "tags": [".NET Core", "Blazor Server", "C#", "Azure", "Migration"],
      "impact": [],
      "links": []
    },
    {
      "slug": "ai-in-the-sdlc",
      "title": "SDLC AI",
      "subtitle": "Built in-house, not switched on from a vendor",
      "category": "AI Enablement",
      "year": "2024-Present",
      "org": "nimbus Cloud",
      "featured": true,
      "monogram": "AI",
      "summary": "Designed and built the AI capability that runs across our software development lifecycle. Not a licence we activated: an architecture I designed, with the scoping, guardrails and enablement that decide whether AI in engineering is leverage or liability.",
      "problem": [
        "AI tooling arrives the way most new tooling arrives, which is unevenly. Some engineers get real leverage, others get confidently wrong code, and without a deliberate position nobody can say whether the net effect is positive.",
        "Buying a product does not answer the questions that actually matter. What code review means when a machine wrote the change. What is acceptable to send to a third-party model when your customers include government and healthcare. How you avoid slowly eroding standards that took years to raise. Those are architecture and policy decisions, not procurement ones, which is why I built rather than bought."
      ],
      "approach": [
        "Scoping first, rather than assuming AI helps everywhere. Test generation, boilerplate and migration work are strong candidates. Novel domain logic is where the failure modes are expensive and subtle, and saying so explicitly matters more than any tooling choice.",
        "Then the guardrails, designed into the system rather than written in a policy document nobody reads: a clear position on what may be sent to which model, human accountability for every merged change regardless of what produced it, and pipeline checks that do not care whether a person or a model wrote the diff.",
        "Enablement is the part most organisations underestimate. Working sessions rather than a link in a channel, shared conventions for our own codebase, and explicit permission to say a tool is not helping for a given task."
      ],
      "outcome": [
        "A working capability with a defined position on where AI belongs in the lifecycle, and guardrails enforced by the pipeline rather than assumed.",
        "This is current work and still developing. Architecture diagrams and measured results are being prepared and will be added here."
      ],
      "tags": ["AI Architecture", "AI Governance", "Developer Experience", "Test Generation", "Code Review", "Usage Policy"],
      "impact": [],
      "figures": [],
      "//figures": "Drop architecture diagrams in here when ready. Each entry: { \"src\": \"/img/diagrams/name.svg\", \"alt\": \"...\", \"caption\": \"...\", \"wide\": true }. SVG is preferred: it stays sharp, scales, and costs a fraction of a PNG.",
      "links": []
    }
  ]
}