Helper CTO Series 23 | From Basic Maintenance to Maintenance Plus Development: When to Move Up

"We already have maintenance, but the feature I want has been on the table for six months and nothing's happened." This usually isn't the vendor slacking off — it's a mismatch between the plan and the ask: your team is still doing that task by hand, and it's taken half a year. You didn't buy the wrong kind of maintenance — you're asking a plan built for "holding steady" to deliver results that need "moving forward." Here are three signals that tell you it's time to move up a tier, and this article also covers when to scale back down.

Basic Maintenance Is "Holding Steady," Not "Moving Forward"

Let's define the scope first. Basic maintenance holds the line — it doesn't push forward. It covers four things:

• Watching the server and handling issues before you notice them.
• Bug fixing: you report a problem, we track it down and fix it.
• Small tweaks: a text change, a field adjustment, a minor fix.
• Regular security updates, not just patching after something breaks.

It doesn't include new features, new modules, or a redesign — not because we're unwilling, but because the level of effort is a different tier entirely. The article on what's included and what isn't in the monthly fee draws that line in more detail.

Two Levels of Effort: Where the Difference Lies

Laid out as a table, it's easier to see which one fits where you stand:

All billed monthly — moving up or scaling down never requires re-signing a contract.

Three Signals It's Time to Move Up

Signal one: small requests start piling up. Last month you raised three items and two got done; this month you raise three more. Ask yourself:

• Of the changes I've requested in the last three months, how many are still undone?
• Are the undone ones "not urgent" or "can't be scheduled in"?
• If it's the latter, is every single one of them stuck waiting?
• A growing queue isn't anyone slacking off — it means the effort level isn't enough anymore.

Signal two: one thing has been stuck for three months. Not a pile of small tasks, but one mid-sized item stuck in limbo:

• Turning a report into an automatic email, connecting two systems, adding a lookup page.
• Bigger than a "small tweak," but not quite the scale of a whole project.
• It doesn't fit inside the monthly fee, but a standalone quote feels like overkill.

Signal three: the business has grown, but the system hasn't. Your company's operations have changed, but the system is still shaped the way it was built originally:

• Order volume is several times what it was, and the system starts slowing down or locking up at certain times.
• A new product line or storefront has no place in the system, so people cram it into a notes field.
• A partner asks "do you have an API?" and you don't know how to answer.
• Reports get slower to run, and coworkers start building their own separate spreadsheets.

The system isn't broken — it's fallen behind. The article why one-off outsourcing fails covers the other side of the same issue.

How to Move Up: Scaled by Size, Committed Monthly

Maintenance plus development capacity isn't a project quote — it's a fixed amount of engineering effort reserved for you every month: you set the priorities, we work through them in order. The difference is:

• No need to go through a quote, negotiation, and contract for every single thing.
• The same team does the work — they've already seen your system, so nothing needs re-explaining.
• Unused effort in a month doesn't roll over, so you naturally learn to prioritize what matters.
• If you want to stop or scale down, it takes effect next month — no need to wait for a contract to end.

The tier depends on the size of the queue and the system's own condition — the same task on a cleaned-up system takes far less effort. The article on three ways to calculate maintenance fees covers who this structure fits.

When to Scale Back Down

Moving up isn't a one-way street. There are three situations where we'd suggest scaling back to basic maintenance:

• The backlog is cleared, and the next few months only have day-to-day small changes left.
• The company has entered a slow season or a transition period, and the system doesn't need to move forward for now.
• For two or three months in a row, less than half of the reserved effort gets used.
• You now have your own engineer, so day-to-day small changes don't need to go outside.

Once scaled back, the same team still looks after the system. If you're thinking of taking on hosting and security updates yourself to save money, the article how much time doing it yourself actually costs is worth running the numbers on first — scaling back development capacity is usually a better deal than cutting basic maintenance.

How Nerdtechnic Helps You Adjust This Level

• We run a health check first before deciding the tier — quoting without one isn't something we do.
• Moving up or down both take effect monthly; you can stop anytime, no lock-in.
• Small items get done directly, without renegotiating cost every time.
• Takeover, maintenance, improvement, and ongoing development — the same team handles all four from start to finish.

What you need was never the pricier plan — it's the effort level that fits exactly.

Moving a system from "holding steady" to "moving forward" doesn't need a new vendor — it needs a different level of effort. Nerdtechnic maintains and continues developing your system as your Helper CTO — like an in-house tech lead, just not on your payroll. The first step is a 60-minute system health check: we just need to see the code, no production credentials required, and within 3–5 business days you'll get a one-page report you can actually understand. If you already have a backlog that never clears, let's look together at which tier to start from: Helper CTO: System Maintenance Plan.