---
title: "The e-shop without a CTO: seven decisions that go wrong"
description: "Vendor choice, hiring, hosting, ownership: the technical decisions that quietly go wrong when nobody senior owns them, and what a CTO would ask instead."
author: "Luboš Zápotočný"
published: "2026-07-08"
language: "en"
canonical: "https://zapolu.com/blog/eshop-without-cto/"
---

# The e-shop without a CTO: seven decisions that go wrong

Between roughly ten and a hundred people, an e-commerce company is in
a difficult position: too much technology to manage informally, too
little to justify a full-time CTO. The gap doesn't stay empty. It gets filled by
whoever is closest (a founder, an agency, the most confident
developer), and a series of decisions get made that nobody is
qualified to veto. These are the seven we see go wrong most often,
and the question a senior technical voice would have asked.

**1. Choosing the platform by the demo.** Platforms are bought on the
polish of the admin and the promises of the sales call, then lived
with for a decade of edge cases. *The CTO question: what are our three
most unusual requirements, and can we see them working, not promised, on
this platform?*

**2. Choosing the agency by the pitch.** The cheapest bid and the
most polished presentation are both selection biases, not evidence. The failure
surfaces two years later as lock-in: code in the agency's private
repos, infrastructure on their accounts, and the knowledge nowhere
but their heads. *The CTO question: if we part ways in twelve months,
what exactly do we walk away with?*

**3. Hiring a senior developer when the problem is architecture**,
or an architect when the problem is throughput. Without someone who
has seen both, the company overcorrects for its last bad
experience. *The CTO question: is our bottleneck deciding what to
build, or building it?*

**4. Letting the plugin count become the architecture.** Every plugin
was a quick win. Fifty quick wins later, upgrades take a quarter and
nobody can say which plugin owns the price calculation. *The CTO
question: for each of these, do we know what it does, and would we
install it again today?*

**5. Inheriting infrastructure by default.** The shop runs wherever
the first developer put it, sized by guesswork, with customer
complaints standing in for monitoring. It works until the first big campaign, which is precisely
when it mustn't fail. When [checkout collapses under load that
the servers should handle](/blog/checkout-collapse-under-load/),
that default becomes expensive. *The CTO question:
what happens at five times today's traffic, and how do we know?*

**6. Not owning the accounts.** Domain at the agency's registrar,
analytics under a freelancer's Google account, deploy keys on a
laptop that left with an employee. Nothing appears wrong while the
relationship holds; when it ends, every one of those dependencies
becomes a problem. *The CTO question: can we
enumerate every account the business depends on, and who controls
recovery for each?*

**7. Treating performance as a launch task.** The site was fast at
launch; it's been getting slower by one plugin and one banner at a
time ever since, and nobody owns the number. Speed is an operations
metric, like uptime. It needs an owner and a trend line. *The CTO question: what was our LCP last month, and
who noticed the change?*

## The pattern behind all seven

All seven are ownership failures: each decision was locally
reasonable and nobody was responsible for the sum. The fix isn't necessarily a hire: at this company size the
CTO job is real but part-time, which is exactly why
[fractional CTO engagements](/services/fractional-cto/) exist. They
buy a few hours a week of someone whose job is to ask the questions above
while the decisions are still cheap to change.

If several of the seven apply to your company,
[the intro call is free](/contact/).