A customer wanted to hire a bike.
That sounds simple enough. The booking came through an embedded Jotform on our website and passed into a calendar. I generated a rental contract and sent it to Legalesign for signature. Stripe handled payment and the deposit pre-authorisation. Revenue went into the till against the right bike code, while safety checks were scheduled against an inventory in Google Sheets.
It worked remarkably well. It was also ridiculous.
I had built a sophisticated collection of integrations around a small bicycle business. Each solved a real problem. Together, they created a dependency I didn't fully appreciate at the time: I had become the integration layer.
That experience led me to my first Odoo implementation. It also taught me something I still bring to ERP projects: complexity isn't necessarily the enemy. Invisible complexity is.
A bicycle shop with ambitions beyond retail
I joined Biketrax as manager around 2015. Turnover was roughly £200,000, with a heavy dependence on Brompton sales and Cycle to Work schemes. I improved the operation and grew sales to around £300,000 before buying BikeTrax with a university friend as a silent partner in 2017, forming AC Cycles Ltd.
I wanted a business that could do more. Tight margins and commissions made me uncomfortable with our dependence on a narrow range of transactions. Servicing, custom builds, hire, tours, events, corporate repairs, fleet tenders - a café and room hire offered other possibilities - with healthier margins but significant extra complexity.
The systems underneath the business had been designed for a much narrower operation.
We started with specialist retail and website software. I moved the till to Seanic, an Access/.NET-based system with direct database access, and built an Access/VBA application to clean supplier CSV files and synchronise product data, SKUs and prices.
Someone else's product information manager was called Myriad. I jokingly called mine Lukiad. Very few people knew it existed.
Accounting, invoicing, customer communications and workshop bookings lived in other applications. Later, n8n workers and intermediary databases helped move information between them. The software cost very little, but every new service added another connection I needed to understand and maintain.
The rental workflow was the clearest warning. Customers could book and sign digitally. Behind that convenience sat a business increasingly dependent on one person's knowledge of how everything fitted together.
Why I chose Odoo
Moving into larger premises made that limit harder to ignore. I wanted to bring more of the operation into a coherent system, while keeping room to experiment with what the business might become.
The alternatives I considered didn't fit. Some were too expensive for our circumstances; others were too narrow for the mix of activities I wanted to support.
Odoo stood out because of its open-source core and the ability to self-host, access the data and extend the system. I had already experienced the limits of a website platform where I could change the CSS but had little control over anything deeper.
I had been demoing Odoo 15. When Odoo 16 launched in October 2022, I started implementing it on launch day.
There was one slight complication: I didn't know Python. My main languages outside SQL were JavaScript, HTML, PHP and related technologies. I decided I could learn it. So I did.
That was my route into ERP: running a business first, then learning the technology needed to change how it operated.
Making real complexity manageable
Odoo didn't make the bicycle industry simple.
A customer can arrive at a workshop with almost anything. Component generations, axle widths, bottom brackets, gearing systems and brake interfaces create a substantial compatibility problem. A small shop cannot afford to keep every possible replacement part on the shelf.
Our answer was to make a much larger supplier catalogue available to the business. Lukiad evolved into a supplier-data pipeline that retrieved, normalised, compared and updated around 550,000 supplier SKUs each night. These were products we could source, rather than a claim about what we held in stock.
It also handled obsolescence: helping customers find replacements for superseded components and helping us identify old stock that needed clearing.
This is an important qualification to the story. Odoo became the core operating system, but specialist integration still had a place. Bringing activities together didn't mean forcing every requirement into one application.
What changed in the workshop
Before the implementation, a mechanic might diagnose a repair, phone the customer for approval, then put parts into baskets on several supplier websites. Someone had to remember which basket belonged to which job and whether the customer had agreed to the work.
Orders could sit there. Agreements could be misunderstood. Visibility depended on people remembering to tell each other what had happened.
Afterwards, customers could review their repair quotation through the portal and confirm the sales order. Approved work could feed into procurement, connecting the customer's decision to the parts the mechanic needed.
The mechanic could work with a catalogue much larger than our physical stockholding. The customer could see what they were agreeing to. The business could see the order and its requirements.
That benefit is difficult to communicate through a list of modules. Sales, purchasing, inventory and a portal matter because of the relationships between them: an approval becomes something the rest of the business can act on.
The part software couldn't do for us
The implementation also made gaps in our working practices more visible.
If a part left a shelf, the movement needed recording. If someone took a component from a finished bicycle for a repair, the system needed to reflect what had happened. Procurement required the right product code. Stock counts had to mean something.
People had to learn that the information they entered affected decisions made by colleagues elsewhere in the business. That required training, reinforcement and sometimes uncomfortable conversations about responsibility.
I had a responsibility here too: the process had to be clear enough for people to follow, and the system had to support the work they were actually doing.
Software can provide a workflow. Operational discipline still needs to be established and maintained by the people running the business.
What the platform made possible
Over time, the business grew to around 12 people and approximately £600,000 turnover. We built a rental fleet of around 90 bicycles, with utilisation approaching full capacity during August. Despite the scale and complexity, we did not double-book bikes.
Customers could book for themselves and handle contracts digitally. We supported tours, events, café operations, room hire and custom bicycles alongside retail and servicing.
Odoo wasn't responsible for those ideas, and I wouldn't attribute the growth to the software alone. But a flexible operating platform changed the cost of trying something new. A new service no longer automatically meant buying another standalone application and building another chain of integrations around it.
That freedom also needed restraint. The fact that I could customise something wasn't sufficient reason to do it. Sometimes configuration was enough. Sometimes integration was appropriate. Sometimes the better answer was to change the process.
The mistake I would not repeat: leaving finance outside
There is a danger in telling this retrospectively: everything starts to sound deliberate. It wasn't.
I never properly migrated accounting into Odoo. Our accountant preferred Sage, and I allowed that preference to become an implementation boundary without engaging deeply enough with the consequences.
That was my decision to own.
I had built the ERP from the operational side inward. I could see sales, purchasing, inventory, repairs and rentals. Finance still relied heavily on summary information and manual cash-flow work.
The connection between operational activity and financial reality remained incomplete. As our working practices settled around that arrangement, changing it became harder.
If I were doing it again, finance would be part of the design from the beginning. Keeping an existing accounting package might still be a valid decision, but the information flows, reconciliation and ownership would need to be explicit.
The lesson is broader than which accounting application you choose. You need to decide how a sale, a purchase or a stock movement becomes reliable financial information, and who is responsible for that connection.
Efficiency isn't immunity
AC Cycles ultimately failed. That belongs in this story too.
From my perspective as the owner, the bicycle market's overstocking and heavy discounting put severe pressure on the business. Stock that had represented a substantial investment became much harder to sell at prices that supported our costs.
At one point we were carrying roughly £250,000 of stock. As prices collapsed, my assessment was that its achievable market value could be nearer £25,000. The cost of buying stock and the price someone will now pay for it are very different things.
I don't want to turn that into a neat claim that one external event explains the whole outcome. Nor would I claim that integrating finance would necessarily have saved the business.
What I can say is that efficient operations didn't protect us from the market. Better procurement and automation could help us respond, but they couldn't restore the selling price of the stock we already owned.
An ERP can give you a clearer picture of reality. It cannot change reality for you.
Good systems improve your ability to understand what is happening, coordinate a response and make decisions. They don't guarantee that a comfortable decision will remain available.
The owner should not be the integration layer
That first implementation helped take me into technology consulting and solutions architecture. I had encountered the operational problems before learning the platform, then lived with both the improvements and the mistakes.
It still shapes the question I ask of an ERP implementation.
My original collection of applications let a small business do a great deal for very little software expenditure. But much of the architecture lived in my head. I knew what a product code meant, which record to trust, why an order appeared in one place before another and what needed restarting when an integration failed.
The business needed more of that knowledge to become explicit and usable by other people. Replacing applications was only part of the work.
Odoo didn't make me unnecessary. It changed what I was necessary for.
That is the test I would apply today: have we made the business easier for other people to understand, operate and make good decisions within?
Complexity will always exist - anyone who tells you otherwise is leading you down a dead end path. The goal is to stop hiding it in spreadsheets, scripts, inboxes or the head of the person who happens to know how everything works.
As a famous man once said of Pink-Floyd - "you don't need to understand what's going on, you just need to be able to dance to it".
Complexity, well arranged and suitably orchestrated, facilitates a better and more unique service and outcomes for your staff and your customers.
This is not easy, and neither should it be. Don't be won over by promises of vastly simplified processes and one-click implementations. They are marketing spiel. It can be easier, though, and better too - but most importantly more efficient. Keep your eye on that prize.