How tech shortcuts come back to haunt startups

Every startup wants to move fast.

Investors reward it, founders celebrate it and employees wear it as a badge of honour. Great ideas, few means, wildly talented people — and deadlines emitting enough pressure to forge diamonds.

I have been lucky enough to work across a lot of different environments — and have almost seen it all: teams restructured and expanded, tech-stacks reworked, costs rationalised and, more recently, the great AI gold rush.

But after working with startups at different stages of growth, I've become convinced that many companies aren't actually moving fast at all. They're simply skipping the homework.

The irony is that these problems rarely begin when a startup is struggling. They begin when it's succeeding — hiring quickly, shipping features and suddenly having enough money to solve every problem by throwing people or software at it.

The transition from 15 people to 150 people is where many startups accidentally build in complexities that later slow them down. Processes that worked when everyone sat around one table begin to fail, but companies often respond by adding more tools, more people and more software instead of simplifying how work gets done.

The specifics vary from company to company, but the underlying patterns rarely do. Different products, different markets and different leadership teams often end up making surprisingly similar trade-offs under pressure.

I have seen these patterns after many years operating across multiple companies, including startups and scaleups in many different domains. You may find similar things happening at your own organisation.

For all the talk of velocity, the startup world is spectacularly overcomplicated. An enormous amount of what gets built is over-engineered and under-documented and, my personal favourite, built more than once.

I have walked into companies running two, sometimes three or even more, internal apps that all performed more or less the same function. Each configured slightly differently, each with their own maintenance costs, quirks and reasons for being that nobody could quite remember.

Congratulations! You are now paying double or triple the price to be equal times more confused.

I have also seen the same business outcome achieved by four different teams following four different undocumented processes, which sounds like harmless variety until you try to standardise or automate any of it and realise there is nothing to standardise to. You cannot automate a process that only exists in someone’s muscle memory.

Why? Because the mandate is fast growth at all costs and everyone is busy building, running like hamsters on a wheel.

Teams pour themselves into hitting those deadlines, and the pressure spikes hardest in the fortnight before a board meeting, when investors want to know where their money went - beyond the quirky company gadgets and the lavish summer party, naturally.

And so documentation becomes whatever can be typed fastest. I have seen the “single source of truth” live in a Google Doc (or Sheet) last touched six months ago, owned by someone no longer in the business. I have seen a product roadmap sketched on one Google Slide. I have seen requirements scattered across Slack DMs, where institutional knowledge goes to be forgotten.

The big problems often emerge gradually.

Releases take longer, onboarding new hires stretches from weeks into months, engineers spend more time understanding existing systems than building new ones, and every organisational change feels disproportionately painful.

Companies might describe this as "losing speed", when in reality they're paying interest on years of accumulated shortcuts.

A lot of founders and senior operators are genuinely tech-savvy, but there is a particular strain of such problems that demands attention: the technical decisions taken by someone who is not technical.

But there is a fine line between resourceful and reckless. This line often gets crossed when leaders move from taking the initiative, saying “I can figure this out myself” to “so there is no need to involve the tech team”.

The quick fix gets wired together, the tool gets chosen, the shortcut gets taken — all without the context and wider considerations a technical expert would have flagged.

In the short term it works, which is precisely the trap: because it works, nobody questions it.

In the long term, you have made a permanent decision with temporary information, and the tech team inherits it later as debt they never signed up for, cannot easily unpick and of course it needs to be resolved immediately, because it is “business critical”.

The road to unmaintainable systems is paved with the words: “Don’t worry, I’ve sorted it”.

This is a phraseI hear constantly, which sounds sensible enough.

But the question I would ask any founder is simple: what happens when someone leaves ?

Because in a startup, knowledge does not live in a system. It lives in a person. The engineer who “just knows” why the payments service behaves oddly on the last day of the month.

The product manager who remembers which half of the roadmap slide is aspirational and which half is real. When they hand in their notice, that knowledge walks out with them, badge and all, and you discover your architecture was load-bearing on a single human being.

That is not a tech stack. That is a hostage situation you did not know you were in and it will come and bite you later on. And it is going to cost you in many different ways.

This is the unglamorous truth of technical and organisational debt: it is a loan. You took it out to move fast, which was the right call at the time. But the interest compounds, silently, and it always comes due at the worst possible moment - mid-fundraise, mid-outage, mid-resignation.

I have been criticised, more than once, by CEOs and boards who made the astute observation that I was “slowing things down instead of accelerating them” and therefore “not adding the value expected from someone like me”.

It is a marvellous piece of theatre, and I understand the instinct: when you have paid for a supposed accelerant, watching someone insist on writing things down feels like betrayal and a complete U-turn. My answer is always the same: “You will thank me later.”

Because I am not slowing you down: I am stopping you from building a castle over the next two years on sand. Refusing to document, refusing to simplify, refusing to make the roadmap live somewhere a new joiner can actually find it — this is what slows you down. You just do not feel it yet.

It arrives as a bill, six months from now, disguised as “Why is onboarding taking three weeks?” or “Why did that new feature take a quarter to roll out? And break two others?”

As a chief technologist, here is the reframe I would offer any founder or investor before they file me under “expensive friction”.

Speed and rigour are not enemies: the teams that genuinely move fastest are boringly disciplined about a handful of things, and those things are usually the first I go looking for.

I start by finding the duplication, because it is always there: the two apps doing one job, the four teams solving the same problem in parallel. Killing one of them is often the fastest win a startup can have. Quite soon, you will have less to run, less to break, less to explain and less to pay for.

None of that is glamorous. None of it demos particularly well. It will not get a round of applause at the all-hands. But it is the difference between a startup that compounds and one that quietly seizes up the moment its cleverest person books a one-way holiday.

And here is one reason to be cheerful: none of it requires a fractional CTO on speed dial.

Pick one home for documentation and actually keep it alive. Kill the second app doing the first one’s job. Write the real workflow down before you try to automate it, not after. And before any “quick” technical decision, spend ten minutes with the person who lives and breaths that stuff and who will still be maintaining it in a year - it is the cheapest insurance you will ever buy, and roughly the price of a coffee.

Move fast, by all means. Just stop mistaking skipping the homework for being ahead of the class.

Eugi Bartolo is the former CTPO at Sifted.