You know your industry, we know architecture: how we learn your business

A question that comes up in almost every first conversation: “Do you know our industry?” The honest answer: not as well as you do – and that is not the plan. What we bring is a method for turning the knowledge inside your company into a system that fits it.

Why we do not promise industry expertise

Cloudwerks works across industries. Our own ordering platform QuickSelect runs in industrial supplies, plumbing and electrical wholesale, building materials, agriculture, foodservice, medical supplies and automotive parts. These industries have little in common – except that, every time, the decisive knowledge sat inside the company, not with us.

A provider who claims to know your industry will build you software that fits his idea of your industry. We build software that fits your company. The division is clear: you bring the industry knowledge, we bring the architecture.

Where the knowledge sits

Rarely only with management. It sits with the person in the warehouse who knows why customer X's order is always packed differently. With the field rep who knows which details he can really capture at the customer's site and which he cannot. With the clerk who types in the order today and has every special case in her head.

That is why we talk to these people – not just at hand-over, but before we design. And they see the working interim versions later, before the software is delivered. Software that is actually used in the warehouse and in the field only comes about this way.

How we ask

We do not ask for requirements. We ask about yesterday's order. “What happened first? And then? What was different from usual?” Concrete cases are more honest than descriptions of how things are supposed to run. We are particularly interested in the exceptions – they decide whether a system holds up in daily use or is replaced by paper again after two weeks.

The spreadsheets, forms and handwritten notes that exist today are the best description of your process. We want to see them. And we adopt your terms: if a “run” is a run and a “docket” is a delivery note in your company, that is what it is called in the software. Your staff should not have to re-learn their vocabulary for the system to work.

Weeks 1 and 2: your business, written down

The first two weeks of the sprint belong to the architecture and the data model. Behind the technical term is something very down-to-earth: we write down which things exist in your company – customers, orders, articles, runs, sites – and how they relate to each other. The data model is your business, put into a form a computer can work with.

This is exactly where the decisions are made that would become expensive later if they were wrong. That is why a senior architect does it, why it happens before the first screen is built, and why it is the phase in which we need your time most.

What this asks of you

• Make the right people reachable. For questions we need the people who handle the process – not only those responsible for it.
• Honesty about the current state. We are interested in how things really run, not what the quality manual says. Workarounds and stop-gaps are not embarrassing; they are the most important information.
• Real examples. A few actual orders, delivery notes or lists say more than any description.

What this does not ask of you: technical knowledge. The translation is our job.

How you will know it works

The interim versions speak your language. Your staff recognise their process instead of wondering what the screen wants from them. And at the end there are fewer of the sentences every project dreads: “But that is not how we do it.”