Why Choose Cutter

We think you should choose Cutter because we specialise in what we do and we live by our reputation. We are happy to provide references, visits to customer sites and other proof that we do a good job if you want it. Much of our business comes by customer referrals rather than by direct sales. You will find that we aren't pushy and we will advise you against switching to desktop alternatives if we don't think it's right for you.

Our goal is to make choosing a Cutter system simple, risk-free and rewarding. We want you to be our best sales resource, happily telling friends and colleagues what a good choice we were. We think we achieve that most of the time and don't want to lose our reputation for doing so.

Self-promotion apart, here are some points to think about before choosing a supplier of systems like ours.

The basics of alternative desktops are not hard to understand and in most cases the benefits are self-evident. Technical staff in many client and supplier companies alike can see this (it's not hard to do the figures) and get excited about trying something new: it's always more fun exploring new things than doing routine stuff well.

Inexperienced but skilled technicians can pick up the component parts of this kind of system and put them together well enough to work most of the time. Though the principles are straightforward, there is considerable complexity in the detail and getting that right is not quite as easy as it looks. Some things can only really be known from experience, such as sizing (how many users can a single server manage, how much memory does a typical user demand, what network bandwidth requirements are likely to be encountered, what's the best load-balancing strategy) - amongst a host of others that become more obvious once the system starts to go live. The bulk of these can be overcome by throwing money and time at the project, but that's not really what you want to be doing.

Having got it working the technicians return to the jobs they were doing before they built their one-off project.

In the meantime things run well enough until there is a problem - perhaps hardware or software failure - or the system needs to be expanded or reconfigured. At that point those technicians are often unavailable because they are working on other important projects or have moved company, or slow to respond because they can't remember what they did and have to relearn a lot of half-remembered or forgotten details. It's unlikely that the project was clearly documented or had systems monitoring and management built-in from the start.

This is not an attempt to paint an excessively bleak picture, it's based on what we've seen in the industry.

We know that what we do isn't bleeding-edge technology, but then little in life is. However it's in our interest to try to avoid the most predictable problems and to build systems that are inherently reliable and simple to maintain. Because our technical staff build these systems day in and day out and all Cutter systems are built to a common template using a limited set of components, there are few surprises when it comes to performance, support and maintenance. We have invested a time and effort in ensuring that our systems can be built to offer 100% remote maintenance and commissioning. Our bread-and-butter income is from systems support rather than new builds and installations. That means it's in our interests to engineer our products for ease of support (less work for us) and simplicity of upgrades and configuration (less expense for us and hence, frankly, more profitable since we aren't doing this just for fun).

Reliability and time-to-fix are usually crucial requirements of a replacement desktop system. You need to know that there are full-time staff out there who can be called on to deal with issues when they arise, people who are already familiar with the technologies used (because that's what they deal with all the time), who don't have to spend a long time looking for documentation or re-discovering the existing configuration. You want people who are familiar with typical failure modes or performance issues because they've already seen them before.

Though we aren't going to name names, in the past we've been invited to take over completed or half-completed system builds when either the customer or the technicians realised things weren't going to plan.

Isn't it better to avoid that and make the right decision from the start? The reality is that we are likely to cost less and do a better job.

As our partners have realised, this makes more sense than having their expensive internal technical staff learn the techniques 'from scratch' and Cutter doesn't compete with them in any other areas.