Skip to content
fullstack.sg
Menu

After launch

Keeping a liveapplication up todate and working

Who it’s for
Teams without in-house developers, Agencies after launch, Product teams with a backlog
To start, send
Access to the code and hosting
Pricing
Quoted for each project

Bug fixes, security updates, broken integrations and small improvements for applications that are already live.

Discuss a projectHow pricing worksOne-pager for your proposal
  1. Interface (not central to this service)
  2. Logic (not central to this service)
  3. Data (not central to this service)
  4. Integrations (used by this service)
  5. Deployment (used by this service)

Is this for you?

A live application doesn’t stay finished. Security patches come out, other services change their APIs, browsers change, and the business keeps asking for small tweaks. Each one is minor on its own. Leave them for a year or two and every change becomes slow and risky.

Maintenance is the regular work that stops that happening. We agree what’s covered and how you send us requests, then work through them on a regular schedule and tell you what changed.

Who it’s for

  • Teams without in-house developers

    Your application works, and you need someone to keep it that way.

  • Agencies after launch

    A client wants ongoing support for something you built, and you’d rather not tie up a developer.

  • Product teams with a backlog

    Your developers are busy with new features, so small fixes and updates keep getting pushed back.

Usually, one of these has just happened

  • Software updates have been put off for months, and the backlog keeps growing.
  • Small requests sit for weeks because nobody’s responsible for them.
  • An integration broke after a provider changed something, and nobody noticed for days.
  • The site launched and the developers left, with nothing arranged for afterwards.

The kinds of work maintenance covers

Most maintenance falls into a few recurring kinds of work. How much time each gets depends on the application. What matters is that none of them is left until it’s urgent.

Security and updates

Every cycle

Security advisories · Patch and minor updates · Runtime versions · Expiring certificates and keys

Fixes

As reported, by priority

Bugs from users · Errors from monitoring · Browser and device issues

Integrations

When providers change

Retired API versions · Changed notifications · New passwords and keys

Improvements

From your list

Small features · Wording and layout changes · Speed fixes · Admin shortcuts

Planned upgrades

Quoted separately

Major framework versions · Database migrations · Hosting changes

Change log, one monthIllustrative
  • Security and updates

    Patched the image library after a published advisory

    Advisory affected file uploads on the admin pages

  • Security and updates

    Updated framework minor version and 14 dependencies

    Routine; tested on staging first

  • Fixes

    Booking emails no longer show times in UTC

    Reported by front-desk staff

  • Integrations

    Moved the CRM sync to the provider’s new API version

    Old version retires at the end of the quarter

  • Improvements

    Added CSV export to the bookings list

    Requested by the client’s finance team

Written for forwarding: plain language, one line on why.

What you get

  1. A maintenance plan

    What’s covered, how you send requests, how they’re prioritised and how much time is set aside, agreed in writing.

  2. Regular updates

    Framework and package updates, with security fixes first. Where there’s a test server, updates are checked there before going live.

  3. Fixes and small improvements

    Worked through from a shared list, in the order you choose.

  4. A change log

    A plain-English summary of what changed and why, ready to forward to your team or your client.

Before we start

What we’ll need from you

Access to the code and hosting
Including any test server. If there isn’t one, setting it up is often the first job.
One place for requests
Your issue tracker, or one we set up, so requests don’t get lost in email and chat.
Someone who sets priorities
For when there’s more to do than time to do it.
Access to any monitoring
Error and uptime alerts help spot problems before your users do.

Decisions we’ll help you make

Set hours each month, or pay as you go?

Set hours suit applications that change often. The cost is predictable and updates don’t slip. Paying as you go suits a stable application that rarely needs anything. We’ll suggest one based on how yours is used.

How quickly are issues handled?

That depends on what we agree, and we’ll write it down. We don’t publish standard response times, because they depend on what we’re supporting and when.

Update everything, or only what’s needed?

Small, regular updates are cheaper and safer than occasional big ones. Major framework upgrades are planned and quoted separately.

How the work runs

  1. 1

    Get to know it

    If we didn’t build it, a short review of the code first.

  2. 2

    Agree the plan

    What’s covered, how requests reach us, and how often we work on it.

  3. 3

    Work through the list

    Updates, fixes and improvements, in your order of priority.

  4. 4

    Report back

    What changed, and what’s coming up next.

Usually included

  • Bug fixes and small feature changes
  • Security, framework and package updates
  • Fixing integrations when other services change
  • Monitoring and investigating errors

Not included unless agreed

  • Large new features, which are quoted separately
  • Round-the-clock cover, unless agreed
  • Content editing in a CMS
  • Hosting costs and third-party subscriptions

When the problem is inside another company’s service, the fix depends on them. Outages at your hosting provider are out of our hands too, though monitoring helps spot them quickly.

The full process, from first message to handover, is on How we work.

How the costis worked out

We price maintenance either as set hours each month or as an estimate for each request. If we didn’t build the application, we’d look through it briefly before quoting.

After a first call, we send a written quote that says what’s included and what isn’t.

What affects the cost

  1. How big and complicated the application is
  2. How often you need changes
  3. How many integrations need looking after
  4. How far behind its software updates are
  5. Whether we built it or are taking it over

Questions

Can you maintain an application you didn't build?

Yes, once we’ve had a short look at it. If it’s in a bad way, we’ll say so and suggest making it safe first.

What happens to unused time in a cycle?

We agree that at the start, so you know where you stand.

Can our agency resell maintenance to our client?

Yes. We can work behind your agency, and the change summaries can be written for you to forward under your name.

Do you monitor the application?

We can set up error and uptime alerts in your accounts and check them as part of the regular work. Someone watching it around the clock isn’t included unless we agree it.

Need someone looking after a live application?Discuss a project →Tell us what it is, what it runs on and what’s been waiting. We’ll suggest an arrangement that fits how often it needs work.