Custom Integrations That Actually Work for Small Businesses

A warehouse manager showed me a spreadsheet last month. Nothing unusual there – except this one had 47 tabs, was updated by five different people throughout the day, and fed data into three separate systems through a complex dance of copy-paste-pray.

"We know it's not ideal," she told me. "But the quote we got to fix it properly was... well, let's just say we're still using the spreadsheet."

I hear this constantly. Growing businesses trapped between systems that don't talk to each other, with quotes for "proper" solutions that would fund a small country.

Here's what I've learned about building custom integrations that actually work for businesses at this scale.

The Real Problem Nobody's Talking About

You've outgrown the simple stuff. Your Sage accounting system doesn't talk to your WooCommerce shop. Your CRM doesn't know what inventory you've actually got. Your warehouse system lives in its own universe.

So your team manually bridges the gaps. Every day. Multiple times per day.

The big integration platforms? They're built for enterprises with enterprise budgets. The consultancies? They want to rip everything out and start fresh – which might take 18 months and cost more than your annual turnover.

And the "simple" integration tools? They work brilliantly until you need something slightly unusual. Then you're stuck.

I've watched businesses lose entire days to manual data entry. I've seen order processing that should take minutes stretch to hours because someone needs to check three different systems and manually reconcile the results. One client was literally printing reports from one system to type the numbers into another. In 2023.

Why the Standard Advice Fails

The conventional wisdom goes something like this: "Invest in a proper ERP system that does everything." Or: "Use Zapier/Make/whatever to connect your systems."

Both can work. But here's what the sales pitch doesn't mention:

That "proper" ERP system? It'll need customising anyway because your business isn't generic. You'll spend months on implementation, train your entire team on new workflows, and probably discover it doesn't quite do that one critical thing your old system handled perfectly.

The integration platforms? Fantastic for standard workflows. I use them myself. But the moment you need conditional logic based on business rules, or you're working with an older system that doesn't have a nice API, or you need to transform data in specific ways... you're fighting the platform instead of solving the problem.

I'm not saying these approaches are wrong. I'm saying they're not always right for businesses at this scale.

What Actually Works: The Practical Approach

I've built integrations for manufacturers, retailers, distributors, and service businesses. Different industries, different systems, but the successful projects share common patterns.

Start with the pain, not the technology.

I worked with a building supplies distributor recently. They wanted "API development" to connect their systems. But when we dug into what was actually costing them time and money, it wasn't the lack of APIs – it was that their pricing updates happened in one system, but their sales team was quoting from another. By the time the prices synced (manually, overnight), they'd sometimes already quoted the old prices.

We didn't build some grand integration architecture. We built one focused script that pushed pricing changes immediately to where they were needed. Took three weeks instead of three months. Cut pricing errors by 90%. Job done.

Use the interfaces that actually exist.

Modern API? Great, I'll use that. Old system that only exports to CSV? Fine, we'll work with CSV files. Access database from 2003? ODBC connection it is.

I've built integrations using:

• Proper REST APIs (when we're lucky)
• CSV exports on scheduled tasks
• Direct database connections (carefully)
• Email parsing (yes, really)
• Even screen scraping as a last resort

The technical purist in me dies a little with some of these. But they work, they're reliable, and they solve the actual problem.

Build for your team, not for perfection.

Your integration needs to be maintainable by someone who isn't a senior developer. Because in three years, it might need tweaking, and you don't want to be held hostage by complexity.

I write code that does one thing clearly rather than everything elegantly. I document in plain English. I include error messages that actually tell you what went wrong.

Here's a simple example – this is the kind of thing that solves real problems:

import requests
import csv
from datetime import datetime

def sync_inventory_to_webshop():
    """Pull inventory from Sage, push to WooCommerce"""
    
    # Get inventory export (Sage generates this nightly)
    with open('sage_inventory_export.csv', 'r') as f:
        inventory = csv.DictReader(f)
        
        for item in inventory:
            product_sku = item['StockCode']
            quantity = int(item['QuantityInStock'])
            
            # Update WooCommerce via API
            response = requests.put(
                f'https://yourshop.com/wp-json/wc/v3/products/{product_sku}',
                auth=('api_key', 'api_secret'),
                json={'stock_quantity': quantity}
            )
            
            if response.status_code != 200:
                # Log the error somewhere your team will see it
                print(f"Failed to update {product_sku}: {response.text}")
                send_email_alert(f"Inventory sync issue with {product_sku}")

if __name__ == '__main__':
    sync_inventory_to_webshop()

Nothing fancy. But it's clear what it does, and if something breaks, the error message tells you exactly what.

A Real Example: The Manufacturer Who Couldn't Scale

A precision engineering firm came to me with a classic problem. They'd grown from 8 people to 35 in three years. Their job tracking system (a custom Access database from 2007) worked fine. Their accounting system (Sage 50) worked fine. Their customer portal (a basic PHP site) worked fine.

But nothing talked to anything else.

Every Monday morning, someone spent three hours generating reports from the job system, manually checking them against Sage, and updating the customer portal with job statuses. Every. Single. Week.

Quotes from proper integration consultancies started at figures that would've funded two new hires. Full system replacement would've taken over a year and disrupted their entire operation.

We took a different approach:

1. Built a simple middleware service that read from the Access database (via ODBC)
2. Transformed the data into a format Sage could import (CSV, nothing fancy)
3. Exposed job statuses through a basic API the customer portal could call
4. Set it all running on a schedule, with email alerts if anything failed

Total development time: five weeks. The manual Monday morning ritual? Gone. Time saved: about 150 hours per year. Error rate in customer communications: down by about 75% because we eliminated the manual transcription.

Did we modernise their entire tech stack? No. Did we solve the actual business problem? Absolutely.

They're still using that solution two years later. It's boring, reliable, and it just works.

How to Actually Implement This

If you're considering custom integration work, here's the process I follow:

Map the actual workflow, not the ideal one.

I spend time watching how your team actually works. Not how the process documentation says they should work – how they really work. Where do they get stuck? Where do they waste time? Where do errors creep in?

Identify the minimum viable integration.

What's the one connection that would save the most time or eliminate the most errors? Start there. Not with the grand vision of everything connected to everything. One solid win.

Choose appropriate technology.

For small business automation, I typically use:

• Python for data transformation and API work (readable, maintainable)
• Simple REST APIs where systems support them
• Scheduled tasks rather than real-time sync (when appropriate)
• Flat files when that's what the systems offer
• Basic error logging that emails someone when things break

Nothing exotic. Nothing that requires a specialist to maintain.

Build in monitoring from day one.

Your integration needs to tell you when it's broken. Loudly. Before your customers notice.

I include:

• Email alerts for failures
• Simple logs that non-technical people can check
• A "last successful run" timestamp somewhere visible
• Checksums or counts so you know if data's being processed

Test with real data, real scenarios.

Not sanitised test data. Real exports from your real systems, with all their quirks and inconsistencies. That's where you'll find the edge cases.

The Gotchas I've Learned the Hard Way

System updates break things.

That Sage update? Might change the CSV export format. That WooCommerce plugin update? Could alter the API response structure. Build your integrations to fail gracefully and tell you what went wrong.

Data is never as clean as you think.

You'll find product codes that are somehow blank. Dates in three different formats. Quantities that are stored as text. Customer names with special characters that break everything.

Handle it. Don't assume clean data.

Performance matters at scale.

That script that processes 100 orders in a few seconds? It might fall over when you hit 10,000 orders. Think about how it'll scale before you build it.

Someone will need to maintain this.

In two years, when you need to add a new field or change a business rule, someone needs to be able to figure out how this works. Document accordingly.

When NOT to Build Custom Integration

I'll be straight with you: custom integration isn't always the answer.

Don't build custom if:

• Your systems are fundamentally unsuitable for your business (fix the root cause)
• A standard integration platform actually does what you need (use the simpler option)
• Your processes are still changing rapidly (stabilise first)
• You don't have anyone who can maintain it (factor in long-term support)
• The system you're integrating with is about to be replaced anyway

I've turned down projects where custom work wasn't the right approach. Sometimes you really do need to replace that ancient system. Sometimes the off-the-shelf integration tool is actually perfect for your needs.

The question isn't "can we build a custom integration?" It's "is this the most practical solution for the actual problem?"

The Real Cost-Benefit Calculation

Here's how I think about whether custom integration makes sense:

Time savings: How many hours per week does the manual process cost? If it's saving 10 hours per week, that's over 500 hours per year. That pays back quickly.

Error reduction: What do errors cost you? Reshipped orders? Unhappy customers? Staff time fixing mistakes? I've seen error rates drop by 80-90% when you eliminate manual data entry.

Opportunity cost: What could your team do with that freed-up time? Could they handle more orders? Provide better service? Focus on growth instead of data entry?

Risk reduction: How much risk does the current manual process carry? One client was manually reconciling financial data – the risk of a mistake there was enormous.

Compare that to the cost of building and maintaining the integration. For most small business automation projects, the payback period is measured in months, not years.

Quick FAQ from Real Conversations

Q: How long does this typically take?

For a focused integration solving one specific problem? Usually 3-8 weeks from initial conversation to deployed solution. Depends entirely on complexity and how cooperative your existing systems are.

Q: What if our systems don't have APIs?

Most of my projects involve at least one system without a proper API. We work with what's available – CSV exports, database connections, even screen scraping if that's the only option.

Q: Can we maintain this ourselves?

That's the goal. I write code that's meant to be understood and maintained by your team or a general IT person. Not code that requires calling me every time something needs tweaking.

Q: What happens when we eventually replace one of the systems?

We build integrations to be modular. If you replace your accounting system, we update that one connection point. The rest keeps working.

Q: Is this secure?

Security is built in from the start – encrypted credentials, secure connections, audit logging. We're not cutting corners just because it's a smaller business.

The Bottom Line

Custom integration for small businesses isn't about building elaborate architectures or using the latest technology. It's about solving real problems with appropriate tools.

I've seen businesses transform their operations not through massive digital transformation programmes, but through focused integrations that eliminate specific bottlenecks. The warehouse that stopped doing manual stock counts. The distributor that eliminated pricing errors. The manufacturer who freed up 150 hours per year of admin time.

None of these were revolutionary. They were practical solutions to practical problems, built at a scale that made sense for the business.

If you're stuck between systems that don't talk to each other, and the quotes you're getting seem disconnected from reality, there's usually a more practical path forward.

Let's Talk About Your Specific Situation

Every business is different. Your systems, your workflows, your constraints – they're unique to you.

If you're dealing with integration challenges and want to explore what's actually practical for your situation, get in touch. No sales pitch, just a conversation about what might work.

Email me at hello@stirlingjonessolutions.co.uk or use the contact form at stirlingjonessolutions.co.uk.

I'll tell you honestly whether custom integration makes sense for your situation, or if there's a simpler approach you should consider first.