Contact Us

Systems Thinking

Practical insights on solutions architecture, technology strategy, and business growth.

September 2026
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

Categories:

Tags:

, , ,

Tag: discovery

  • The Cost of “Just Making It Work”

    , by:

    aashdown

    Category:

    Tags:

    , , ,

    Why Ad-Hoc Tech Decisions Cost SMBs More Later

    Every startup and SMB has made this decision at some point: a problem shows up, there’s no time to think it through properly, so someone picks the fastest fix available. A new spreadsheet. A free-tier tool. A quick integration someone found on YouTube. It works. Everyone moves on.

    Do that ten times over two years, and you don’t have ten quick fixes. You have a system — just one nobody designed, that nobody fully understands, and that’s now quietly running large parts of your business.

    This isn’t a story about bad decisions. Every one of those individual choices was probably the right call in the moment. The problem isn’t the decisions — it’s that nobody ever went back and looked at them together.

    Why this happens to good businesses

    Ad-hoc tech debt isn’t a symptom of poor management. If anything, it’s a symptom of moving fast, which is exactly what growing SMBs are supposed to do. Nobody sits down and decides to build a fragile, disconnected set of tools on purpose. It happens because:

    • Speed beats structure under pressure. 
      • When a customer needs something now, “good enough” wins over “correct.” That’s usually the right trade-off — the problem is that trade-off is never revisited.
    • The person who made the decision moves on. 
      • The contractor/intern who set up a custom automation left eight months ago. Nobody else knows it exists until it breaks.
    • Tools are cheap to add and expensive to remove. 
      • Signing up for a new SaaS tool takes ten minutes. Untangling it from three other systems, a year later, takes weeks.
    • There’s no one whose job it is to see the whole picture. 
      • Individual team members own individual tools. Nobody owns how they all fit together.

    None of this is a failure of judgement. It’s just what happens by default, in the absence of a plan.

    What it actually costs

    The costs rarely show up as a single dramatic event. They show up as a slow tax on everything the business does:

    • Time. 
      • Someone, somewhere, is manually re-entering data that should flow automatically between systems. Multiply that by every week, every employee doing it, and it adds up to a real chunk of payroll spent on work that shouldn’t exist.
    • Errors. 
      • Manual processes and disconnected systems are where mistakes live — the customer who got billed twice, the order that never made it to fulfilment, the report that quietly used last month’s numbers because nobody noticed the sync had failed.
    • Decision quality. 
      • If your data lives in five places and none of them fully agree with each other, every decision made from that data is built on shaky ground. Leadership ends up making calls based on gut feel because they don’t trust the numbers — even though the business has the numbers, they’re just not usable.
    • Growth capacity. 
      • This is the one that bites hardest. A patched-together system that just about works at 20 staff often doesn’t work at 50. What was a minor inconvenience becomes the thing actively stopping you from scaling — right at the moment scaling matters most.
    • Hidden risk. 
      • Ad-hoc systems tend to have single points of failure nobody’s aware of: one person who knows how the invoicing spreadsheet actually works, one integration that will silently stop functioning if a free API tier gets deprecated. You don’t find out these exist until they fail.

    The trap of “we’ll fix it later”

    The reason this problem persists is that fixing it never feels urgent — until suddenly it’s very urgent, usually during a growth spurt, a funding round, or a busy season, which is the worst possible time to discover your systems can’t cope.

    Waiting for the “right time” to sort this out is usually a way of guaranteeing the fix happens under the most pressure, with the least time, and at the highest cost. Technical debt, like financial debt, accrues interest. The businesses that deal with it early pay a small, manageable amount. The businesses that wait pay considerably more — in emergency fixes, lost time, and often a painful stretch where the tech genuinely can’t keep up with demand.

    It doesn’t require starting over

    The fix isn’t “rip everything out and start again” — that’s rarely necessary and almost never proportionate for an SMB. It’s about someone stepping back periodically to look at the whole system, not just the individual pieces:

    • Which tools are actually doing the same job, or fighting each other?
    • Where is data being copied by hand that should just flow?
    • What’s one person away from breaking, with no backup plan?
    • If we grew 3x tomorrow, what would fall over first?

    Answering those questions properly — and building a plan around the answers — is exactly what Solutions Architecture is for. It’s not about buying more technology. Often it’s about using what you’ve already got, connected properly, with a plan for what gets added next.

    The businesses that build this habit in early don’t eliminate the cost of growth. They just pay it steadily, in small amounts, instead of all at once, at the worst possible moment.

    Ashdown Systems helps UK startups and SMBs untangle ad-hoc systems and build a foundation that can actually scale. If any of this sounds familiar, get in touch.

  • You Don’t Need to Be a Tech Company to Need Solutions Architecture

    , by:

    aashdown

    Category:

    Tags:

    , , , ,

    If you run a startup or SMB in the UK, there’s a decent chance you’ve never used the phrase “Solutions Architecture” in a sentence. That’s fine — most business owners haven’t, and most don’t need to. But there’s also a decent chance you’re already living with the exact problem it solves, without having a name for it.

    Here’s a scenario that might sound familiar. You started with a handful of tools: an accounting package, a CRM, maybe a booking system or an e-commerce platform. Each one made sense on its own, solved an immediate problem, and got switched on quickly. Eighteen months later, you’ve got data trapped in five different places, someone on your team spends half a day a week manually copying numbers between systems, and nobody’s entirely sure which version of the customer list is the “real” one.

    Nothing broke. There was no single bad decision. It just… accumulated. That accumulation is exactly what Solutions Architecture exists to prevent — and to untangle once it’s already happened.

    So what actually is it?

    Think of it like the difference between building an extension on your house room by room, versus getting an architect to draw up plans first. You can do the former — plenty of people do — and each individual room might be perfectly fine. But without a plan that considers how everything connects (plumbing, load-bearing walls, where the light falls), you end up with awkward compromises baked into the structure, ones that are expensive to fix later because now there’s a wall in the way.

    Solutions Architecture is that planning discipline, applied to how a business’s systems, tools, and data fit together. It’s not about writing code. It’s about answering questions like:

    • What are we actually trying to achieve, and what does the business need from its systems in 2 years, not just today?
    • Which tools should talk to each other, and how?
    • Where’s the single source of truth for our customer data, our orders, our finances?
    • If we double in size next year, does this setup hold — or does it fall over?

    A good Solutions Architect sits above any one piece of software. They’re not selling you a CRM or a cloud platform — they’re figuring out what combination of things (which might include tools you already own) actually serves the business.

    Why this matters even if you’re not “technical”

    There’s a common assumption that architecture is something for tech companies — SaaS businesses, software vendors, engineering-led startups. It’s true that those companies need it. But arguably, non-technical businesses need it more, precisely because they don’t have anyone in-house whose job it is to spot the problem forming.

    A tech company usually has an engineer somewhere who winces when three systems don’t talk to each other. A retail business, a professional services firm, a hospitality group — they often don’t have that person. The disconnect between systems doesn’t show up as a technical error message. It shows up as a Friday afternoon spent reconciling spreadsheets, a customer getting the wrong invoice, or a new hire who takes three weeks to understand “how we actually do things here” because it’s never been written down or built into the systems themselves.

    None of that requires you to understand databases or APIs. It requires someone who can look across your whole operation, ask good questions, and design something that fits — then translate it into terms your team can actually use.

    What this looks like in practice

    For an SMB, Solutions Architecture rarely means a six-month project with a five-figure price tag. More often it looks like:

    • A short discovery process to map out what tools you’re using and where the friction actually is
    • A clear, plain-English plan for how things should connect — what stays, what goes, what gets automated
    • Recommendations that are proportionate to your size, not “enterprise” solutions you’ll grow into eventually
    • A roadmap that means the next tool you buy fits into a plan, rather than becoming yet another island

    The goal isn’t complexity. It’s often the opposite — removing steps, removing manual work, removing the version-control chaos that builds up quietly over time.

    The real cost of not doing this

    The businesses that feel this most acutely are usually the ones growing fastest. Every new hire, every new customer, every new system you bolt on either compounds a good foundation or compounds a shaky one. The compounding is the same either way — it’s just a question of which direction it’s working in.

    The good news: you don’t need to have a technical team, or even a big budget, to start doing this properly. You just need someone to ask the right questions before the next tool gets bought, not after the third spreadsheet reconciliation of the month.

    Ashdown Systems helps UK startups and SMBs design systems and technology that actually fit how their business works — no jargon, no over-engineering. If any of this sounds familiar, get in touch.