Analysis

5 Mistakes We Made Building Workshop Software (And What We Learned)

CutFlow Team19 February 20269 min read

CutFlow didn't start as a software company. It started as a 130-person bespoke manufacturing workshop - cutting panels, building kitchens, managing deliveries across five branches. The software came later, born out of frustration with the tools that were supposed to help us but never quite fit. We built what we needed because nothing on the market understood how workshops actually operate. UK manufacturing is a sector with deep heritage and significant economic output, yet software designed for it has historically been lacking.

But building software from the inside of a real workshop doesn't mean we got everything right. Far from it. We made assumptions that turned out to be wrong. We built features nobody asked for, missed the ones they desperately needed, and spent months going in the wrong direction more than once. This post is an honest account of the five biggest mistakes we made - and what each one taught us about what workshop software actually needs to be.

Software developer whiteboard with workshop management system architecture notes

Mistake 1: We Built a Scheduling System Nobody Used

This one still stings. We spent three months building an interactive drag-and-drop Gantt chart for production scheduling. It was, from a technical standpoint, genuinely impressive. You could drag orders onto timelines, assign them to specific machines, set dependencies between tasks, and visualise your entire production capacity for weeks ahead. We were proud of it.

Nobody used it.

The problem was fundamental: bespoke manufacturing doesn't work like a factory production line. Every job is different. A kitchen might take three days or three weeks depending on the spec, and the spec changes mid-production more often than anyone wants to admit. Workshop managers don't schedule by dragging blocks around on a screen - they schedule by walking the floor, talking to their team, and making judgement calls based on what they can see. A rigid Gantt chart that assumed predictable task durations and fixed sequences was fighting against the reality of bespoke work, not supporting it.

We watched our own workshop managers - the people we built it for - ignore the Gantt chart entirely and continue scheduling by instinct. When we asked why, the answer was blunt: "It takes me longer to update the chart than to just do the scheduling in my head."

What we changed: We stripped the Gantt chart out completely and replaced it with a simple card-based system that shows job status and branch load. No timelines. No dependencies. Just a clear view of what's in progress, what's waiting, and where the bottlenecks are. Workshop managers could see capacity at a glance without maintaining a complex schedule. Usage went from near-zero to daily within a week.

Key Lesson

Workshops need visibility, not control. A scheduling tool that tries to impose order on inherently unpredictable work will be abandoned. Show people what's happening - don't try to dictate what should happen next.

Mistake 2: We Assumed Workshops Would Enter Data

Our first order form had 23 fields. Customer details, site address, order type, material specification, edge finish, colour code, dimensions for every component, delivery requirements, installation notes, payment terms, special instructions. We thought we were being thorough. We thought if we captured everything upfront, the rest of the process would be smooth.

What actually happened: the office staff filled everything in during the first week of onboarding because they were being watched. By week two, most of the fields were being left blank. By week three, people were creating orders with just a customer name and a price, then attaching a scribbled note as a photo. The 23-field form was dead.

The reason is obvious in hindsight. Workshop staff are busy making things. The person entering an order might be the same person who just got off the phone with a customer, has three people waiting to ask questions, and needs to check on a delivery that's running late. They don't have time for a 23-field form. They need to get the essentials in and move on.

What we changed: We stripped the order creation down to the absolute minimum - customer, description, value, delivery date. That's it. Four or five fields to create an order. Everything else became optional detail that could be added later, when there was time, or auto-populated from customer history and templates. We also made the entire order entry process mobile-friendly, so people could create an order from the shop floor in under a minute. As we covered in our onboarding guide, the first week of adoption is critical - and nothing kills adoption faster than a form that feels like homework.

Key Lesson

If you need more than five fields to create an order, you've failed. Capture the minimum to get work started. Let detail accumulate naturally as the order progresses.

Mistake 3: We Over-Engineered the Quoting Module

We built a quoting system that an accountant would love. Component-level pricing. Nested assemblies where you could break a kitchen down into individual carcasses, then break each carcass into panels, edges, hinges, and handles. Profit margin calculations per line item. Material cost tracking with supplier price lookups. It was, in every technical sense, extremely accurate.

It also took 45 minutes to produce a quote that used to take 10.

Here's the truth about how most small workshops quote: a customer calls or emails with a description of what they want. The workshop owner - who has been doing this for 15 or 20 years - thinks about it for a moment and says, "That's going to be around three thousand pounds." They might sketch some rough numbers on the back of an envelope. Then they send a one-page quote with a total price, maybe broken into two or three broad line items. The customer says yes or no, and work begins.

Our component-level quoting system was solving a problem that didn't exist for 90% of our users. The workshops that needed that level of detail were large enough to have dedicated estimators. Everyone else needed speed. A quote that takes 45 minutes means fewer quotes going out, which means fewer jobs coming in. We were actively hurting our users' revenue.

What we changed: We built a simple quote builder with templates. Create a quote in minutes using predefined items, adjust the total, send it out. For workshops that want more detail, the component-level pricing is still available - but it's an option, not the default. Quoting speed went from 45 minutes back down to under 10, and the conversion rate improved because quotes were going out the same day instead of the next week.

Mistake 4: We Ignored the Van

For the first 18 months of CutFlow's development, we focused almost exclusively on what happened inside the workshop. Order management. Production tracking. Quoting. Invoicing. These felt like the core of the business, and they were - but we completely overlooked what happened after a product left the building.

Meanwhile, delivery was causing roughly 30% of all customer complaints across our own branches. Wrong items loaded onto the van. Deliveries arriving at the wrong time - or not at all. No one calling the customer to say the driver was running late. Items damaged in transit because they weren't secured properly and no one checked before leaving. The workshop could produce a flawless kitchen, and the customer's experience was still terrible because the last mile was chaos.

We had this blind spot because we thought of delivery as a logistics problem, separate from production. It isn't. A kitchen is not "done" when it leaves the workshop. It's done when it's in the customer's home, undamaged, on the day they were expecting it. Everything between the workshop door and the customer's door is still part of your production process, and if you don't manage it with the same care, you undo all the good work that came before.

What we changed: We built a complete transport and delivery module - route planning, a driver app with GPS navigation and proof-of-delivery photos, automatic customer notifications when the driver is en route, and delivery checklists to verify items before they leave. Customer complaints related to delivery dropped by over 60% within two months of rolling it out.

Tip

If your workshop software doesn't cover delivery, you're managing the hardest part of the customer experience with phone calls and hope. Transport is not an afterthought - it's the final stage of your production process.

Mistake 5: We Tried to Replace Spreadsheets Entirely

When we started building CutFlow, we had a clear mission: zero spreadsheets. We wanted every single process, every piece of data, every calculation to live inside the system. Spreadsheets were the enemy. They were unstructured, error-prone, impossible to share reliably, and they created data silos. We were going to eliminate them.

It turns out that some things genuinely work better in a spreadsheet. Ad-hoc analysis where you're trying to figure out pricing for an unusual material combination. One-off calculations for a job that doesn't fit any template. Quick what-if scenarios when a customer asks "what if we went with oak instead of walnut?" These are tasks where the freeform nature of a spreadsheet is actually an advantage, not a weakness.

By trying to force everything into structured software, we created workarounds. People would enter data into CutFlow and then immediately export it to a spreadsheet to do the analysis they actually needed. Or worse, they would keep a parallel spreadsheet for the things CutFlow couldn't handle flexibly, creating exactly the kind of data silo we were trying to eliminate.

What we changed: We stopped fighting spreadsheets and started working with them. We added CSV exports everywhere - orders, quotes, production data, financial reports. We built Excel template downloads so workshops could use our data in their own spreadsheet workflows. We created import tools so data that started in a spreadsheet could flow back into CutFlow without manual re-entry. You can find many of these templates on our free resources page. For a deeper look at where each approach works best, see our spreadsheets vs. CutFlow comparison.

Key Lesson

Don't try to eliminate spreadsheets. Work with them. Import and export are more important than replacement. Your software should be the source of truth for structured processes, and spreadsheets should remain available for everything else.

What These Mistakes Taught Us

Looking back, every single one of these mistakes has the same root cause: we built for how we thought workshops should work, not for how they actually work. We imagined an ideal workflow - every field filled in, every schedule maintained, every quote itemised to the penny - and built software to enforce it. The reality of a busy workshop is messier, faster, and far more human than any ideal workflow. People make quick decisions. They cut corners when they're under pressure. They find workarounds for anything that slows them down.

The most important lesson was this: software should adapt to the workshop, not the other way around. If your users are consistently ignoring a feature, the feature is wrong - not the users. If people are creating workarounds, they're telling you exactly where your software fails them. The answer is never "train them harder." The answer is to build something that fits how they already work.

We also learned that the parts of the business you think are peripheral - transport, spreadsheet compatibility, speed of data entry - are often the parts that matter most to the people using the software every day. The features that look impressive in a demo (Gantt charts, component-level quoting) are rarely the features that get used in practice. What gets used is whatever is fastest, simplest, and causes the least friction.

We're sharing all of this because we believe honesty builds trust. We could write a blog post about how CutFlow was perfectly designed from day one. It wasn't. It was built through trial and error, inside a real manufacturing workshop, by people who got things wrong repeatedly before getting them right. Every feature in the product today exists because we learned something the hard way. That's not a weakness - it's the reason the software actually works for real workshops. Organisations like Made in Britain champion the kind of quality-first, learn-from-experience ethos that drives UK manufacturing forward.

Built from Real Workshop Experience

CutFlow exists because we made every mistake so you don't have to. See the software we wish we'd had from day one.