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: roadmap

  • AI Costs Out of Control?

    , by:

    aashdown

    Category:

    Tags:

    , , , ,

    A Solutions Architecture Approach to Getting Them Under Control

    If you’ve started using AI tools in your business — anything from an LLM API embedded in your product to a handful of AI assistants across your team — there’s a good chance the bill has started climbing faster than anyone expected. It’s becoming one of the most common conversations we’re having with tech-focused SMBs right now: AI spend crept up gradually, nobody quite knows why, and the instinct is to assume you just need to “use it less” — which, much like cloud spend a few years ago, usually isn’t the real answer.

    AI cost problems are rarely about usage being inherently too high. They’re almost always about adoption that happened faster than the architecture around it — because early on, when it was one team experimenting with one tool, it didn’t need a plan. The good news is that this is a genuinely fixable problem, provided you’re solving the right one.

    Why AI costs spiral faster than cloud costs did

    AI spend has a few characteristics that make it spiral even quicker than the cloud cost creep many businesses have already been through:

    • Per-call pricing with no natural ceiling. 
      • Unlike a fixed server bill, AI API costs scale directly with usage — every request, every token, every generation adds up in real time, often with nobody watching the meter.
    • Model choice matters enormously, and defaults are usually the most expensive option. 
      • It’s common to see a task running on a large, expensive model when a smaller, cheaper one would do the job just as well — because nobody revisited the choice once it was working.
    • Sprawl across tools and teams. 
      • AI capability shows up in a chatbot subscription, an embedded feature in your CRM, a coding assistant, an API integration — each billed separately, each decided on its own, with no one holding the full picture.
    • Experimentation that never gets reviewed. 
      • A proof of concept that worked gets left running in production. Nobody circles back to check whether it’s still needed, or whether it was ever optimised for cost.
    • Redundant calls and poor caching. 
      • The same prompt, or something close to it, gets sent to the model repeatedly because there’s no caching or deduplication layer — paying full price for an answer you already had.

    None of this is exotic, and none of it is a sign of anyone doing something wrong. It’s the predictable result of a genuinely useful technology being adopted quickly, by teams focused — rightly — on what it can do, not yet on what it costs to run at scale.

    Why “just use it less” isn’t the right frame

    The instinctive response to a high AI bill is to restrict usage — cut licences, limit API calls, tell the team to be more careful. That can help at the margins, but it treats the symptom, not the cause, and it risks throttling the exact capability that made the tool worth adopting in the first place.

    A Solutions Architecture approach starts from a different question: not “how do we use this less?” but “does how we’re using this actually match the value it’s creating?” That reframing tends to surface bigger, more durable savings than simply asking people to be more frugal.

    Where the real savings usually are

    In our experience, the biggest and most durable wins tend to fall into a small number of categories:

    • Right-sizing the model to the task. 
      • Not every task needs the largest, most capable model available. Matching model choice to actual task complexity — using a smaller, cheaper model where it performs just as well — is often the single biggest lever available, and one of the easiest to overlook.
    • Caching and deduplication. 
      • Where the same or similar requests are being made repeatedly, caching results rather than regenerating them can cut costs substantially, particularly for high-volume, low-variability use cases.
    • Prompt and workflow efficiency. 
      • Poorly structured prompts, unnecessary context, or overly chatty multi-step workflows all add cost without adding value. Tightening these up is usually low-risk and high-impact.
    • Consolidating tools and licences. 
      • AI capability adopted piecemeal across different teams often duplicates itself — several tools solving overlapping problems, billed separately. Consolidating onto fewer, well-chosen tools reduces both cost and the operational overhead of managing them.
    • Visibility and ownership. 
      • Just as with cloud spend, you can’t optimise what you can’t see. Attributing AI spend to the team, product, or feature responsible — rather than watching one combined bill arrive each month — makes it possible to prioritise fixes and hold usage accountable.

    Cost discipline as part of adoption, not an afterthought

    The other trap is treating AI cost control as a one-off clean-up: review the spend, fix what’s obviously wasteful, move on. That helps once. Then the same sprawl starts again, because the underlying pattern — fast, ungoverned adoption — is usually still there, and new AI tools keep arriving.

    The more durable fix is building cost and architecture thinking into how AI gets adopted going forward, so “what will this cost at scale, and does it need to run on the most expensive model available?” is part of the decision from the start, not a question asked eight months later when the invoice has become impossible to ignore.

    The commercial case for getting this right

    For a tech-focused SMB, AI spend isn’t a novelty line item anymore — it’s rapidly becoming a real input into margins, alongside infrastructure and headcount. Getting the architecture right doesn’t just reduce cost; it usually improves reliability and performance too, because the same discipline that controls spend — matching the right tool to the right task, avoiding redundant work — tends to produce a better-built system regardless.

    Getting a proper architectural view of your AI usage, before deciding what to cut or restrict, tends to save more money, preserve more of the value the tools were adopted for, and cause far less disruption than reaching for the off switch.

    Ashdown Systems helps UK tech-focused startups and SMBs get their AI adoption — and their AI bills — under control. If any of this sounds familiar, get in touch.

  • Cloud Costs Out of Control?

    , by:

    aashdown

    Category:

    Tags:

    , , ,

    A Solutions Architecture Approach to Cost Optimisation

    If your AWS or Azure bill has started arriving with a slight sense of dread, you’re not alone. It’s one of the most common conversations we have with growing tech-focused businesses: the cloud spend crept up gradually, nobody quite knows why, and the instinct is to assume you just need to “use less cloud” — which usually isn’t the actual answer.

    Cloud cost problems are rarely about usage being too high. They’re almost always about architecture that was never designed with cost in mind — because early on, it didn’t need to be. The good news is that this is one of the more fixable problems a scaling business will face, provided you’re solving the right problem.

    Why cloud costs spiral

    Cloud pricing is built to reward planning and punish improvisation. That’s not a criticism of AWS, Azure, or GCP — it’s just the nature of pay-as-you-go infrastructure. A few patterns show up again and again in growing businesses:

    • Over-provisioning “just in case.” 
      • Resources sized for a traffic spike that happens twice a year, running at that size the other 363 days.
    • Orphaned resources. 
      • Test environments, old databases, and unused storage volumes that were spun up for a project that finished months ago and never got switched off.
    • No visibility into what’s actually driving spend. 
      • Without proper tagging and cost allocation, nobody can say which feature, team, or customer is responsible for which part of the bill — so nobody can prioritise fixing it.
    • Architecture that made sense at a smaller scale. 
      • A design decision that was cheap and simple at low volume can become the single biggest line item on the bill once usage grows 10x, without anyone noticing the shift happened.
    • Default settings left untouched. 
      • Many services default to convenient, not cost-efficient. Nobody revisits those defaults once the system is live and working.

    None of these are exotic problems. They’re the predictable result of infrastructure decisions made under time pressure, by a team focused — rightly, at the time — on shipping rather than on the invoice.

    Why “just cut costs” isn’t the right frame

    The instinctive response to a high cloud bill is to go looking for things to switch off. That can help at the margins, but it treats the symptom, not the cause — and it risks cutting something that turns out to matter, or missing the structural issue that will just regenerate the same costs in six months.

    A Solutions Architecture approach starts from a different question:

    Not “what can we cut?” but “does the architecture match how the system is actually being used?”

    That reframing usually surfaces bigger, more durable savings than a line-by-line audit of what to switch off.

    Where the real savings usually are

    In our experience, the biggest wins tend to fall into a small number of categories:

    • Right-sizing, properly done. 
      • Not just picking a smaller instance, but matching compute and storage tiers to real, observed usage patterns rather than the original guess made at launch.
    • Committing to savings plans or reserved capacity — but only once usage is stable. 
      • These can offer meaningful discounts, but committing too early, before your architecture has settled, can lock in inefficiency rather than remove it.
    • Re-architecting for elasticity. 
      • Systems that scale down as well as up — rather than running at peak capacity permanently — can be one of the largest single savings available, particularly for workloads with predictable quiet periods.
    • Storage lifecycle management. 
      • Data that’s accessed constantly and data that’s accessed once a year shouldn’t be sitting in the same (expensive) storage tier. This is often one of the simplest fixes with an outsized impact.
    • Visibility and ownership. 
      • Proper tagging and cost allocation so that spend is attributed to the team, product, or feature responsible. You can’t optimise what you can’t see, and you can’t hold anyone accountable for a bill nobody can attribute.

    Cost optimisation as an ongoing discipline, not a one-off clean-up

    The other trap is treating cost optimisation as a single project: do a big review, fix what’s obviously wasteful, move on. That works once. Then the same drift starts again, because the underlying architecture and habits that created the problem the first time are usually still there.

    The more durable fix is building cost awareness into how architecture decisions get made going forward — so that “what will this cost at scale?” is part of the design conversation from the start, not a question asked eighteen months later when the bill has become impossible to ignore.

    The commercial case for getting this right

    For a tech-focused SMB, infrastructure cost isn’t a back-office line item — it’s a direct input into your margins, your runway, and how much room you have to reinvest in the product. A well-architected system doesn’t just perform better; it’s usually the cheaper one too, because most cost inefficiency and most technical fragility come from the same root cause: architecture that wasn’t given the chance to be deliberate.

    Getting a proper architectural view of your cloud spend, before deciding what to cut, tends to save more money and cause far less disruption than starting with the axe.

    Ashdown Systems helps UK tech-focused startups and SMBs get their cloud architecture — and their cloud bills — under control. If any of this sounds familiar, get in touch.

  • Scaling Without Breaking

    , by:

    aashdown

    Category:

    Tags:

    , , ,

    How to Choose Technology That Grows With You

    There are two ways for a growing SMB to get technology wrong, and they sit at opposite ends of the same mistake.

    The first is under-investing: sticking with tools and processes that were fine at 10 people but are visibly straining at 40, because nobody wants to spend money “fixing something that isn’t broken yet.” The second is over-investing: buying the enterprise platform, the elaborate infrastructure, the tool built for a company ten times your size — because it looks like the serious, grown-up choice, even though you won’t need most of what it does for years.

    Both mistakes come from the same place: choosing technology based on where the business is right now, without a clear view of where it’s actually heading. Getting this right isn’t about picking the fanciest option or the cheapest one. It’s about matching the tool to the trajectory.

    Why “it works for now” isn’t the right test

    When you’re evaluating a new system, tool, or platform, the obvious question is: does this solve my current problem? That’s necessary, but it’s not sufficient. The better question is: does this still make sense if we’re twice the size in 18 months? Does it still make sense if we’re a tenth of the size, because a big contract fell through?

    Technology decisions made purely for today tend to break in one of two predictable ways as a business grows:

    • They hit a hard ceiling. 
      • The tool simply can’t handle more volume, more users, or more complexity — and migrating off it mid-growth is far more disruptive than choosing better the first time.
    • They become quietly expensive. 
      • Some tools scale in cost far faster than they scale in value. What was a reasonable monthly fee at 5 users becomes a serious line item at 50, for a tool that hasn’t actually gotten any more useful.

    Neither failure mode is obvious when you’re making the initial decision — which is exactly why it’s worth having someone think it through properly rather than just picking what’s fastest to set up.

    What “grows with you” actually means

    This isn’t about always buying the most scalable, most powerful option available. That’s the over-investment trap — paying for headroom you’ll never use, and often taking on complexity you don’t need yet either. A tool that’s overkill for your current size can slow a small team down just as much as a tool that’s too limited.

    What you’re actually looking for is a good match between:

    • Where you are now
      • Team size, transaction volume, complexity of what you’re managing
    • Where you’re realistically heading
      • Not a best-case fantasy, but a grounded view of growth over the next 1–3 years
    • How painful it would be to switch later
      • Some tools are easy to move away from if you outgrow them; others lock in your data, your workflows, or your team’s habits in ways that make switching a genuine project

    A tool that’s slightly ahead of your current needs, but not wildly so, and that doesn’t trap you if your plans change — that’s usually the right zone. It’s rarely the newest or shiniest option. It’s the one that fits the shape of your actual growth curve.

    The role of architecture in getting this right

    This is where Solutions Architecture earns its keep. It’s not about recommending specific products — a good architect isn’t loyal to any particular vendor. It’s about building a clear picture of how your systems fit together today, and how that picture needs to change as the business grows, so that every new tool gets evaluated against an actual plan rather than gut feel or a sales pitch.

    In practice that looks like:

    • Mapping out what’s likely to break first as you scale
      • Often it’s not the tool you’d expect
    • Setting some ground rules for new tools before you need them
      • What they must integrate with, what data they must not silo, what happens if you need to replace them in two years
    • Separating “must solve this now” from “nice to have eventually,”
      • So that you’re not paying today for capability you won’t touch for 18 months
    • Building in the flexibility to swap out individual pieces later
      • Without having to rebuild everything around them

    Done well, this means growth doesn’t feel like a series of emergencies. It feels like the systems were expecting it.

    Growth reveals what you built

    Every growing business eventually finds out what its systems are really made of. Slow, steady growth is forgiving — it gives you time to notice and fix small cracks. Fast growth is not; it finds every weak point at once, usually at the worst possible moment, like a big new client or a busy season.

    The businesses that scale smoothly aren’t the ones who guessed right about every tool. They’re the ones who built with the next stage in mind from the start — so that growth becomes a matter of switching things on, not tearing things down and starting over.

    Ashdown Systems helps UK startups and SMBs choose and design technology that’s built for where the business is heading, not just where it is today. If any of this sounds familiar, get in touch.

  • Build vs. Buy

    , by:

    aashdown

    Category:

    Tags:

    , , ,

    The Question Every SMB Gets Wrong at Least Once

    At some point, every growing SMB hits this fork in the road: you need a system to do something — manage inventory, handle bookings, run a customer portal — and you have to decide whether to buy something off the shelf or build something bespoke. It feels like a technical decision. It isn’t, really. It’s a business decision that happens to be about technology, and it’s one that gets made under pressure more often than it gets made with a clear head.

    Most businesses get it wrong at least once — not because they’re careless, but because the pull in each direction is genuinely strong, and the wrong choice often looks completely reasonable at the time.

    Why “buy” feels safe, and sometimes isn’t

    Buying an existing tool is the default instinct, and for good reason. It’s fast, it’s proven, and someone else has already done the hard work of building and maintaining it. For a huge number of business needs — accounting, email, project management — buying is simply the right answer. There’s no commercial upside to building your own version of something that already exists and works well.

    But “buy” quietly stops being the safe option in a few specific situations:

    • When the tool almost fits, but not quite. 
      • You end up working around its limitations rather than through them — extra manual steps, workarounds, spreadsheets bolted on to cover the gap.
    • When the thing you need is actually core to your competitive advantage. 
      • If the process you’re trying to support is genuinely what differentiates your business, a generic tool built for everyone will, by definition, treat it as generic too.
    • When the pricing model doesn’t match how you’ll actually use it. 
      • Per-seat or per-transaction pricing that looked fine at your current size can become a serious cost at scale, for a tool that isn’t actually built around your specific volume or workflow.
    • When you’re stitching together several “buy” tools to replicate one coherent process. 
      • At that point, you may already be doing informal, unplanned building — just without the benefits of doing it properly.

    Why “build” feels ambitious, and sometimes is a trap

    Building feels like the grown-up, in-control choice — no compromises, exactly what you need, nothing you don’t. For genuinely core, differentiating capability, that instinct is often right. But building carries costs that are easy to underestimate, especially for a business without an existing technical team:

    • It’s never just the build. 
      • Every custom system needs ongoing maintenance, security updates, and someone who understands it well enough to change it later. The build cost is often the smallest part of the total cost over time.
    • You inherit all the boring problems too. 
      • Login, permissions, backups, uptime — a mature off-the-shelf tool has usually solved these thoroughly. Building bespoke means solving them yourself, even though they add no unique value to your business.
    • Key-person risk is built in from day one. 
      • If one developer (or one agency) built it, that’s often also the only person who deeply understands it — a single point of failure baked into your foundation.
    • The scope tends to grow. 
      • “We just need a simple booking system” quietly becomes a much larger project once every edge case and integration need surfaces mid-build.

    The question that actually matters

    The build-vs-buy decision usually gets framed as a cost comparison — which is cheaper, up front. That’s the wrong starting point. The better question is: 

    Is this capability something that differentiates the business, or something that supports it?

    If it’s genuinely differentiating — the thing customers notice, the process that’s actually your edge — it’s usually worth the investment to build and own it properly. If it’s supporting infrastructure — necessary, but not what sets you apart — buying is almost always the better use of time and money, even if it means accepting some compromise.

    Most businesses get this backwards at least once: building something generic that should have been bought off the shelf, or buying something core to their business that they should have owned outright. Both mistakes are expensive, just in different ways and on different timelines.

    A middle ground that’s often overlooked

    The choice isn’t always binary. Some of the best outcomes come from a hybrid: buying the well-solved, generic parts of a problem, and building — or configuring — the specific parts that actually matter to your business, connected together properly. This is often cheaper and faster than a full custom build, while avoiding the workaround-on-workaround problem of forcing a generic tool to do something it wasn’t designed for.

    Getting this right requires looking at the decision from above — understanding what’s actually core to the business, what the total cost of each path looks like over several years rather than at launch, and how each option affects your ability to change course later. That’s a different exercise from comparing two vendor quotes or two developer estimates, and it’s exactly where an outside architectural view earns its keep.

    Getting it right more consistently

    Founders rarely get every build-vs-buy call correct — the calculus genuinely does shift with team size, budget, and what’s actually strategic at a given stage. But businesses that treat it as a deliberate decision, revisited as circumstances change, make far fewer expensive mistakes than those that default to whichever option feels fastest in the moment.

    Ashdown Systems helps UK startups and SMBs make build-vs-buy decisions with a clear view of the real, long-term cost — not just the price tag on day one. If any of this sounds familiar, get in touch.

  • AI Tools Are Everywhere — How Do You Actually Decide What’s Worth Adopting?

    , by:

    aashdown

    Category:

    Tags:

    , , , ,

    Every business, at this point, is being pitched AI. New tools launch weekly, existing software adds an “AI-powered” feature to its marketing, and it’s genuinely hard to tell which of it is worth your attention and which is noise. For a lot of SMBs, the result is a kind of stuck feeling: aware that AI probably matters, unsure what to actually do about it, and wary of either falling behind or wasting money chasing hype.

    The good news is that deciding what’s worth adopting doesn’t actually require becoming an AI expert. It requires treating it like any other architecture decision — because that’s exactly what it is.

    Why this feels harder than it should

    Most technology adoption decisions have a fairly clear shape: there’s a specific problem, a shortlist of tools that solve it, and a reasonably stable set of options to compare. AI adoption right now doesn’t have that shape:

    • The pace of change makes “best in class” a moving target. 
      • A tool that’s clearly leading today may be matched or overtaken within months, which makes normal due diligence feel less reliable.
    • The marketing is louder than the substance. 
      • “AI-powered” gets attached to features that are genuinely useful and features that are barely more than a chatbot bolted onto an existing product, and it’s not always obvious which is which from the outside.
    • The fear of missing out is doing a lot of the decision-making. 
      • A real, if often quiet, anxiety that competitors are pulling ahead pushes businesses toward adopting tools quickly, without the normal scrutiny they’d apply to any other significant purchase.
    • It touches everything at once. 
      • Unlike a single-purpose tool, AI capability can plausibly show up in customer service, marketing, operations, and product all at the same time — which makes it hard to know where to even start evaluating.

    None of this means AI adoption should be treated differently from other technology decisions. If anything, it means the normal discipline matters more, not less, precisely because the noise is louder.

    The question that cuts through the noise

    Strip away the hype, and the evaluation question is the same one that applies to any tool: 

    “What specific problem does this solve, and is AI actually the best way to solve it?“

    That second half matters more than it sounds. Plenty of AI tools are solving real problems. Some are solving problems that a simpler, non-AI tool would handle just as well, at lower cost and lower risk. Adopting AI because it’s AI, rather than because it’s the best available solution to a specific problem, is how a lot of wasted spend and abandoned pilots happen.

    A practical framework for evaluating AI tools

    When a new AI tool crosses your desk — whether someone on your team is pushing for it or a vendor is pitching it — a few questions consistently separate the genuinely useful adoptions from the ones that fizzle out:

    • What specific, recurring problem does this solve? 
      • Not “it could help with X” in the abstract, but a concrete, repeated task that’s currently slow, expensive, or error-prone. Vague potential is a warning sign; a specific bottleneck is a good one.
    • What does it actually integrate with? 
      • A tool that sits disconnected from your existing systems creates exactly the kind of data silo and manual-reconciliation problem that costs businesses time elsewhere. Integration quality often matters more than the AI capability itself.
    • What’s the real cost at the volume you’d actually use it? 
      • AI tools are frequently priced per-use in ways that scale unpredictably. Understand what the cost looks like at realistic volume, not just the entry-level price you saw in the demo.
    • What happens if it’s wrong? 
      • Every AI tool makes mistakes some percentage of the time. The right question isn’t whether it’s ever wrong, but what the consequence is when it is — and whether there’s a sensible human check in place for anything high-stakes.
    • Who owns it, and who reviews whether it’s still worth it? 
      • A pilot that nobody’s responsible for tends to either quietly become permanent infrastructure with no oversight, or quietly get abandoned without anyone noticing. Both outcomes are avoidable with clear ownership from day one.
    • Does this reduce complexity, or add to it? 
      • A genuinely good AI adoption should make some part of the business simpler to run. If it’s adding another disconnected tool, another login, another system nobody fully understands, that’s a cost worth weighing seriously against the benefit.

    Fear of missing out isn’t a strategy

    The pressure to “do something with AI” is real, but it’s not a substitute for evaluating a specific tool against a specific problem. Adopting quickly and adopting well aren’t the same thing, and the businesses getting genuine value from AI right now are mostly the ones applying ordinary due diligence, not the ones adopting the most tools the fastest.

    Treated properly, an AI tool is just another architectural decision: does it solve a real problem, does it fit with what you already have, and does the cost and risk make sense at your actual scale. Getting that evaluation right, tool by tool, tends to produce a lot more value than trying to have an overarching “AI strategy” before you’ve adopted anything at all.

    Ashdown Systems helps UK startups and SMBs cut through the noise and evaluate AI tools against real business problems — not hype. If any of this sounds familiar, get in touch.

  • 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.