Strategy
Deciding what to build before anyone writes code, and putting an architecture and a costed plan behind that decision rather than a deck.
AI programs more often stall at the decision than at the build. There is a long list of candidate use cases, no agreed architecture beneath them, and no credible view of what any of it costs to run. Our strategy work exists to end that state. It produces a short list of use cases worth building, the architecture they share, and a build plan with costs attached, written so a CFO can read it.
Use-case discovery starts with the operation, not the model
Discovery begins with the operation, not the technology. We sit with the people who own the processes in question, follow where work queues and where errors are expensive, and write down what a fix would actually be worth to the business. Each candidate is then scored on four things: the value at stake, the state of the data it depends on, how deep it has to reach into the systems you already run, and what regulation says about it. Most candidates do not survive that. Removing them is part of the deliverable.
Target architecture, drawn once for everything on the list
The use cases that survive rarely need separate systems. They need one architecture: how data is reached, how identity and permissions carry through, where models sit and how they are routed, where evaluation runs, and what gets logged. We draw that architecture against the estate you already have, treating your cloud, your identity provider and your data platform as fixed points. It names what has to be true before anything is built, and it names the parts of the current estate that will have to change.
An honest build versus buy call
For every item on the list we take a position on whether you should build it, buy it, or leave it alone. Where a vendor already does the job and the capability is not where you compete, buying is the right answer and we say so, including when that means less work for us. Where the answer is build, we say what makes it differentiating enough to justify owning it. Vendor options are tested against the same evaluation criteria we would apply to a system we built ourselves.
The plan is costed because we would have to build it
An estimate written by people who never have to deliver against it is a guess. Ours comes from the engineers who would do the work, which is why the plan is constrained by what is actually buildable in your environment. It sets out the sequence, what has to exist before what, the integration and data work hiding under each item, the internal people whose time is required, and the costs that follow from all of it. Where a number is uncertain, the plan says so and says what would resolve it.
A document your board can act on
The output is a written plan, not a presentation. It carries the decisions, the architecture, the cost basis and the risks in a form your finance and risk functions can review without a translator in the room. It belongs to you. If you take it to another firm, or build it with your own team, it still works, because nothing in it depends on us being the ones to execute. We would rather lose the build than write a plan that only we can read.
What you get
- A scored inventory of candidate use cases, including the ones we recommend killing and the reasoning behind each call.
- A target architecture drawn against your existing cloud, identity and data platform, naming the parts of the estate that have to change.
- A build versus buy position on every surviving use case, with the vendor options we tested and why they passed or failed.
- A sequenced build plan with costs attached, produced by the engineers who would deliver it.
- A risk and control view covering data access, auditability and the regulatory questions your reviewers will ask.
- A short list of what to do first, written so a sponsor can take it to a finance committee without rewriting it.
Evidence
Zilk is an AI, cloud, network and security engineering firm we built and still run, and it forced the same decision this practice makes for clients: which capabilities were worth engineering into products of our own, which were better delivered as services, and what architecture had to sit under both.
Zilk and the rest of what we have built →
What this is not
This is not a strategy deck practice. Caltor does not sell advice it cannot execute, so we will not take strategy work on a system we would not be prepared to build. It is also not an assessment commissioned to satisfy a governance checkpoint. If what you need is a market scan, a maturity score or a benchmark against peers, another firm will do that better.
Talk to a partner
If you have a list of AI ideas and no agreed architecture underneath them, that is the conversation to start.
