How to create a technical improvement backlog

Every business system that lives longer than a year accumulates a second, invisible to-do list: the workarounds nobody fixed, the report that takes forty seconds too long, the integration that silently retries three times before it works. Most teams only talk about this list when something breaks. By then it's an emergency, not a plan.

A technical improvement backlog turns that invisible list into a visible, prioritized, budgeted part of how you run your software — the same way your feature roadmap is visible. This article walks through how to actually build one, what belongs in it, and how to keep it alive instead of letting it rot in a spreadsheet nobody opens.

What is a technical improvement backlog, exactly?

It's a maintained, prioritized list of known weaknesses in your business software that don't need to be fixed today, but will cost you more the longer they're ignored. Think of it as separate from your feature backlog (new things the business wants) and your bug tracker (things that are actively broken right now).

Typical entries look like this:

• "The nightly sync between FileMaker and Exact Online has no error logging — when it fails, nobody finds out until a customer complains about a missing invoice."
• "The quote-approval script was written for 3 approval levels; sales now uses 6, and the workaround is copy-pasted logic in four places."
• "Klai-based AI lookups in the support module call the OpenAI API directly from the client with no caching or rate limiting — this will get expensive and slow as ticket volume grows."
• "The FmBetterforms web layout for the customer portal hasn't been touched since the 2021 redesign and breaks on newer mobile browsers."

None of these are on fire. All of them are debt collecting interest.

Why can't you just fix things as you notice them?

Because "fix it when we notice" always loses to "ship the next feature the sales team is asking for." That's not a discipline problem — it's an incentive problem. Feature work has a visible business case attached to it (a customer, a deal, a deadline). Technical debt rarely does, until it does — usually in the form of an outage, a security incident, or a developer telling you a two-day task now takes two weeks because of what's underneath it.

A backlog fixes the incentive problem by making the debt visible, sized, and schedulable, so it can compete for the same planning attention as features instead of losing by default.

What actually belongs in the backlog?

Not everything that annoys a developer belongs here. Use these categories as a filter:

1. Structural debt — schema shortcuts, duplicated business logic, tables or scripts that grew organically without a redesign. Example: a FileMaker solution where "customer type" logic is checked with If statements scattered across 12 scripts instead of one central function.
2. Integration fragility — connectors and API calls that work today but have no monitoring, retry logic, or versioning plan. Example: an API connector to a shipping provider that will break silently the day that provider deprecates its v1 endpoint.
3. Performance decay — things that were fast with 500 records and are sluggish with 50,000. Example: a dashboard summary field recalculating on every layout load instead of being cached.
4. Security and access gaps — accounts with more privilege than they need, unencrypted exports, hardcoded credentials in a script.
5. Tooling and dependency risk — reliance on a plugin, library, or AI service (like an unmanaged Klai integration) with no fallback if it changes pricing, breaks, or gets discontinued.
6. Documentation gaps — the one custom module only one developer understands, with no comments and no spec.

If an item doesn't fit one of these, it's probably a feature request or a bug — send it to the right list instead.

[[IMAGE:left|a funnel sorting issues into feature backlog, bug tracker, technical debt backlog]]

How do you find what should be on the list?

You won't find most technical debt by asking "does anyone have technical debt to report?" It surfaces through specific triggers:

• Code review: every pull request or script change is a chance to log a "noticed but didn't fix" item.
• Support tickets: recurring complaints about the same slow report or confusing screen are debt signals in disguise.
• Onboarding a new developer: what they find confusing or ask "why is it built this way?" about is exactly what should be documented and backlogged.
• Post-incident reviews: after any outage or data issue, ask what underlying weakness allowed it, not just what the immediate fix was.
• Scheduled technical audits: a quarterly pass through core scripts, integrations, and layouts specifically hunting for fragility, even if nothing is currently broken.

How do you prioritize a technical backlog?

Unlike feature requests, technical items don't have an obvious business sponsor pushing for them, so you need an explicit scoring approach. A simple, workable model:

Impact × Likelihood × Cost-of-delay, scored roughly on a 1–3 scale each:

• Impact: how bad is it if this goes wrong, or how much time does it waste per week?
• Likelihood: how likely is it to actually cause a problem in the next 6–12 months?
• Cost-of-delay: does this get more expensive to fix the longer you wait (e.g. more code built on top of the shortcut), or does it stay flat?

Multiply the three, and you get a rough priority order. It won't be perfect, but it's far better than "whoever complains loudest gets fixed first."

How do you write a good technical backlog item?

A vague entry like "clean up the invoicing module" will never get scheduled, because nobody can scope it. Write each item like a mini-brief:

1. What is it, concretely? — name the script, table, layout, or integration.
2. What breaks or degrades if it's not fixed? — a real scenario, not a generality.
3. Rough effort estimate — hours or days, even if it's a guess.
4. Suggested fix or direction — even a one-line idea saves re-thinking it later.
5. Who flagged it and when — for context and to avoid "is this still relevant?" debates six months later.

Example of a well-written entry:

Item: Order-sync error handling. What: The FileMaker → ERP order export script has no logging when the API call fails; it just silently skips the record. Risk: Orders have gone missing twice in the last quarter without anyone noticing for days. Effort: ~1 day. Fix direction: Log failures to an error table and trigger a Slack/email alert. Flagged by: support team, after the March incident.

How much time should you actually spend on it?

A common and workable rule: reserve 15–20% of development capacity every sprint or month specifically for technical backlog items, separate from feature work. Treat it like a fixed cost, not a "if there's time left over" bucket — because there is never time left over.

Some teams instead do it in blocks: one week out of every six or eight dedicated purely to backlog burn-down. Either model works; what matters is that it's scheduled, not improvised.

[[IMAGE:right|a calendar showing a recurring reserved block for technical debt work]]

Who should own the backlog?

Someone specific — usually the lead developer or IT manager — should own grooming it: reviewing new items, closing stale ones, re-scoring priorities quarterly. Without an owner, the backlog either grows unmanaged (everything gets added, nothing gets removed) or dies from neglect (nobody updates it after the first month).

Business owners and CEOs don't need to review every line item, but should see a short quarterly summary: what got fixed, what's still open, and what's the single riskiest thing still sitting on the list. That keeps technical debt visible at the level where budget decisions actually get made.

What tools should you track it in?

You don't need specialized software. Good options, roughly in order of formality:

• A shared spreadsheet with the fields above — fine for small teams.
• A dedicated list or board in whatever project tool you already use for features (Trello, Asana, Jira, Monday), tagged clearly as "technical debt" so it's filtered separately from feature work.
• A lightweight custom-built tracker inside your own FileMaker system — which has the advantage of living right next to the system it's tracking, and can even link backlog items directly to the scripts, layouts, or tables they describe.

The tool matters far less than the habit of actually reviewing it.

How does this connect to keeping software maintainable long-term?

A technical improvement backlog is really the operational mechanism behind a bigger idea: that maintainability isn't something you achieve once during a rebuild, it's something you actively manage every month as the system keeps growing. Our related guide on how to keep business software maintainable as it grows covers the broader strategy this backlog supports — this article is the concrete "how" for one piece of that strategy.

Quick checklist: is your technical backlog actually working?

• Does it exist somewhere other than in one developer's head?
• Is every item written concretely, with a real risk and rough effort attached?
• Is there a named owner who grooms it regularly?
• Is time reserved for it in every planning cycle, not just "when there's slack"?
• Do business owners see a summary of it at least quarterly?
• Are integration and AI-tool dependencies (APIs, connectors, services like Klai) included, not just internal scripts?
• Are old items ever closed as no-longer-relevant, or does the list only ever grow?

FAQ

Isn't this just another name for a bug list? No. Bugs are broken now. Technical debt items are working now but degrading, fragile, or costly to extend — they're a bet against future problems, not a report of a current one.

Won't a visible debt list make our software look badly built to stakeholders? The opposite tends to be true. A team that can point to a managed, prioritized list of known risks looks far more in control than one that insists everything is fine until an outage proves otherwise.

How big is too big for a backlog? If it has more than 50–60 open items, it's a sign items aren't being closed or prioritized ruthlessly enough. A healthy backlog is actively shrinking on the well-understood items and growing slowly on genuinely new discoveries — not just growing.

Does this apply to systems we didn't build ourselves? Especially those. Inherited or legacy systems (including older FileMaker solutions built by a previous developer) almost always carry more hidden debt than a young, actively developed one — auditing them into a backlog is often the first useful step before touching any code.

If you recognize your own system in these examples — a sync job with no error visibility, a script rewritten four times by four developers, an AI integration nobody's monitoring — that's usually a sign it's time for a structured look, not another quick patch. Loggix helps teams turn that kind of hidden risk into a concrete, prioritized plan, whether that means auditing an existing FileMaker solution, hardening an API connector, adding monitoring around an AI tool like Klai, or simply sitting down together to map out what should be fixed first and what can wait.