FLUXOR HQ
Ongoing Support

Maintenance & Support

Maintenance is the ongoing work that keeps a site or application secure, current, and working after launch: patching, upgrades, monitoring, and fixes.

Software decays if nobody touches it. Dependencies pick up vulnerabilities, browsers change, third-party APIs deprecate endpoints, and performance drifts as content grows. We take that work on a retainer, with a monthly report so you can see what was done rather than taking it on trust.

Who this is for

  • Companies whose site or app was built by an agency or developer no longer available
  • Teams with no in-house engineer to own a production system
  • Businesses running an application with dependencies that have not been updated in a long time
  • Teams who want a known route to a fix when something breaks

When it's not a fit

  • You have an in-house team already doing this. You do not need us for it.
  • The system needs rebuilding rather than maintaining. We will tell you if a retainer is money spent holding up something that should be replaced.
  • You want new features rather than upkeep. That is project work, and mixing the two in one retainer means the upkeep is what gets dropped.
  • Nobody can give us access to hosting, repositories, or DNS. Without access we cannot be responsible for uptime.

What We Deliver

Monitoring & Uptime

Uptime checks, error tracking, and alerting configured so problems reach a person instead of sitting in a log.

Security Patching

Tracking advisories for your dependencies and applying patches, with the urgent ones handled out of the normal cycle.

Dependency Upgrades

Keeping frameworks and libraries current in small regular steps, so you never face one enormous migration.

Performance Work

Core Web Vitals and server response times measured over time, with the regressions traced and fixed.

Bug Fixes & Small Changes

A defined monthly allowance for fixes and small content or feature changes, with a clear route for reporting them.

Backups & Recovery

Backups configured and, more importantly, restores actually tested — an untested backup is not a backup.

Common Use Cases

  • Taking over a site or application from a previous developer
  • Ongoing upkeep where there is no in-house engineering team
  • Clearing a backlog of overdue dependency and framework upgrades
  • Fixing performance that has degraded as content grew
  • Setting up monitoring and alerting on a system that has none
  • Keeping a marketing site current between larger redesigns

Tech Stack

Next.jsReactNode.jsPostgreSQLVercelAWSCloudflareSentryGitHub ActionsDependabotLighthouse CIUptimeRobot

Outcomes you can expect

  • Known dependency vulnerabilities getting patched rather than accumulating
  • Outages you hear about from monitoring rather than from a customer
  • Upgrades arriving in small steps instead of one unavoidable rewrite
  • A written record of what was done each month

What you receive

Everything below is handed over to you. Code and infrastructure live in your accounts, not ours.

  • A documented handover audit: what exists, what is out of date, what is at risk
  • Monitoring and alerting configured, routed to a channel you watch
  • A patching and upgrade cadence, written down and adhered to
  • A monthly report: what was patched, what broke, what was fixed, what is next
  • A tested backup and restore procedure
  • A named route for reporting issues, and an agreed response expectation

Engagement models

Fixed-scope project

A defined deliverable at a fixed price, scoped up front. Best when you know what you need built and want a firm schedule and budget.

Best when: You know what you need built and want a firm budget and date.

Retainer

Ongoing delivery, maintenance, or advisory billed monthly. Best for continuous improvement after launch, or when priorities shift faster than a fixed scope allows.

Best when: The work is continuous and priorities shift faster than a fixed scope allows.

Extended team

Our engineers working inside your team, your process, and your repositories. Best when you have the roadmap but not the capacity or the specific skills.

Best when: You have the roadmap but not the capacity or a specific skill.

Frequently asked questions about Maintenance & Support

Monitoring and alerting, security patching, dependency and framework upgrades, performance work, backups with tested restores, and an agreed monthly allowance for bug fixes and small changes. You get a monthly report showing what was patched, what broke, and what was fixed.

Yes, and that is most of this work. We start with a handover audit covering what exists, what is out of date, and what is at immediate risk. You see that report before committing to a retainer, so you know what you are asking us to look after.

The code repository, hosting and deployment, the domain and DNS, and any third-party services the system depends on. Without all of those we cannot be responsible for uptime, so we would rather say that up front than accept a retainer we cannot deliver on.

No, and that separation is deliberate. Retainers cover a monthly allowance for bug fixes and small content or feature changes. Substantial new features are scoped as separate project work, because when upkeep and new features share one budget, the upkeep is always what gets dropped.

Because dependencies accumulate published security vulnerabilities whether or not you change anything, and browsers and third-party APIs move underneath you. Small regular upgrades are routine; two years of skipped upgrades becomes a migration project, which is what we are avoiding.

Discovery. We agree the goal, review whatever exists already, and produce a written scope: what will be built, in what order, what you will receive, and what we need from you. It ends with a plan you can approve, amend, or take elsewhere.

The outcome you want and how you will judge it, access to any existing code, designs, hosting, and analytics, one person who can make decisions, and any hard constraints — a fixed launch date, a required stack, compliance obligations. Missing pieces we can work around; an unnamed decision-maker we cannot.

Both. Our published work spans early-stage products and established companies, and our smallest engagements are single fixed-scope projects. What matters is that someone on your side can make decisions and that the problem is defined well enough to scope, not company size.

Yes, as a retainer covering monitoring, security patching, dependency upgrades, performance work, and a monthly allowance for fixes and small changes. You get a report each month showing what was done. It is a separate engagement from the build, so upkeep does not compete with feature work.

Engineering and design work is delivered remotely, so location is not a constraint for those. Our in-person work — hackathons, builder houses, developer meetups, and campus programmes — runs in Delhi, Bangalore, Hyderabad, and Mumbai, plus university campuses across the country.

You get a written summary of what we understood, a proposed scope broken into phases, what each phase delivers, and the engagement model we would recommend. If we think you should buy something off the shelf or not build yet, the summary says that instead.

Hand over maintenance to FLUXOR

Tell us what you are running and who built it. We will audit it, tell you what needs attention first, and propose a retainer that fits.