The invoice was for a little over forty thousand dinars. The website it paid for was never used.
It almost never happens the way people assume. Nobody was incompetent. The agency was good, the staff committed, the owner smart and successful. And still, eleven months later, the company quietly went back to taking orders on WhatsApp.
What follows is a composite — details changed and blended from more than one project. But if you have run a company in Kuwait long enough, some part of it will feel familiar.
The meeting where it went wrong
A trading company with a solid catalogue decided to sell online. The owner did what any sensible person does: he asked three agencies to propose. All three were competent, quoted a similar range, and included a platform, a timeline and a feature list. He picked the one that felt most professional.
Here is what nobody noticed. In that entire process — three proposals, several meetings, one signed contract — nobody in the room had the job of asking whether the plan was right. The agencies were answering the brief. The owner was judging the answers. The brief itself had never been examined by anyone with the experience to see what it was missing.
Everyone in the room was qualified to have an opinion. Nobody in the room was qualified to make the decision.
The brief said “an online store with our full catalogue.” It did not say how stock levels would stay in sync with the warehouse system the company had run since 2014, who would write Arabic descriptions for four thousand items, or what happens when a customer pays by KNET and the item turns out to be out of stock.
Those are not technical questions. They are business questions with technical consequences — and they surfaced one by one in month four, when each answer cost ten times what it would have in month zero.
This is not a Kuwait problem. It is just expensive here.
This is one of the best-documented failures in business technology. McKinsey’s study of large IT projects found they ran on average 45% over budget and delivered 56% less value than predicted — and the biggest cause was not technical difficulty but unclear objectives.
The people who inherit these projects tell the same story from the other side. In Stack Overflow’s 2025 Developer Survey, technical debt tops the list of what frustrates working developers — the accumulated cost of decisions made quickly and never revisited. Spend an hour in r/ExperiencedDevs or r/webdev and the same thread appears weekly: someone who has just opened a codebase built by a team nobody told what the business needed.
What makes it more expensive in Kuwait is the size of the market. A business here does not get many attempts, and the second one is always harder to fund internally than the first.
The three options — and why most businesses pick the wrong one
Faced with this, a business usually chooses between three things.
| Full-time CTO | Agency or freelancer | Fractional CTO | |
|---|---|---|---|
| What you get | Senior leadership, always available | Execution capacity | Senior judgement, part-time |
| Incentive | Aligned with the business | Aligned with building | Aligned with the decision |
| Cost | A full executive salary | Per project | A fraction of a salary |
| Best when | Technology is the product | The plan is already right | The plan has not been examined |
| The risk | Expensive and underused | Builds what you asked for | Not there every day |
Most SMEs pick the middle column, because it is the only one that produces something visible. That is the trap. An agency is paid to build; ask it whether you should build and you are asking a question its business model cannot answer neutrally. Good agencies will tell you when a brief is wrong — but you should not have to rely on it.
The first column has the opposite problem. A full-time CTO costs a senior executive salary, and for a company shipping one significant project a year, most of that buys availability you do not use. SaaStr argues the wrong senior technology hire, made too early, is the most damaging hire a growing company can make.
What actually happens in the first thirty days
People assume a fractional CTO arrives with a strategy deck. In practice the first month is mostly listening and arithmetic.
Week one: what is the business trying to do?
Not “what do you want to build,” but what has to be true commercially in twelve months and how you will know it happened. Half the projects I am called into cannot answer this. A project without a success condition cannot fail — which means it cannot succeed either.
Week two: what already exists?
The current site, the analytics, the search performance, and how work actually flows through the company. The warehouse system nobody mentioned in the brief usually turns up in week two.
Week three: the decisions
Platform, structure, scope, integrations, sequence. Most of the value is created here, and it looks like the least impressive week, because the deliverable is a document rather than a screen. That document is what stops month four from happening.
Week four: what not to build
Almost always the most valuable conversation. A brief that started with forty features leaves with twelve, a launch date months earlier, and a written plan for the rest — some of which will never be missed.
After that the role becomes review rather than design: checking that what is delivered matches what was agreed, and catching architectural mistakes while they are still cheap.
A real example, from my own side of the table
I do not only advise on this — I build. UTTER IN, a voice-first AI assistant I founded, is a useful example because I had to make these calls with my own money.
Every capture goes through a language model, and it would have been easy to send every request to the most capable one available. It demos beautifully. It also produces a cost per user that quietly destroys the business at scale. So routine requests run on a small, cheap model, and only ambiguous ones escalate.
That is a fifteen-minute decision at the design stage. Made a year after launch, with pricing already published, it is a rebuild. Nothing about it is visible in the interface — and it is the difference between a product that survives and one that does not.
When you do not need one
- Your plan has already been examined by someone technical with no stake in building it.
- You need a small marketing website and nothing else — hire a good web consultant and go.
- Technology is genuinely your product and you are past real scale. You need a full-time CTO, and a fractional one should be helping you hire them.
- You want someone to validate a decision you have already made. That is an expensive way to buy agreement.
What to ask before you hire anyone for this
Whether you talk to me or someone else, these four separate senior judgement from senior-sounding conversation.
- Ask what they would not build. Anyone who accepts your whole feature list without argument is selling capacity, not judgement.
- Ask about a project that went wrong. Someone who cannot describe one honestly has either not done enough or is not being straight with you.
- Ask who maintains it in two years. If the answer is only “us,” you are buying a dependency.
- Ask them to explain a technical decision in business terms. If they cannot, translation — the entire job — is not something they can do.
Back to the forty thousand
The trading company did eventually sell online. The second attempt cost less than a third of the first, launched in under three months, and started with two hundred products instead of four thousand.
Nothing about it was more technically sophisticated. It was decided properly before anyone started building. The expensive part of the first project was never the code — it was eleven months spent building the wrong thing, confidently, at speed.
Frequently asked questions
What does a Fractional CTO actually do?
Senior technology leadership, part-time: deciding what should be built and in what order, choosing platform and architecture, reviewing the work of developers or agencies, and translating between business goals and technical consequences. It is judgement and oversight rather than writing code — though many, myself included, also build.
How is a Fractional CTO different from hiring an agency?
An agency is paid to build, so its incentives point toward building. A Fractional CTO is paid for the decision, so the honest answer is available — including that you should build less, or nothing. In practice the two work well together: one defines and oversees, the other executes.
Is a Fractional CTO worth it for a small business in Kuwait?
It depends what you are about to spend. Before a significant project — a new platform, an ecommerce build, an AI initiative — a few days of senior review is cheap insurance against a much larger mistake. If you need a simple website and nothing more, it is not worth it, and you should be told so.
Can a Fractional CTO work with my existing developer or agency?
Yes — it is one of the most common arrangements. The role gives your existing team senior direction and review rather than replacing them. Good agencies tend to welcome it, because decisions get made instead of drifting.
If any of this sounds like your last project — or the one you are about to start — read how I work on the Fractional CTO services page, or just tell me what you are trying to build. If the honest answer is that you do not need me, I will tell you that too.