<p>When an online store fails, people picture an outage. In practice, the expensive failures are far quieter than that. The site stays up, the orders just stop being what they should be, and nobody notices for a quarter.</p><h2>Speed is a revenue line, not a technical metric</h2><p>Every extra second a product page takes to load costs you buyers. Oversized images, a theme carrying features you never enabled, and a stack of third-party scripts are usually the culprits. Measure the pages that make you money on a real mobile connection rather than on the office network.</p><h2>Checkout is where the money leaks</h2><p>Abandoned carts are rarely a pricing problem. They are a friction problem: a forced account creation, a shipping cost that appears at the last step, a payment method your customers expected and you do not offer. Walk your own checkout on a phone once a month. It is the cheapest research you will ever do.</p><h2>Unpatched plugins are the front door</h2><p>An eCommerce platform is a collection of dependencies, and every one of them is a maintenance obligation. Extensions that have not been updated in two years are how most stores get compromised. Patch on a schedule, and remove anything you are not actually using.</p><h2>Nobody is watching the errors</h2><p>Most stores have no alerting on failed payments, failed webhooks or server errors. That means a broken integration can run for weeks before someone spots the gap in the numbers. Uptime monitoring, error alerting and a weekly look at the payment logs will catch nearly all of it.</p><h2>Your recovery plan is a guess until you test it</h2><p>Backups that have never been restored are not backups. Set a date, restore to a staging environment, and find out how long it actually takes to get trading again.</p><p>None of this is glamorous work. It is the difference between a store that compounds and a store that quietly bleeds.</p>

Why online stores fail, and how to stop yours from being one

Most eCommerce failures are not dramatic. They are slow checkouts, stale plugins and unmonitored errors that quietly cost you orders every single day.

<p>There was a stretch of time when calling someone a geek was not a compliment. It meant you cared more about how a thing worked than about whether anyone else found that interesting. Plenty of us learned to keep it quiet.</p><h2>The word turned</h2><p>Somewhere along the way the meaning inverted. Being the person who reads the documentation, who wants to know why the query is slow rather than just accepting that it is, stopped being a social liability and became the most valuable thing on the team.</p><h2>But being a geek is only half the job</h2><p>Here is the part that took longer to learn. Technical depth on its own does not help a client. A perfectly elegant architecture that nobody can explain to the person paying for it is not a success. Neither is a recommendation that is technically correct and financially ridiculous.</p><p>The engineers who make a real difference are the ones who can hold both: genuine depth in the technology, and the ability to sit across from a business owner and explain the trade-off in terms they can act on. No jargon, no condescension, no pretending a decision is more complicated than it is.</p><h2>Half geek, half human</h2><p>That balance is not a slogan we picked because it sounded good. It is a hiring standard. We look for people who are unembarrassed about the depth of their technical curiosity and equally comfortable translating it for someone who does not share it.</p><p>If you have ever been the person in the room who actually wanted to know how it worked, you already understand the first half. The second half is learnable, and it is worth learning.</p>

Embracing my inner geek

Geek used to be an insult. Now it is the job description, and it is half of how we describe ourselves.

<p>Atiba has been in business since 1992. That is long enough to have supported technologies that no longer exist, and long enough to have been told several times that our whole category was about to be automated away.</p><h2>The obsolete list is longer than you think</h2><p>Server rooms we designed have been decommissioned. Languages we shipped production systems in are now historical curiosities. Entire platforms that were going to change everything did not survive their own version two. If you build a business on a single technology, you have built it on a timer.</p><h2>What survived was never the technology</h2><p>What lasted was more boring and more durable: understanding a client's business well enough to tell them when not to buy something. Being reachable when a system fails at an inconvenient hour. Having the same engineers on an account for years, so nobody has to re-explain the environment every time.</p><h2>Growth is mostly retention</h2><p>The most useful lesson in thirty years is that growth in a services business is not primarily a sales problem. Clients who stay are worth more than clients you win, and they stay because the work is good and the communication is honest, including when the honest answer is that they do not need what they were about to buy.</p><h2>Stay curious, stay sceptical</h2><p>Every few years something genuinely transformative arrives, usually alongside a dozen things that merely claim to be. Right now that is AI, and the discipline is the same as it always was: learn it properly, be honest about what it does and does not do yet, and do not let enthusiasm write cheques the technology cannot cash.</p>

Thirty years in IT: what actually lasted

We have watched a lot of technology arrive as inevitable and leave without a note. Here is what survived, and what it taught us about growth.

<p>Website accessibility lawsuits have become common enough that most businesses now hear about compliance from their lawyer rather than their designer. That is the wrong order, but it is where a lot of organisations start.</p><h2>What the standard actually is</h2><p>The Americans with Disabilities Act does not publish a technical checklist for websites. In practice, courts and settlements have converged on WCAG, the Web Content Accessibility Guidelines, at level AA. That is the standard to build against.</p><h2>The issues we find most often</h2><p>Across the sites we audit, the same handful of problems account for the majority of failures.</p><ul><li><strong>Images without alt text.</strong> Every meaningful image needs a description. Decorative images need an empty alt attribute so screen readers skip them.</li><li><strong>Insufficient colour contrast.</strong> Light grey text on white fails, and it is everywhere. Body text needs a contrast ratio of at least 4.5 to 1.</li><li><strong>Keyboard traps.</strong> Every interactive element must be reachable and operable with a keyboard alone, and the focus outline has to be visible. Removing focus styles because they look untidy is a compliance failure.</li><li><strong>Unlabelled form fields.</strong> A placeholder is not a label. Each input needs a real, associated label element.</li><li><strong>Video without captions.</strong> Pre-recorded video needs captions, and audio content needs a transcript.</li><li><strong>Headings used for styling.</strong> Heading levels describe document structure. Choosing an h4 because it happens to be the right size breaks navigation for screen reader users.</li></ul><h2>Automated tools find about a third of it</h2><p>Scanners are useful and they are not sufficient. They will catch missing alt attributes and contrast failures. They will not tell you whether your alt text is meaningful or whether your site is genuinely usable with a keyboard. That part requires a person.</p><h2>Overlay widgets are not a fix</h2><p>The one-line script that promises instant compliance does not deliver it, and their presence has featured in litigation rather than preventing it. Fix the underlying markup.</p><p>Accessibility done properly makes a site better for everyone. Clearer structure, better contrast and sane keyboard behaviour are just good design that happens to also be a legal requirement.</p>

ADA compliance basics for your website

Accessibility is a legal exposure and a design obligation. The good news is that most of it is straightforward once someone actually looks.

<p>Remote work moved a large part of most companies' attack surface into homes, coffee shops and airport lounges. The controls that assumed everyone was inside the office network stopped applying, and in a lot of organisations nothing replaced them.</p><h2>Multi-factor authentication, everywhere</h2><p>If you do one thing, do this. The overwhelming majority of account compromises we are called about would have been stopped by MFA. Enforce it on email, VPN, remote desktop and every administrative account. Prefer an authenticator app or a hardware key over SMS.</p><h2>Manage the devices, not just the accounts</h2><p>A secured account on a compromised laptop is not secured. Company data belongs on devices you can see: disk encryption on, endpoint protection running, updates enforced rather than suggested, and the ability to wipe a device remotely when it goes missing.</p><h2>Patch on a schedule you can prove</h2><p>Attackers overwhelmingly exploit vulnerabilities that already have a fix available. Automate operating system and browser updates, and keep an inventory so you know what is actually out there.</p><h2>Assume the network is hostile</h2><p>Public Wi-Fi should be treated as an untrusted network, because it is. Route work traffic through a VPN or a zero-trust access layer, and make sure home routers are not still running their factory default administrator password.</p><h2>Train for the attack people actually face</h2><p>Phishing remains the way in. Remote staff are more exposed to it because they cannot lean over and ask a colleague whether an odd email is real. Run simulated phishing, keep the training short and frequent, and make reporting a suspicious message completely blameless.</p><h2>Back up, then test the restore</h2><p>Ransomware is a backup problem before it is anything else. Keep an offline or immutable copy, and rehearse the restore before you need it under pressure.</p><p>None of these are exotic. Put them all in place and you have closed the paths behind most of the incidents we are called in to clean up.</p>

Security essentials for remote and hybrid teams

Your network perimeter now includes a lot of kitchen tables. Here is the short list that closes most of the exposure.

<p>There is a version of the AI story where a solo founder ships a company with no team. There is a more sceptical version where none of it works. Neither matches what we see when we actually build with these tools every week.</p><h2>What it genuinely does</h2><p>The compression is real. A first working prototype that used to take a small team weeks now takes a capable person days. Boilerplate, scaffolding, test data, first-draft copy, the tedious integration glue between two APIs: all of it is dramatically faster. For validating whether an idea is worth pursuing, that is a serious advantage.</p><p>It is also a genuine substitute for the specialist you cannot yet afford at 11pm. A founder who is not a designer can get to a defensible interface. A founder who is not an engineer can get far enough to know whether the hard part is hard.</p><h2>What it does not do</h2><p>It does not decide what to build. Judgement about which customer problem is worth solving comes from talking to customers, and no model has your market.</p><p>It does not carry accountability. When a system mishandles real money or real medical data, someone has to own that, and it cannot be a model. Code that looks correct and is subtly wrong is the failure mode we are called about most, and reviewing it well requires the expertise the tool was supposed to replace.</p><p>It does not maintain anything. Generated code becomes your code the moment it ships, and the second year of a system costs more than the first regardless of who typed it.</p><h2>The useful framing</h2><p>Treat AI as an exceptionally fast, tireless junior who has read everything and understood the stakes of none of it. Enormously valuable with direction and review. A liability without either.</p><p>The founders getting the most from it are not the ones asking it to replace a team. They are the ones using it to get to a real answer faster, then bringing in people who know what they are looking at before it touches production.</p>

AI as a co-founder: what it does and does not replace

AI will genuinely compress the early work of building a company. It will not do the parts that decide whether the company survives.