Why Distilleries Are Ditching In House Systems (And What to Use Instead)

Building your own distillery management system sounds sensible on paper. You keep control, avoid licence fees, and tailor everything to how your operation runs. The reality, though, is that in house systems, whether that's a sprawling Excel workbook, a creaking Microsoft Access database, or something a developer built five years ago, tend to cost far more than expected once you factor in everything beyond the initial build.

We've helped distillery businesses move away from exactly these kinds of setups, and the pattern is almost always the same: what started as a pragmatic workaround has quietly become a liability.

Key Takeaways

• In house distillery systems look cheap upfront but carry significant hidden costs in staff, maintenance, and lost productivity.
• Only 10% of employees in the Scottish Whisky industry are in engineering or technical roles, finding qualified in-house developers is genuinely hard.
• When your key developer leaves, they often take critical system knowledge with them.
• In-house systems are rarely documented well enough for someone else to take over.
• Scalability is a consistent weakness: systems built for today struggle to handle tomorrow's volume, new product lines, or regulatory changes.

The Expertise Problem Is Bigger Than You Think

Software development is genuinely difficult. It's not just writing code, it's translating complex business processes into logical, reliable system behaviour. That requires people who've done it many times before.

In distilling, that kind of expertise is rare. A case study from the Scotch Whisky Association found that just 10% of employees within the Scottish Whisky industry are in engineering or technical roles. That figure includes electricians alongside IT staff and software engineers, so the actual share of qualified software developers is even smaller.

If you do manage to find someone capable of building a warehouse management or bulk stock control system internally, there's a follow-on question worth asking: can they translate business need into proper system requirements? It's a specific skill, and many developers who are competent at writing code have limited experience turning operational complexity into software logic.

When that translation goes wrong, you end up with bugs, workarounds, and processes that don't quite match how your team actually works. You then bring in outside consultants to fix it, consultants who don't know your business, and the hoped-for cost saving evaporates.

Excel and Access: Familiar, But Fragile

A lot of distilleries we speak to aren't running a bespoke system built by an in-house developer. They're running Excel. Sometimes a very elaborate Excel setup, with linked sheets, macros, and colour-coded tabs that only two people fully understand.

Excel works well up to a point. The problem is that point arrives faster than most people expect. Once you're tracking multiple casks across multiple warehouses, managing different spirit types, recording fill dates, regauging data, and trying to reconcile stock figures with HMRC requirements, Excel starts to buckle. Files get corrupted. Two people edit the same sheet simultaneously and overwrite each other's work. A formula breaks and nobody notices for three weeks.

Microsoft Access has similar ceiling issues. It was designed for relatively simple relational data management and tends to struggle under the weight of a growing operation, particularly when more than a handful of users need access at the same time.

Moving away from these tools isn't just about convenience. It's about having a system that doesn't introduce risk into your compliance and stock management processes.

What Happens When Your Developer Leaves

This is the hidden cost that catches distilleries most off guard. You've invested months (sometimes years) in building a system. It works, more or less. And then the person who built it moves on.

In-house systems are frequently built without the kind of documentation, user manuals, or technical guides that come with properly developed software. The logic lives in the developer's head. When they leave, new staff or developers stepping in are often at a complete loss, not just about how to improve the system, but about how to keep it running at all.

Attracting someone to take on that role is also harder than hiring for a clean-slate development position. Experienced developers tend to be selective about the roles they take. Being handed an undocumented legacy system built on an outdated platform, and asked to maintain it indefinitely, isn't exactly an enticing proposition. The UK's well-documented skills shortage in technical roles makes this more acute: skilled candidates have options, and they'll generally choose work that's interesting and modern over firefighting someone else's legacy code.

The result is a system that becomes progressively harder to maintain as time passes, with an ever-shrinking pool of people willing or able to work on it.

Scalability: The Wall You Hit Without Warning

In-house systems are almost always built to solve today's problem. They're scoped around current volumes, current product lines, and current processes. That's not a criticism, it's just how pragmatic internal development works.

The difficulty comes when the business grows or changes. You add a new product. You open a second warehouse. You take on contract distilling or bonded warehousing for another brand. Suddenly the system that handled one site and one spirit type needs to handle something significantly more complex, and the architecture wasn't built for it.

This isn't hypothetical. John Dewar and Sons Ltd faced exactly this scenario. The company had relied on an in-house bulk stock control system for years. When Bacardi decided to implement a new ERP system (SAP), JDSL had to choose: invest heavily in adapting the existing in-house system to interface with SAP, or move to a purpose-built specialist solution. Their existing system was built on a legacy platform specific to their whisky operation and was approaching the end of its working life. They chose to replace it with the DRAMS system, which could handle not just whisky but bulk stocks of other maturing spirits, rum and tequila, at Bacardi production sites worldwide.

The lesson isn't that in-house systems are always wrong from day one. It's that they carry an inherent extendibility risk. If you can't upgrade or adapt them as the business changes, they become obsolete, and overhauling an obsolete system is far more expensive than it would have been to choose a more extensible solution from the start.

The True Staff Cost Is More Than Salary

Even setting aside the expertise and skills gap questions, the ongoing staff costs of an in-house system are routinely underestimated. The salary of the developer or IT staff member supporting the system is just the starting point.

There's also the time cost. Developing software in-house takes significantly longer than buying or commissioning a fit-for-purpose solution. That cost doesn't stop at launch, maintenance, updates, and improvements all take staff time that could be spent elsewhere. There's the cost of requirements analysis, design, testing, and rework when things don't work as intended.

And here's the financial reality that rarely gets discussed: that investment is almost impossible to recoup. In-house systems are typically so tightly built around one site's specific processes that they can't be sold or licensed to another organisation. Every pound spent is sunk.

Narrow Functionality: The System That Can't Keep Up

Managing maturing spirit inventory isn't a generic stock management problem. It involves unique regulatory requirements, long ageing cycles, complex blending and regauging processes, and reporting obligations that off-the-shelf general business software doesn't handle well.

In-house systems often end up with narrow functionality, good at the specific problem they were originally built for, but unable to address the full range of challenges the operation actually faces. As the business evolves, the gaps become more visible and more costly to work around.

A purpose-built solution developed by specialists who understand the spirits industry, and who keep developing it as regulation and technology change, handles this differently. Updates and improvements are rolled out as part of the product. You're not dependent on one internal developer's availability and priorities.

What a Better Approach Looks Like

For most distilleries, the right answer sits somewhere between a generic off-the-shelf system and a fully bespoke build managed entirely in-house. The key is working with developers who understand both software and your operational requirements, and building something that's properly documented, maintainable, and designed to grow with the business.

That might mean moving away from Excel into a custom-built web application that centralises your stock data, provides proper user access controls, integrates with your existing tools, and can be handed over cleanly to whoever manages it in future. It might mean commissioning a system that starts focused on your core warehouse management needs but is architected to add functionality as requirements change.

Our custom software development work with distillery businesses has typically started exactly where you might expect: an Excel file that's become unwieldy, or an Access database that one person understands and everyone else is nervous about. Getting that into a proper, supported, documented system doesn't have to be as daunting as it sounds, and the long-term costs are almost always lower than continuing to patch the existing setup.

Is In House Always the Wrong Answer?

Not necessarily. If you have a genuinely strong internal development capability, the resources to maintain it long-term, and a clear plan for documentation and knowledge transfer, in-house development can work. But those conditions are rare in distilling, and they need to be honestly evaluated rather than optimistically assumed.

The question isn't whether in-house development is possible. It's whether the full cost, expertise, ongoing maintenance, staff risk, scalability constraints, and the opportunity cost of the time involved, has been honestly accounted for. In most cases we've seen, it hasn't.

---

If your distillery is still running on Excel, Access, or a system nobody fully understands any more, it's worth having a conversation before the next breakage. Our team has helped distillery businesses make exactly this transition, from fragile in-house tools to proper, maintainable software. Talk to us about custom software development and we can walk you through what that would look like for your operation.