Software does not look after itself

Software is not a wardrobe. Put in place once, it does not stay in the same state for five years. Browsers change, libraries change, server versions and regulations change. The software stands still, everything around it moves, and something stops fitting.

The second reason is your company. After six months of real use, things nobody expected always come up. A different printout, one more column, a new type of order, a changed rate. Those are not defects, that is a company that keeps growing.

So we bill care monthly rather than in a rush after an outage. Ad hoc costs more and always lands at the worst moment, because you pay for the hurry and for someone opening the code cold.

The word upkeep is vague, so here is what actually happens every month. Six separate jobs, each with a different cost of getting it wrong.

• Somebody checks that it is aliveWhether the site opens, the database answers and the disk has not filled up. When something falls over you want to hear it from us, not from a member of staff who cannot raise an order.
• Backups somebody restores as a testA backup nobody has ever restored is not a backup, it is a hope. Every so often we build a working copy from the file, so we know it will hold on a bad day.
• Updates and security patchesThe libraries underneath your software get fixes every few weeks. We bring them in one at a time. That costs less than one jump three years forward after an incident.
• Bug fixesSome things only show up months later, on rare data or in a case nobody thought of. We fix them without counting every hour separately.
• Small changesA new field, a column in a summary, a different printout layout, a changed rate. Hour-long jobs nobody wants to order with a separate contract and a separate invoice.
• Watching dates nobody remembersThe site certificate, the domain renewal, keys to outside services, expiring passwords. Any one of them can stop the software on a Wednesday morning.

A company without care still does all of this. It just does it in a panic, on the day something has already stopped, and pays twice.

Plenty of care conversations start the same way. The software runs, people work on it, but there is nobody to ask for a fix. The firm that wrote it stopped replying, or no longer exists.

• You do not have the codeWe work out where it might sit. A server account, a repository the supplier set up, a copy at the hosting company, an annex to the contract. More than once the code turned out to be somewhere the client was already paying for.
• The code exists, but nobody can run itCode with no run instructions can be useless for a week. We rebuild the environment from scratch, meaning versions, variables and the database.
• It runs on the supplier's accountThe server, the domain and the outside service accounts are often in the name of a company that has vanished. We move them onto you, so nobody but you can switch the software off with one click.
• The supplier answers but does nothingSometimes contact exists and replies do not, for months. We then say plainly what can be taken over without breaking anything, and in what order.

If the review says rewriting is cheaper than patching, we tell you so. The arithmetic behind that call is written up in how much software for a company costs. If the decision goes towards a rewrite, we move into a system built around your processes, and the old one keeps running until the new one replaces it.

A takeover follows a fixed order, because otherwise nobody can honestly say what upkeep will cost. The review usually fits into a week, two for a larger system. It ends with a document, not a verbal opinion.

1. 1
   We collect the accessWe work out what you hold keys to. Most of it happens on your side, because it means digging out old emails and invoices.

   What we check

   • the code repository
   • the server and hosting panel
   • the database and its backups
   • the domain, certificate and outside service accounts

   How long

   1 to 3 days, mostly on your side

   What can come up

   some access sits on the private account of somebody who has left

2. 2
   We run it on our own machinesWe start a copy on our own hardware, without touching what your people work on. This is the first honest test of whether the project can be developed further.

   What we check

   • whether the code builds
   • whether the database can be recreated
   • what is missing from the configuration

   How long

   half a day to two days

   What can come up

   a file or a key is missing and the software will not start without it

3. 3
   We read the code and the databaseThis is where the truth shows up. We are not grading the previous team's style. We look for places where data can drift apart or changing anything costs a week instead of an hour.

   What we check

   • database structure and where data is duplicated
   • libraries with no update in years
   • passwords written straight into the code
   • whether errors are recorded anywhere at all

   How long

   2 to 3 days

   What can come up

   personal data sits where it should not, and that has to be reported at once

4. 4
   We restore a backupWe take the most recent backup and try to build working software from it. That is the only way to tell whether you have protection or a folder of files.

   What we check

   • whether the backup restores
   • how old the most recent one is
   • how many hours it takes to get back to work after an outage

   How long

   half a day

   What can come up

   backups have been running for two years and none has ever been restored

5. 5
   We hand over a list and a priceA document with three columns. What we fix straight away, what we schedule, and what we leave alone because it works. Each line says what happens if it stays as it is.

   What we check

   • the urgent items
   • the scheduled items
   • what to leave untouched
   • a proposed care package

   How long

   the end of the review week

   What can come up

   sometimes the conclusion is that a rewrite is cheaper than upkeep

The review is paid and ends with a document that stays yours, including when we do not go on to a care package. We give the price in writing after a free call, because it depends on the size of the software and how many other tools it connects to.

We do not publish hours here. A response time on a website rather than in a contract is marketing, with nobody standing behind it. We agree it in writing in the care contract, and there it binds both sides. It depends on four things.

• On what happenedAn outage that stops work gets picked up immediately. A typo in a printout joins the queue. The contract sets out priorities, so there is no later argument about what counts as an outage.
• On the hours you workA hotel has different critical hours than an office, and a two-shift plant different again. There is no sense paying for night cover nobody needs.
• On where the software runsWhen it runs on your own server, some matters need somebody on site or access that has to be opened. When it sits with a provider, we go in ourselves.
• On the care packageOn the basic one we work through the queue. On the higher ones the response time is shorter and written down for each priority separately. We do not sell the same thing under three names.

We keep response time and repair time apart. A response means somebody replied, started and knows what comes next. A repair cannot honestly be promised in hours up front, because it depends on what broke. Confusing the two is the most common source of bad feeling.

Three packages, all monthly. Prices are net and apply to software that already runs. We match the package to what is actually in place and how many people use it.

• Care Basic490 PLNnet / month
  • Support
  • Backups
  • Small fixes
• Care Pro990 PLNnet / month
  • Everything in Care Basic
  • A set response time, written into the contract
  • Development hours included every month
• Care Scale1,990 PLNnet / month
  • Everything in Care Pro
  • A shorter response time and wider hours
  • Priority when the software is extended

Care is monthly and you can leave whenever you want. We do not tie anyone into a yearly contract. The same packages, together with the rest of how we bill work, are set out on our pricing page.

Care looks after what exists. Development adds new things. We keep them apart, because in one bucket upkeep always loses, and upkeep decides whether the software reaches its third year.

1. 1Small changes come out of the packageA field, a column, a filter, a different printout, better wording in an email to your customers. Once a month we go through the list and agree what goes in.
2. 2Bigger things are quoted separatelyA new module or a connection to another system is a stage of its own. One fixed price in writing, a date, and payment in stages, exactly as on the first build.
3. 3Your company sets the order, not usA wish list grows by itself. Once a quarter we sit over it and order it by what eats people's hours, not by what is most interesting to write.
4. 4We add to the foundation, not beside itThe new part uses the same database, the same accounts and the same permissions. Otherwise two years later you have two systems instead of one, and double the work on every change.

That is how it looks in practice on the Relay project, where staff accounts with roles and personal PINs, an archive with a monthly production summary and a big-screen mode for the floor all arrived after launch.

How to settle that kind of work so it does not end in invoices after the fact is written up in our piece on a fixed price or hourly billing.

Auresta RCP, our time-tracking module, runs in production at a hotel in the Podkarpacie region and covers several dozen reception, kitchen, spa and housekeeping staff. It runs on the client's own server, so care covers that server, its backups and updates.

The client wrote in a reference letter that when a small technical problem came up the response was immediate and the matter was resolved the same day. That is the only thing about response times we put on this page, because a client signed it rather than us.

Relay at a precast plant in Sanok shows the other side, growth while the work continues. Since go-live it gained staff accounts with roles and PINs, modules switched on in settings, an archive with a monthly production summary and a big-screen mode for the floor. The code belongs to the client.

• 0paper attendance sheets after go-live
• same daythe hotel's reported fault, from the reference letter
• on sitesoftware runs on the client's own server
• more projectsboth clients said they plan to continue

The full story of the hotel build is written up as the Auresta RCP project, including the reference letter as a download.