Who handles software maintenance and support after launch?

What does software maintenance and support cover?

Custom software doesn’t stay finished. It runs on parts made by other people: a hosting server, a database, ready-made code, and connected apps like QuickBooks Online or Stripe. Their makers keep updating those parts, and your business keeps changing too.

Of all that upkeep, security updates matter most. CISA, the US government’s cybersecurity agency, tells people to install updates on their computers and phones as soon as possible. It warns that attackers may go after a known weak spot for months or even years after a fix is out.

Software maintenance and support is the steady work of keeping all of it running. In plain terms, it covers five things:

• Fixes. Something breaks, like an invoice that won’t send or a form that stops saving, and someone finds the cause and fixes it.
• Software updates. The parts your system is built on, and the hosting it runs on, get regular updates. With custom software, one update can break a feature, so each one should be tried on a test copy first, then put live quickly.
• Security updates. These close known weak spots, so they should go live as soon as they’ve been checked, not wait for a quiet month.
• Small changes. New prices, a new service, an extra field on a job form, a login for a new hire.
• New features. Bigger additions, like a customer portal or a crew phone app, should be quoted first, so you know the price before work starts.

Reference: CISA: Understanding Patches and Software Updates (opens in a new tab)

Who fixes bugs after launch?

Right after launch, the team that built it should, during a fix period written into your agreement. After that, it’s whoever you have a support plan with. If you never signed one, nobody has agreed to look after it. Each fix becomes a new job, priced and scheduled whenever the developer can fit it in, if they still answer.

If you launched a while ago with no plan, ask your developer for one in writing, using the list in the next section. If they’ve moved on, skip ahead to taking over software someone else built.

If you haven’t launched yet, plan for surprises. Real people start using the system in ways nobody tested. A customer types a phone number with dashes, a tech loses signal halfway through a job, the office runs its first month-end report.

So ask for a fix period written into the agreement, so bugs found right after launch are fixed at no extra cost. Ask what it covers, too: bugs only, or small changes as well. And ask what happens the day it ends: does a plan start, or are you on your own?

Then use that window well: have everyone do their real work in the new system from day one. Keep one shared list of anything odd: what they did, what they expected, what happened, and a screenshot. A list like that gets things fixed faster than a phone call a week later. If it’s a website, our website launch checklist covers what to test before you go live.

What should a support plan spell out in writing?

When the fix period ends, a support plan can take over. Plans vary a lot, so don’t compare them by monthly price alone. Compare what each one puts in writing. A good plan answers each of these:

• What’s covered. Which website, system and connections, and whether that means fixes, updates and small changes, or only some of them.
• Backups. Who makes them, how often, and whether anyone has tried restoring one.
• Reply times. How long until someone replies, and whether an urgent problem, like customers who can’t pay, gets a faster answer than a small change.
• How to ask. One email address or phone number, and the hours someone answers.
• Whose bugs you pay for. Whether bugs in the developer’s own code are fixed free or come out of your monthly hours.
• A monthly note. A short report of what was updated, fixed and changed, so you can see what you paid for.
• What costs extra. Where a small change ends and a quoted project begins.
• Who has the logins. Your domain and the apps your system connects to should stay in your name.
• How to leave. How much notice you give, and what you get when you go: the code, the logins, and short notes on how it fits together.

What happens if the developer disappears?

Developers change jobs, close up shop, or stop answering emails. If they held the only logins and were the only ones who knew how the system works, you’re stuck until someone new figures it out.

Three things protect you. Keep the owner logins for your domain, email, payments and accounting in your business’s name. Make sure you can get a copy of the code, and that the agreement says who owns it. And export your records to plain spreadsheet files every few months, so your data is safe whatever happens to the system.

We cover which logins to keep and what your agreement should say in who owns your software, your data and your domain. With those in hand, moving to a new team is a planned handover, not an emergency.

Taking over software someone else built

For example, a property manager with 40 units has a maintenance request app built by a developer who has since moved on. Requests still come in, but nobody has updated it in two years, and the login page now shows errors. The owner wants someone to look after it.

Before anyone changes the code, the new team should review it. Parts that their makers no longer update are a real risk, and CISA recommends retiring software that has reached that point. The review tells you what can be looked after as it is, what needs updating first, and what may be cheaper to rebuild. Expect it to cover three things:

• How it’s built. What it’s written in, where the code lives, and whether a test copy can be run safely.
• Who has access. Every login to the hosting, code, database and connected apps, including past staff and past developers who should be removed.
• What shape it’s in. Parts that are out of date or no longer updated, known bugs, and whether backups exist. Also, any step that only works because someone does it by hand.

Reference: CISA: Understanding Patches and Software Updates (opens in a new tab)

Questions to ask any developer about support before you sign

Ask these on the first call, then check that the answers are in the written agreement. Good answers are specific: a reply time, a number of hours, a list of what you get.

• What do you fix for free after launch, and for how long?
• What does a monthly plan cost, and what exactly does it cover?
• How fast do you reply, what are your hours, and is that written down?
• Are bugs in your own code fixed free, or do they use up plan hours?
• How do you check updates before they go live?
• If we part ways, what do you hand over, and how much notice do you need?

How we look after the software we build

Every project we launch includes 30 days of fixes, covering bugs and small changes at no extra cost. A monthly plan can pick up from there, priced in your quote. The price depends on what we look after, how many hours of changes you want and how fast you need replies. Bugs in code we wrote are fixed without using your hours, and anything bigger than a small change is quoted first.

Reply times are written into your plan before you sign. Calls run Monday to Friday, 7 am to noon Pacific, and we don’t promise 24/7 support. Each month you get a short note of what we updated, fixed and changed. Your domain and the apps we connect stay in your name, and hosting runs on our account, which you can take over after payment.

We also look after websites and software we didn’t build. We review it first: how it’s built, who has access and what shape it’s in. Then we tell you what we can look after. If something is broken now, a one-off fix costs $750–$3,000 and takes 1–⁠2 weeks.

The first call is free. After it, you get the plan price in writing within 48 hours, and a plan starts within a week. See how our website and software support works, or if the system doesn’t exist yet, start with custom business software.