For a long time, our work began with another company’s problem.
There would be a process that needed to work differently, a piece of equipment that needed software, or an application that had to fit into an organisation already full of applications. The brief belonged to somebody else. Our job was to understand it well enough to build something they could use.
Partech’s roots go back to 1997. Bhaskar and Kamal Paratey have been directors since those early years. Over more than two decades, the business built software and hardware solutions for other companies. Over the last decade, making our own software for the wider world has become another substantial part of the work.
Those periods overlap. There was no single morning when we stopped being one kind of company and became another. The change was in who got to ask the first question.
Learning to listen to a brief
Client work teaches you to distinguish a request from the problem behind it. Someone asks for a report; what they need is to decide what to do next. Someone asks for a new screen; the difficulty may be the three screens they already have to use first.
It also teaches respect for the things around the software. The equipment it runs on. The person who supports it. The work that happens before a record reaches the system and after it leaves. A technically sound application can still make somebody’s day harder.
We carry that understanding into products that look much smaller. A medicine label, a receipt and a game of solitaire have very different consequences, but each deserves to be understood on its own terms. The useful starting point is a person trying to do something.
A different kind of brief
With your own product, there is nobody across the table to settle the scope for you. You choose the problem, the audience and the point at which you are willing to put your name on it.
You also inherit the work after release. A download is the beginning of a relationship. The application still needs to open after an operating-system update. A setting still needs to make sense six months later. A support address needs to lead somewhere.
That changes what a good idea looks like. A feature can be easy to build and expensive to explain. A small product can be worth keeping because it does one job particularly well. Choosing what to leave out becomes part of looking after what remains.
A familiar game with a legible board and a document that can be read comfortably on a small screen are useful expressions of that thinking. So is the type in which an instruction is set. Different products can share a practical interest in how people read and use things.
The work we want our name on
The tools available to a small team have changed enormously. We can make and try things faster. That makes judgement more useful, because producing an implementation is no longer the only difficult part of making a product.
We still have to decide whether the thing deserves somebody’s attention, whether it behaves as its description suggests, and whether we can keep looking after it.
This journal is where we will write about those decisions. Some pieces look back at the experience that shaped Partech. Others look closely at something we are making now. The connection is the work itself: understanding a problem, making a useful thing, and staying responsible for it.