Seven years ago, I walked away from a stable tech lead role to build Geedesk. That decision was built on one belief: skills beat credentials. Today, that same belief has taken me somewhere new — rebuilding my entire product suite around AI from the ground up. This is how I did it, and how you can too.

 

The Problem With "Good" Software

Geedesk handles hotel guest complaints and operations for brands like Radisson Blu, Park Plaza, and Ramada. Alongside it, I run Adjutas for asset management, Hilfedesk as an internal API-first helpdesk, LTCRM a headless AI powered CRM and FolioCRM for hotel CRM. Products built over a period of seven years and all of them worked. All of them were, underneath the polish, the same thing: forms in, database out, dashboard on top.

I always felt that the software we were using is nothing but a modern version of the database where your data was stored in a database and it was retreved and displayed in a certain format. I found my answer to this limitation in machine learning and artificial intelligence. 

Not a lot of people know that I have also been running a company called AxionTech where we build custom software for our clients. In the past half a decade we have built CRMs, ERPs and other productivity tools. 

Working across enough client systems, a pattern became impossible to ignore: every one of them was sitting on data with foresight buried inside it, and none of them could use it. A support queue that could tell you three days out which ticket was about to become a churn risk. An operations log that could flag a bottleneck before it caused a delay, not after. The information was there. The software just recorded it — it never anticipated anything.

That gap is what took AxionTech AI-first.

In the past two years AxionTech has undergone a radical change. We are no longer building applications with databases and a dashboard. We are focusing on building intelligent system that couples the old enterprise software with machine learning and artificial intelligence to help businesses run more efficiently and recognize patterns that are difficult or close to impossible for a human to identify. We call them custom intelligent systems. 

 

Gradually Stop Building Legacy Software

Every change involves a certain amount of risk. No matter hos optimistic you are every change involves a certain amount of risk. While the risks can at times reward, they also on the other hand cause a business to shutdown. 

The journey of AxionTech to become an AI first company was also filled with such risks and uncertainity no matter how much we planned. The very first step that we took was to ask the sales to stop pursuing new projects. Obviously the sales team was allowed to go through their pipeline to close all open deals and those projects were delivered without any compromise. 

The free time that the sales team had from not pursuing new leads/deals was usefully invested in some family time and also to learn selling new service of building custom intelligent applications. 

We provided them all kinds of training and support to ensure they were becoming the evangelists of this new form of software as eventually they would be hunting of similar opportunities in the market. 

 

Setup an Internal AI Team

As there were live projects going on in the company we could not ask the entire engineering team to stop building legacy applications. Deals were accepted and had to be delivered. While the larger of the company was working towards delivering applications already built, we setup a small internal team to learn and pick up the technical knowledge required to build intelligent systems. 

We called this team the AI Team and did not assign them to any client projects. Instead their primary goal was to learn the new technology and build custom intelligent systems. 

Most of the internal applications that we use is built by our own team. Our HR system, our project management application our crm all of it was built internally. So our AI Team had a lot of legacy applications work with with during their learning phase. 

We were mostly a php shop and our AI team had to learn Python. So some of our initial steps were that basic. 

 

Why I Didn't Start With Frameworks

Every AI tutorial online starts with a framework — LangChain, CrewAI, pick your flavor. I didn't. I started with raw tool-calling: Python, direct API calls, building the agent loop by hand.

This was deliberate. Frameworks are opinions wrapped around mechanics, and they hide the mechanics from you. When an agent breaks in production — and agents break in ways forms-and-database software never does — you need to know exactly what's happening underneath. I built that understanding first. Only once the fundamentals were solid did I bring in LangGraph, and only for the parts where a real state graph earns its complexity: multi-step agentic workflows, not single tool calls dressed up as "AI."

If you're starting this path: resist the framework first. Build one agent loop by hand before you let a library abstract it away from you. You'll debug faster for the rest of your career because of it.

 

Building Simple Systems

With the basic foundation set, the next focus was to quickly get out of the tutorial vortex and start building real applications. We kept the applications very simple but highly useful.

For example the very first software that we built was to generate high quality LinkedIn posts. We built an RAG system to accomplish this. 

The next application that we built was to implement machine learning in our HR system to identify employee churn and employee burnout. 

These small excercises not only the AI Team more capable to build AI systems, but it also improved our overall operation sby automating certain activities. 

 

Building GIA: The Guest Intelligence Assistant

GIA is the AI layer I built into Geedesk, and it's the clearest example of what going AI-first actually looks like in practice — not a chatbot bolted onto a sidebar, but a system that changes what the product fundamentally does.

The architecture rests on three pillars:

• LLaMA 3 via Ollama as the language layer, run under my own control rather than routing every guest interaction through a third-party API I don't own.
• scikit-learn models doing the unglamorous statistical heavy lifting — anomaly detection on response patterns, SLA breach prediction before the breach, not a report after it.
• LangGraph-driven proactive agents — the Velocity Watcher, which tracks how fast a complaint is escalating in real time, and the SLA Breach Agent, which flags a property before it violates contract terms rather than during the post-mortem.

Each of these pieces existed as isolated capability before I ever wired them into GIA. The real work — the work most people underestimate — is the integration: getting a language model, a statistical model, and an agentic workflow to hand off to each other cleanly, inside a product that real hotel staff use under real pressure.

 

The MCP Server: Making the Agents Useful

An agent that can't reach real data is a demo, not a product. Alongside GIA, I built an MCP server on top of my CRM's REST API — Node.js and TypeScript, with OAuth 2.1 handling auth. This is the connective tissue: it's what lets any agent I build query and act on real CRM data instead of operating in a sandbox.

This part gets skipped in most "AI-first" writeups because it's not glamorous. It's infrastructure. But it's the piece that determines whether your agents survive contact with production or stay stuck as impressive-looking prototypes.

 

Shipping Small, on Purpose

The instinct when you have a full AI vision mapped out is to build all of it at once. I didn't. I shipped the smallest possible agentic tool inside Geedesk first — one narrow task, done well, observed in production — before expanding scope. Every piece of GIA that's live today got there through that same discipline: small, shipped, observed, expanded. Not designed once and deployed whole.

That discipline extended beyond the code. I've had a career-long pull toward new ventures — cloud infrastructure, defence tech, health digitization, more ideas than any one person should chase. Going AI-first on Geedesk meant pointing that same curiosity inward, deepening what I already had instead of scattering it into something new. That focus is as much a part of "how I did it" as any technical decision.

 

How You Can Do This

This is the part I wish someone had handed me before I started. Not a list of buzzwords — a sequence of decisions, in order, with the reasoning behind each one. Follow it in this order. Skipping ahead is the most common way this kind of rebuild fails.

 

1. Find the Foresight Gap

Don't start by asking "where can I add AI." That question leads to bolt-on features nobody asked for. Start by pulling up every dataset your product already collects — logs, transactions, tickets, timestamps, status changes — and asking a sharper question: where does a human, looking at this data, know something before the software does?

In my case, it was obvious once I looked for it: an ops manager glancing at a complaint thread could sense escalation risk long before a rule-based alert would trigger. That instinct — "this is about to get worse" — was pattern recognition my software had no mechanism to perform. That's your foresight gap. Every product has at least one. Go find yours before you write a single line of AI code. If you can't name the specific gap in one sentence, you're not ready to start building yet — go back to the data.

 

2. Learn the Mechanics Before the Framework

Build a single agent loop by hand before you touch LangChain, CrewAI, AutoGen, or anything else with a logo. Concretely, that means:

• Write the function that calls the model API directly.
• Write your own tool-calling schema and parse the model's tool-use response yourself.
• Write the loop that feeds the tool's result back to the model and decides when to stop.
• Log every single step — input, decision, tool call, output — so you can see the reasoning chain, not just the final answer.

This takes a fraction of the time people assume, and it pays back every time something breaks later. When your production agent misbehaves at 2 AM, you want to already understand the raw mechanics that a framework would otherwise have hidden from you. Only once this loop is boring and predictable to you should you introduce a framework — and even then, only for the specific complexity it earns, like multi-agent state graphs, not for single-call use cases where it's dead weight.

 

3. Design for Integration, Not Isolation

A language model alone is easy. A statistical model alone is easy. An agent framework alone is easy. Almost nobody fails at any one of these in isolation. Where builds actually fail is the handoff between them.

Be explicit about this at the design stage, before writing code:

• What does the language model hand to the statistical model, and in what format?
• What does the statistical model hand back, and how does the agent decide what to do with a borderline score versus a clear signal?
• What does the agent do when one of these components is slow, wrong, or unavailable — does it fail loud, fail silent, or fall back to a simpler rule?

Draw this as a diagram before you build it. If you can't draw the handoffs cleanly, you don't have an architecture yet — you have a pile of capable components sitting next to each other.

 

4. Build the Plumbing First, Not Last

The unglamorous infrastructure — API layers, auth, data access — determines whether your agents ever touch real data or stay stuck running against toy examples forever. Treat this as core work, not a chore to defer:

• Decide early how an agent authenticates and what it's allowed to touch. Scope permissions tightly; an agent with blanket API access is a liability waiting to happen.
• If you're exposing internal systems to an agent, standardize the interface — this is exactly why I built an MCP server over my CRM's REST API rather than letting every agent talk to raw endpoints in its own inconsistent way.
• Version this layer like you would any other production API. Agents built against a moving target break constantly and unpredictably.

Do this before you're tempted to write more agent logic. An excellent agent with poor data access is worse than a modest agent with clean, reliable access — the second one you can actually trust in production.

 

5. Ship the Smallest Version First

Resist the full vision. Pick the single narrowest slice of your foresight gap and ship only that:

• Define success in one sentence before you build: what does this narrow tool need to catch or predict, and how will you know if it worked?
• Put it in front of real usage immediately, even if it's rough. Simulated data and internal demos will lie to you about how the model actually behaves against real, messy inputs.
• Instrument it heavily. You want to see false positives, false negatives, and edge cases within days, not months.
• Only expand scope once the narrow version is boring and reliable — not exciting, boring. Boring means it's trustworthy.

This is how GIA grew: one agent, one narrow task, observed until it was reliable, before the next one was added. That sequencing is not caution for its own sake — it's the only way to build trust in a system that behaves probabilistically instead of deterministically.

 

6. Protect Your Focus

This is the least technical point and the most important one. Going AI-first is a deepening move — you are making your existing product smarter, not launching a new company. The moment it starts pulling you toward unrelated new ventures, you've lost the thread.

Practically, this means:

• Every new AI capability should map directly to a gap in a product you already run, not a new idea it inspired.
• Set a hard rule for yourself about how many new agent capabilities you'll pursue in parallel — one at a time is usually right.
• When a shiny new idea shows up mid-build, write it down somewhere else and finish what's in front of you first. The idea will still be there later; the unfinished build won't fix itself.

I've chased enough new ventures over the years to know this is where most ambitious technical founders lose momentum — not from lack of skill, but from lack of a finish line. Treat AI-first as a discipline exercise as much as a technical one.

I built Geedesk over seven years on the belief that what you can build matters more than what's on your resume. Going AI-first is the same belief, applied to the next seven.