Manufacturing success

Starting as we mean to continue

As professional website developers my team and I pride ourselves on being able to design and build complicated systems, but on more than one occasion we’ve got ourselves completely lost in the weeds and have screwed things up for our clients. 

Why would I admit this and in a public forum no less? Well mostly because I’m tired of all the dishonest cheerleading of technology that suggests that the solution to any problem is more technology.

That idea is not only untrue, it leads to the kind of hype which loses people money and livelihoods (I’m looking at you Crypto, and AI - you’re not off the hook either.)

Creating the custom web applications we build for our clients is hard. It requires financial investment, patience and skill.

I would also like to dispel the myth that coming up with technical ‘solutions’ is easy. It isn’t. Creating the custom web applications we build for our clients is hard. It requires financial investment, patience and skill, and not just from us, but from our clients too.

It has been standard practice in our business, for many years, to always advise our clients honestly and with clear language, even when it hurts to do so. As trusted advisors, designers and programmers this honesty and clarity  is our livelihood. 

So I’m going to outline a project that encapsulates all that is good, bad, hard, expensive, and ultimately rewarding about what we do. Maybe you’ll see something in that project that appeals to you, maybe some wisdom, maybe a lesson or two. I hope so.

A (hard) case study

Our client, Tony, runs a manufacturing business on Auckland’s North Shore. Tony uses large CNC machines to cut components to order and his team then assembles them into cabinetry that is ready to ship. It’s a slick operation, but there are some bottlenecks in the workflow.

Until recently, orders were still manually calculated using a pricing matrix set up in one of the most complicated spreadsheets we’d ever seen. It was so hard to use that only one member of the team could really understand it. If the price of the components changed, the calculations across several sheets had to change also - a process that was also manual and error-prone.

With the business growing fast, it was obvious that using a spreadsheet was not sustainable - let alone the risk they were taking having the entire process resting on a single employee.

And this was the birth of our project: to build an online ordering system that would allow clients to put together large orders of complicated, custom-designed components, while also calculating the amount of labour, materials, and machining time, and then sending the entire order with its multiple custom parts in a machine readable format so that it could be loaded directly into the production workflow.

This system would make pricing accurate, remove the bottleneck, and introduce new efficiencies into an already efficient business.

We were so full of optimism back then.

The deep end

Technology is, of course, both made by and used by humans. As a result it suffers from all of the problems you might expect humans to make: it uses poor assumptions, makes a few honest mistakes, fumbles the really hard jobs, and misses the occasional detail.

We try to get ahead of these problems by really understanding them - carrying out what we refer to as the design and discovery phase of the project. When we began this project we had one idea about what the finished project would be like (which wasn’t accurate) and only a rudimentary understanding of how the current system (the spreadsheet of death) actually did work.

We made some poor assumptions in the early phases about the complexity of the ordering process, and some of these got baked into the structure of the database that kept track of all of the product variations, prices, and calculations.

Our discovery was lacking, and so the design was insufficient.

Team talk

What this means on the ground is that the first version of the project took far too long to build and was not suitable for release to clients. It also cost more money than budgeted. 

These are the conversations you hate to have with your client and it is fair to say that Tony and his team experienced their fair share of frustration. We were in deep too, having sunk many more hours into the project than we were going to be paid for in a desperate bid to get something online that would work.

We were in deep too, having sunk many more hours into the project than we were going to be paid for in a desperate bid to get something online that would work.

Projects like this are a team effort. We were fortunate to have a patient client who was truly committed to seeing this web application become a reality. Not only was he not going to give up, he wasn’t going to let us off the hook either. 

Over the course of several months - after taking some time to cool off - we went back to the drawing board, working collaboratively to build a detailed scope of everything that version one lacked, and the benchmarks which version two must live up to.

It was a humbling process, but one which we were grateful to have. After all, we had something left to prove.

Circular logic

What followed was many late nights unraveling complicated processes to create clear reports for the sales-people. We generated detailed Bills of Material (BOMs) for every item, and for each order, that could be manually checked against our expectations. We added large sets of custom variables that the client could adjust as needed - such as labour rates, cutting prices, default material settings, and hardware costs.

In short, we made the system incredibly fine-grained, and we exposed all of the calculations for the team so that they could check it at every step of the way.

The team could then accurately zero-in on any details that might cause a price difference, or which might provide impossible values and break the system. Re-establishing trust in the process (and importantly, having the room to do that) meant we could create the system as it was meant to be.

This process was circular. We would generate requirements, build a test, implement a basic solution, review it, and then cycle back to the requirements again. I learned more about cabinetry on this project than I thought possible, and I think Tony and his team learned more about software development than they ever expected to.

If you love something…

…you get your customers to test it with real orders. 

When version two was first released, the sales team began using it to generate real orders for current customers. We were confident that the system was far more accurate than the spreadsheet, more easily adjusted and tailored, and far more capable of scaling - but there’s nothing like real customers to prove you wrong.

Time after time Tony would get in touch with a problem or corner case that we hadn’t considered before. We had to work out how to regularly import an updated list of 5000 different types of boards, with new pricing, and without breaking existing or historical orders. We had to make adjustments for sales commissions, variable customer discounts, account holds, and a plethora of other challenges on the fly.

Again, patience and clear communication was the key to navigating these challenges. Every mistake cost money - an order value might be out by thousands of dollars if it was using the wrong kind of board - and any loss of trust between Tony and his customers could prove disastrous.

The pricing algorithm is so complicated that it is now managed by dozens of automated tests. We write the test for any new piece of code before we write the code itself. And even so, we have made mistakes - they are inevitable at a certain level of complexity, but that does not make them any more enjoyable.

Every error we uncover is like a little dagger in the heart - so you can be sure we work extremely hard to avoid them.

The payoff

Of course it is not all pain. I wouldn’t be writing this article if it did not have a happy ending. Version two of the Cabinet Maker Online web app, along with all of the various releases we’ve made since then, has ultimately proved itself to be a tremendous success. While Tony wouldn’t want me sharing his sales figures, needless to say it’s working well.

When you spend your life writing code and manipulating computer graphics, it can be hard to see the real-world implications of your work, so I get a thrill whenever I login to the custom dashboard we designed and I see very real orders flowing in. Each of those orders is a victory of persistence, teamwork, and skill. 

5 lessons in building a custom web application

I’ve done projects like the one I described above for more than twenty years, and yet I still feel as though I’m learning each time. This project reinforced several things for me. They apply to project owners as much as they apply to me - so maybe you’ll find something useful in these lessons:

1. Spend as much time as you can stand on the project discovery and scope. It will pay off later. The designer, programmer, and the client all need to be part of this process and the document needs to be free of jargon, clear, and honest.
2. Check your assumptions, and the work, against the expectations from step 1 every chance you get. Don’t wait until 3 days before the launch to figure out it’s not even close to what you had in mind - test and review as you go. If managed well this will help the project team and stop them from getting lost deep in the woods of some problem that doesn’t matter to the end result.
3. Patience, clear communication, and good-will matter. Your project team wants this project to be a success. They want to knock it out of the park. Approach each challenge understanding this and with a desire to do the same.
4. No plan survives first contact with the enemy. The ‘enemy’ in this case, is when you see how real-world customers actually behave and you find out all of your assumptions were wrong. Be prepared to adjust, review, and redesign as needed.
5. Budget your time and money realistically. Any project worth the effort will cost both time and money. Setting too tight a timeframe, or too small a budget, is only going to undermine the end result. Web designers sometimes shy away from talking about the money - but if they’re not getting paid they work much slower, believe me.

If you’ve made it this far, you probably want to see the project itself. Head on over to contemporano.com and try putting together an order for your kitchen cabinetry. While you can’t see all of the machinery I’ve described at work, you should be able to get a taste of just what is possible.

Visit Contemporano website

---

We are looking to partner with other kiwi manufacturers, importers, or both to build high-quality, custom designed tools that will improve efficiency, reduce costs, and increase orders. If that’s you - give us a call.

Get in touch