In support of support contracts

At Spork, we don’t like to dev n’ ditch. The successful deployment of your project of the upmost importance, but so too is its continued upkeep.

Print projects – indeed most physical products – are static in that once they’re done, they’re done. In contrast software is a living and breathing entity. (Ok – not literally living – developers are a confident bunch, but they cannot give life… yet.) Left unattended it can begin to feel a little unloved.

I’ve long struggled to find a suitable analogy for this in the real world. Sure, you can say it’s a little bit like a car that needs a service each year. But a car is made of actual stuff that wears in the real world, so the comparison with virtual software is possibly a little flimsy

Imagine, then, a railway carriage (I’m sitting in one currently, as it happens). The train trundles along (perhaps quite slowly, as is the case this evening). People get on and off. They leave newspapers on the seats. They leave drink cans under the seats. Some selfish bastard on the way to a rehearsal is using two seats in rush hour, as he has nowhere to put his tuba (that’s me). It’s cold. Someone has left the window open.

Slowly over time, this carriage will be messed up by its users. Little bits of things discarded will generally clutter the carriage. Left for a while, it will become miserable to travel in. The door at the end leading to the next carriage will get stuck. The toilet will eventually stink. Someone will vomit on the last train home… you get the picture.

At the end of the line, station staff will do a litter pick. Every evening the carriage will get a clean. And probably every 6 months or so the carriage will undergo a deep clean and refurbishment to properly spruce it up.

The same goes for your website, platform, or application. Data gets corrupted. Memory runs low. Code will get old and need updating. New devices (phones or tablets) come out that might necessitate tweaks. Even if you didn’t want any single change post launch, eventually things will, with the passage of time and nature, break.

As I said, we don’t dev n’ ditch. If the site has a problem, we don’t refuse you help just because we haven’t talked about support. However, a client once hypothesised that a support contract was just a way for us to make some more money. But honestly, it’s not about that; when we establish a support contract designed to keep your application working as it should, we’re upholding Spork’s central idea of being your true partners: in it for the long haul. And here is why:

Preventative maintenance

In factories, every piece of machinery is on rota to undergo downtime and an overhaul. During my (very) brief career as a manufacturing engineer I realised how crucial this was. It’s cheaper to prevent something from breaking than fixing something that’s broken. The same goes for your software.

Security

It’s a sad fact of life that people out there are trying to get access to your data. Personal or otherwise, some people do it to cause real damage, others just for shits n giggles. Whether your application just needs known weaknesses patched or whether you need exhaustive penetration testing, your dev team needs to be on top of it. It’s cheaper, safer, and less disruptive than responding to a data breach.

Reduction of Technical Debt

I’ll level with you. There will come a time in every project, usually at the end, when a developer will go, ‘Hmm… I have to build this bit in a sub optimal way, due to some type of limitation’. That limitation might be time related (implementing a last-minute change request while still hitting your deadline), or it could be some genuine technical reason – out of their control – that prevents the more sophisticated solution. This is a legitimate way to work and the most experienced developers know exactly when to take this route without apology. Left unchecked though, this work around might come back to bite someone in the arse. It’s also known as technical debt. Projects often have it and a support contract allows the dev team to revisit these parts of the code over time.

Priority Support

A contract or service level agreement will allow your team to schedule in work. They can’t prioritise you if you don’t have an agreement in place. That may mean a wait – and depending on what has gone wrong, waiting may cause further problems.

Those little tweaks

You will, undoubtedly, want something changed before too long. That’s what we’re here for; with your dev team booked in each month you can relax in the knowledge that they’re working through your list of requests methodically.

Everyone still focuses on the product

This might be considered a soft cuddly point, but I happen to think it’s really important. With ongoing support, you engage with your tech team every month. That means you, they, and everyone else think about ways to improve your platform frequently. And that is a very good thing.

If you’d like to chat to us about the support requirements of a current or upcoming project, get in touch.