AI solution design · Granada / Remote
Before any code gets written there are a dozen decisions that determine the cost, latency and reliability of everything that follows. I design the architecture, choose the models on evidence and leave a phased roadmap with success criteria. The deliverable is a document your team can build from, with me or without me.
This service is for teams that have already decided to build something with AI and want to get the architecture right before sinking six months into it. It is also for CTOs and product leads who need a second technical opinion: someone who has taken an AI system to production and has nothing to gain by recommending the most expensive option.
I do not write code at this stage. I review what exists, talk to your team and put the decisions in writing along with their reasons, including the alternatives that were ruled out and why. If the honest conclusion is that you should buy an existing tool, or do nothing for now, that is what the document will say. And if what you need is someone to start building now, the phase you are looking for is implementation.
A component diagram, the end-to-end data flow and the decisions taken with their rationale: what was ruled out, why, and what would have to change to revisit it. Written to be read by an engineer and by a board alike.
A reasoned comparison of providers and model sizes for your specific case, with the trade-off between cost, latency and quality made explicit. Including which parts are better solved without an LLM at all — almost always more of them than expected.
What one query, one processed document or one resolved case costs, and how that number behaves as volume multiplies. It is the figure that tells you whether the project makes economic sense before it is built.
How you will measure quality: which cases make up the evaluation set, who reviews them, what threshold counts as good enough to ship, and what data you need to get there.
A phased plan with success and stop criteria for each phase. Every phase leaves something usable, and every phase has an explicit point where stopping is a legitimate outcome if the numbers do not hold up.
A closing session to walk the document through with the people who will build it, answer questions and adjust anything that does not fit your operational reality. The aim is for the team to own it.
I design from the constraints rather than from the technology. Expected volume, budget per operation, the latency your users will tolerate and what data may leave your perimeter come first; the decisions about models, RAG, agents or fine-tuning then follow almost by themselves. I know the three large commercial providers and the open options you can run on your own infrastructure, and I have no commercial agreement with any of them. The recommendation depends on your case, and the document states the conditions under which it would stop being valid.
Interviews with the business and with engineering, a review of the existing code or pilot if there is one, and access to a data sample. I need to understand the real constraints before the idea. One week.
Architecture, model comparison and cost figures. Where a decision depends on something you cannot know without trying it, I run a bounded experiment rather than assume. I share drafts halfway through so there are no surprises at the end. Two to three weeks.
Final document, roadmap and working session. From there you can build it in-house, take it to tender with a specification that finally makes technical sense, or continue with me into implementation. All three are legitimate outcomes, and the document serves equally well in each.
AI consulting for companies: find out where AI, agents and RAG actually pay off, with a senior engineer. From idea to production system, no hype.
Hands-on AI implementation: LLMs, agents and RAG integrated into your stack with tests, evals and observability. From pilot to production.
Tell me about your case and I'll tell you honestly whether AI is the right tool — and how I would implement it.