We keep apps running

Your app is important to your organisation. No, it probably is your organisation: the membership database, the site your users log into, the thing the service runs through.

You service your car to keep it on the road. An app's no different. Skip the servicing and it'll keep running fine, right up until it doesn't, and that's always on a Friday.

• Updates. The framework, the libraries, the language version, the server underneath. Kept current, a little at a time, so nothing turns into a six-month upgrade project.
• Monitoring. We know it's down before your users email you. And when a check can't tell, it says so.
• Backups, restored. On a schedule, with a copy offsite, and restore tests so we know they work.
• Support. Email your support address and it becomes a ticket our developers answer. Urgent things get scheduled first.
• A monthly look. What changed, what we found, what we'd do next. A call if you want one.
• Hosting, if you want it. On servers we run the same way we run our own. Servers

To fix things quickly, a developer needs to know the code, and the way to know it is to work on it regularly. So keeping it running means a bit of both: support when it breaks, and steady work to stop it breaking.

You know that app you inherited? The one sitting in the corner keeping you up at night?

Maybe your last developer went travelling and never came back. Maybe the agency that built it has moved on to other things. Or maybe nobody left at all, and you've just been told nobody knows the password to deploy changes live.

We've seen that one before.

First we get it running on our systems, so we can work on it without touching yours. Then we make it portable: it builds from the repo, it deploys with one command, and the knowledge stops living in one person's head. Then we write you an audit and a risk report, in plain English, and agree what to fix first.

After that we keep it running, like any other.

Take over an app

Plenty of organisations now have code an AI wrote, sometimes with a developer watching closely, sometimes not.

It works. Today. But who understands it in eighteen months, when it needs changing and the person who prompted it has moved on?

We've built with AI for two years, with tests first and a human on every merge. We can read what yours wrote, put tests round it, and tell you honestly what's sound and what isn't.

Every app gets old. The framework stops being updated, the language gets hard to hire for, or what you need has outgrown what it was built to do.

When we see that coming, we'll tell you, well before it becomes urgent. Then we can plan the move with you and do it ourselves: to a newer version, a rebuild, or a different platform altogether. You don't have to start again with someone who's never seen your app.

We've moved a client off code we'd looked after for years, onto a new platform, and built the new one. We'd do it again.

We have rolled out the development of our reservation portal, upgraded our PHP version and continue to monitor errors and deploy fixes to the most irritating problems that we had previously grown to simply accept.

Tom Lampard, Director of Acquisitions, Lok'nStore

It was extremely comforting to know that when we encountered unexpected maintenance issues, Siftware were on call to help resolve any technical problems to ensure the ongoing effectiveness of our website.

Tony Ingram, Owner, Car & Classic

Siftware also made our application fully portable to ensure efficient development and disaster recovery.

Adam Walton, Beacon Project Coordinator, U3A