Cloud hosting, deployment automation, security-conscious architecture, monitoring and integrations designed around your requirements.
A call, a WhatsApp chat, or a written brief if you prefer. We ask about the outcome you need, the constraints you are under, and what has already been tried.
Within 2 business days: a one-page scope with options and the assumptions behind them, and a fixed quote for each, or a short paid discovery first if too much is still unknown.
Short milestones against acceptance criteria agreed in the scope. Decisions are written down as they are made, so nothing important lives only in a meeting.
Documentation, runbooks and decision records, with access and ownership in your name. Defects found after launch are fixed within a window agreed in your scope; ongoing support is a separate, optional agreement.
Most projects need far fewer Azure services than a reference diagram suggests. A business website usually runs on Static Web Apps; an app with a database adds App Service or Functions and Azure SQL; integration services come in only when there is something to integrate. We start from the simplest architecture that does the job, and write down why each piece is there.
For teams connecting ERP, CRM, e-commerce and partner systems, such as Dynamics 365, SAP and Salesforce, who need it to keep working when one of them does not. Already live? A reliability retrofit adds error handling, dead-lettering, alerting and identity to an estate that is running today.
For CTOs, heads of engineering and IT leads who need a senior second opinion, or a plan their own team can carry out. An architecture that grew one ticket at a time, an incident fixed with more instances, a data-centre exit with no inventory: each starts the same way, by counting what exists before designing anything.
For system integrators, consultancies and in-house programmes that need a senior Azure integration architect for a phase, or a few days a month, without a permanent hire. We work under your brand and process if the programme needs it.
How we think
A system is defined by what it does when the other side is slow, wrong or gone: the payment provider at a sale, the ERP at month end, the website on the day it was built for. So that is where the design work goes first, and every choice that matters is written down: what was considered, what was chosen, what it cost.
Scroll the diagram sideways
Timelines are planning estimates for a typical scope. Yours goes in the written scope, with a fixed quote for each option, within 2 business days of our first conversation.
Your website or app set up on Azure in your own subscription: the simplest services that fit, a deployment pipeline, monitoring, budgets and alerts.
About 5 working days: an inventory, cost and reliability findings ranked by effort and impact, and decision records, walked through on a call.
Interfaces designed, built and taken live with your team, scoped and quoted wave by wave.
A senior Azure architect for a phase, a few days a month, or a one-off second opinion on a design.
From our founder’s previous employed roles, before Kakoriya Cloud, and labelled so. It is not the firm’s client work.
Founder experience
Migration architecture · Ferry and cruise
A legacy integration estate with a data-centre exit date and no inventory: the count that had to come first, the 4 patterns it produced, and the design that was approved as the baseline for the build.
Done by our founder in a previous employed role, before Kakoriya Cloud. The design was approved; the build began after our founder left.
Founder experience
Integration platform · Construction and ERP
Bespoke on-premises applications wired into a new ERP against a fixed date, with requirements still moving: the contract-first discipline that absorbed the churn, and what a batch of messages is worth.
Done by our founder in a previous employed role, as part of a team, before Kakoriya Cloud.
Founder experience
Estate turnaround · Automotive
An integration estate that arrived undocumented, deployed by hand and failing in ways nobody could explain: the order the team took it in, and the 5 decisions inside it that were our founder’s.
Done by our founder in a previous employed role, as part of a team, before Kakoriya Cloud.
Related: Maintenance & support
Founder experience
Customer platform · Energy utility
A utility’s public customer platform meeting its first real storm: what gave way, what the team changed afterwards, and which of those changes were our founder’s.
Done by our founder in a previous employed role, as part of a team, before Kakoriya Cloud.
Related: Custom web applications
Founder experience
Figures from our founder’s previous employed roles, before Kakoriya Cloud. They are not the firm’s results.
Most projects use a few of these, not all of them.
For a review, read-only access with cost data is enough. For build work we prefer a subscription you own, with access granted per environment through your own identity provider and removed at handover.
Azure is billed by usage, so nobody can honestly promise a fixed bill. Your scope includes an estimate at your expected usage, and we set budgets and alerts so a change shows up early.
We can look, and we never promise a number before we have. The common wins are plans sized for a peak that never comes, premium tiers nothing needs, and workloads that could share a plan. Each finding comes with what it saves and what it costs to change.
About 5 working days: an inventory of what runs and how it connects, reliability and cost findings ranked by effort and impact, decision records for the changes worth making, and a call to walk through the written report.
Usually both: Logic Apps for orchestration your team can read, Functions for mapping and logic that needs real code. We say which, interface by interface, and write down why.
Yes. Those three are where most of our founder’s integration work was, in previous roles before Kakoriya Cloud: Dynamics 365 Finance and Operations through data management packages and OData, SAP S/4HANA over OData behind API Management, and Salesforce over REST from Functions fed by Service Bus.
Often. An on-premises application behind a queue or a gateway is the normal case. The new platform pieces we build run on Azure.
Yes. We start by counting and instrumenting what exists, before changing any of it.
Yes. A second pair of senior eyes next to a delivery team is one of the most useful shapes this work takes.
Yes, if the programme needs it. Our founder spent 7 years inside system-integrator delivery teams before starting Kakoriya Cloud.
It is agreed per engagement and written into the scope, so neither side is guessing. Tell us the dates and the days a week; we will tell you honestly whether we can cover them.