Internal app portfolio review before a busy quarter

Why this gets messy fast

Most tool sprawl starts with a reasonable shortcut. A team needs a tracker, a form, or a small script, so someone builds one in an afternoon. It works, people rely on it, and then nobody stops to ask where it belongs or who should maintain it.

That pattern repeats team by team. Finance keeps a forecasting spreadsheet. Ops adds a form for approvals. Sales saves a script that cleans exports before Monday meetings. Each tool solves a real problem, but the company ends up with a patchwork that grew without a map.

The mess gets worse because most companies never keep one complete list. Some tools live in shared drives. Some sit in personal folders. Some run from one person's laptop. Others hide inside old automations that still send emails every morning. If you ask three managers for the full set, you usually get three partial answers.

Ownership is where small tools become risky. People trust a spreadsheet or script because it has

What belongs in the review

Start broader than official software. The tools that usually cause trouble are the ones people built to save 15 minutes and then kept using for two years.

For a first internal app portfolio review, include anything that stores business data, changes it, routes work, or produces numbers people trust. If a team depends on it every week, put it on the list even if nobody calls it an app.

Shared spreadsheets deserve a close look. A simple file with raw data is one thing. A spreadsheet with formulas, cross-sheet references, imports, pivot tables, or macros is closer to a small production system, especially when several people edit it or another report pulls data from it.

Forms belong in the review too. Many companies rely on forms for purchase requests, leave approvals, customer intake, incident logging, or monthly updates. Once a form sends emails, creates tasks, updates a sheet, or kicks off an approval chain, a small setup error can block work for a whole team.

Then there are the scripts. These often hide in plain sight because they run quietly in the background. If someone wrote a script to clean CSV files, merge exports, rename documents, move records between systems, or generate a report on a schedule, review it even if only one person touches the code.

Personal databases, dashboards, and trackers also count. A sales manager may keep a private forecast tracker. Finance may rely on a homemade database for budget checks. Ops might use a dashboard that only one analyst knows how to fix. If one person owns the logic and other people rely on the result, the risk is real.

A short test helps:

• Does it change or combine data?
• Does it trigger emails, approvals, or follow-up work?
• Do other people depend on its output?
• Would work slow down if the owner took a week off?
• Did one team adopt it without central approval?

That last point matters more than many leaders think. Team-level tools bought on a company card, built in a shared drive, or passed around by copy and paste often become part of daily operations before anyone reviews them.

If people would scramble when it fails during the last week of the quarter, it belongs in the review.

How to build the first inventory

Start with weekly reality, not the official software list. The tools that crack under pressure are often the ones nobody planned for: a spreadsheet a manager updates every Monday, a form tied to a shared inbox, or a script that only one analyst knows how to run.

Ask each team for every tool they use in a normal week. Keep the question simple: what do you open, edit, submit, or run to get work done? Sales, finance, ops, support, and HR will each remember different things, and that is exactly what you need.

Do not stop at named apps. Export lists from form builders, automation accounts, SaaS admin panels, shared drives, and script folders. Many companies think they use 20 tools, then find 70 once they count Google Sheets, Excel files, Airtable bases, Zapier flows, small Python scripts, and dashboards built by one person for one process.

Put everything into one inventory sheet with one row per tool. Keep the columns simple:

• tool name
• owner or team
• regular users
• plain English purpose
• where data starts and where it ends

That last part tells you how work actually moves. If data starts in a form, lands in a spreadsheet, then gets copied into payroll or invoicing, you already have several points where errors can spread. Write down the full path, even if it feels obvious.

Some entries will look messy, and that is fine. "Budget tracker, owned by Priya, used by finance and ops, pulls data from order forms, ends in the monthly close file" is enough for the first pass. In an internal app portfolio review, coverage matters more than perfect formatting.

If two teams use the same tool for different jobs, keep one row and note both teams. If nobody can name the owner, mark it as unknown instead of guessing. Unknown ownership is useful information because it usually points to a tool that can fail quietly.

A good first inventory looks plain. That is a strength. When the quarter gets busy, a plain list helps you see what exists, who depends on it, and which tools need a closer check before they cause trouble.

How to sort tools by risk and usage

Do not start with a complicated model. For a first internal app portfolio review, a blunt score works better than a clever one. You need a fast way to see which tools can hurt the business if they fail, and which ones people touch every day.

Use a simple score

Give each tool two scores: risk and usage.

• Score impact from 1 to 5 based on what happens if the tool stops working. A 1 is a minor annoyance. A 5 means payroll, invoicing, customer delivery, or month-end work stalls.
• Score dependency from 1 to 5 based on how many people rely on it. One person's helper sheet is not the same as a form used by three teams.
• Score frequency from 1 to 5 based on how often people run it or update it. Daily tools usually deserve more attention than something used once a quarter.
• Add a risk flag if the tool touches money, customer data, employee data, or compliance records. That flag should push it up the list even if only a few people use it.

Keep the math simple. Many teams use risk as impact plus data sensitivity, and usage as dependency plus frequency. You do not need perfect scoring. You need consistent scoring.

Then place every tool on a basic grid. High risk and high usage tools go in the top right. Fix those first. They break loudly and at the worst time. High risk but low usage tools still matter, especially if finance, legal, or security depends on them during a deadline. Low risk and high usage tools usually need cleanup, owner names, and backup steps. Low risk and low usage tools often belong in an archive or retirement pile.

A small example makes this clearer. A spreadsheet that tracks invoice approvals may only update twice a week, but if one broken formula delays payments, risk is high. A team lunch signup form may get daily traffic, but risk is low. Sort them that way, and the next steps become obvious.

What to check in each tool

Most internal tools do not fail because one formula breaks. They fail because nobody knows who can change them, who covers for the owner, or how to undo a bad edit.

Start with access. Write down who can edit the spreadsheet, form, script, or database right now. Use real names, not job titles. You want the current list of editors, admins, and anyone who can change logic or data. Shared logins deserve extra suspicion because they hide who changed what.

Then check what happens when the owner disappears for a week. Vacation is enough to expose a weak setup. Ask a plain question: who can run this tool, fix a small issue, and answer user questions if the main owner is away? If the answer is "only Sam knows how," treat that tool as fragile.

Version recovery matters more than teams expect. Find out whether people can restore an older version without panic. A spreadsheet may have history, a script may live in Git, and a small database may rely on backups. Do not trust assumptions. Ask someone to show the last restore test, or at least confirm the last time they rolled back a change.

Manual work around the tool tells you how likely it is to break under pressure. Many tools still depend on someone exporting a CSV, cleaning columns, copying values into another file, sending an approval message, or running a script from a laptop. Those steps look harmless in a quiet week. During a busy quarter, they turn into delays and mistakes.

Capture a few facts in the inventory:

• current editors and a backup owner
• whether the team can restore a prior version
• manual steps that happen before or after the tool runs
• the last date someone tested the full workflow

That last point often reveals the real risk. A tool may open fine every day and still fail when the team runs the whole process. For an internal app portfolio review, this check helps you spot the tools that look stable but crack when volume goes up.

A simple example from finance and ops

A growing company often finds its weak spot in a place that looks harmless. Finance closes monthly reports with three linked spreadsheets. Ops collects requests through a form, then pushes them along with email rules that move messages to the right inbox. On a normal week, the setup feels good enough.

The trouble starts when both teams depend on the same numbers. Finance needs clean totals for the close. Ops needs current request data to plan orders, staffing, or delivery dates. Those two data sets meet in a small script that one contractor wrote months ago.

That script joins the form export from ops with the finance sheets and spits out a file people trust. Nobody else knows how it works. It runs from the contractor's machine, the field names changed once without warning, and the team only notices a problem when totals look off.

A first internal app portfolio review would score this setup high on usage and high on risk. Usage is high because both teams touch it often and rely on the output to make decisions. Risk is high because one person owns the logic, the handoff is partly manual, and a failure lands right in the middle of close.

The red flags are easy to spot:

• One contractor is the only person who can fix the script
• Three linked sheets can break when someone renames a tab or column
• Email rules are hard to see and easy to forget
• No shared log shows whether the data join ran correctly

The team does not need a huge rebuild before quarter end. It just needs to remove the weakest handoff. A practical fix is to move the script to a shared location, document the inputs, assign a backup owner, and replace the email rule chain with one clear intake point that both teams can check.

That change will not make the process pretty. It will make it safer. When the busy quarter hits, finance can close without chasing a contractor, and ops can trust that the requests in the report match the requests that actually came in.

Mistakes that waste the review

Most teams lose time before they find a single real risk. They open a blank sheet, debate columns, and try to design the perfect tracker. That usually slows the work more than it helps. A rough list with tool name, owner, users, and purpose is enough to start.

Names cause another pointless fight. People spend half an hour deciding whether something is a workflow, a report, a script, or a mini app. It does not matter yet. If nobody can say who owns it, who uses it every week, and what breaks if it stops, the label will not save you.

The most dangerous tools often look too small to matter. One spreadsheet that only payroll touches, one script a sales manager runs on Fridays, one form built by an ops lead three years ago - these are the ones that fail at the worst time. If only one person understands a tool, put it on the list first, not last.

A spreadsheet risk assessment also goes wrong when managers score risk from a meeting room. Daily users know where people paste data by hand, where exports fail, and which file everyone is afraid to touch. Five minutes with the person who uses the tool every day will beat a neat scorecard built from guesses.

Another common mistake is pushing obvious single points of failure to a later phase. Teams say, "We will fix that after the review," even when they already know the problem:

• one person holds the password
• one file lives on one laptop
• one script runs with no backup
• one approval step depends on one employee being online
• one data source has no fallback

Those issues do not need more discussion. Mark them early and give them a deadline.

The internal app portfolio review should help you see where work can stop during a busy quarter. If the review turns into a taxonomy exercise, it is drifting. Keep it plain, talk to the people doing the work, and treat fragile one person tools as urgent while you still have time to act.

Quick checks before you lock the list

Before you freeze the list, clean up the parts that usually stay vague. Most review work falls apart at the end because a tool has three unofficial owners, no fallback, and no deadline for the fix everyone agreed on.

Start with ownership. Every tool needs one named person who can answer simple questions fast: who uses it, what breaks if it fails, and who approves changes. A team can support the tool, but one person must own the record. Shared ownership sounds fair and usually creates silence.

High-risk tools need a backup plan before the busy quarter starts. That plan does not need to be fancy. A daily export, a read-only copy, a manual workaround, or a second person who knows the process is often enough. If payroll, reporting, approvals, or customer operations depend on one spreadsheet or script, do not leave recovery to memory.

Teams also need a clear line around changes. Some tools should stay frozen during the quarter unless the owner and manager approve an update. This matters most for tools that feed finance, operations, or customer delivery. A small edit in the wrong sheet can ripple through three teams in a day.

For the riskiest tools, write fix dates and owner names in plain language. Avoid notes like "review later" or "team to discuss." Put down who will act, what they will change, and by when. If nobody wants their name next to the tool, that is useful information too.

A one-page summary helps leaders read the whole picture without digging through tabs. Keep it tight:

• tool name and business use
• named owner
• risk level
• backup status
• next action with date

A short example makes the gap obvious. Finance may rely on a closing workbook built by one analyst, while ops runs a script that only one manager understands. Lock the workbook owner, assign a backup, freeze changes to the ops script, and put real dates on both fixes. That takes less time than explaining a missed deadline in the middle of a packed quarter.

What to do in the next two weeks

Start with the tools that can cause a missed payment, a bad report, or a broken handoff between teams. Leave the harmless cleanup for later. A growing company does not need a perfect list right away. It needs fewer ways for a busy quarter to go sideways.

For the first internal app portfolio review, keep the work tight and practical:

• Pick the top 5 to 10 tools with the highest business impact.
• Give each one a named owner.
• Fix one obvious failure point in each tool.
• Move fragile scripts into a supported workflow.
• Set a short monthly check for anything new that appears outside approved systems.

That third step matters more than people think. One spreadsheet with manual copy and paste, one form that emails the wrong person, or one script that runs only from a single laptop can create hours of cleanup when volume spikes.

Fragile scripts deserve special attention. If one person runs a script from their machine, the company does not really own that process. Move it into a scheduled job, a shared repo, or another supported setup that the team can see and maintain. Even a simple handoff note and one backup owner can cut risk fast.

A small finance and ops example makes this clear. If finance closes numbers in a spreadsheet and ops updates inventory through a local script, do not spend next week renaming tabs or cleaning old folders. First make sure the numbers come from the right source, the script has an owner, and someone else can run it if the usual person is out.

Then make the review repeatable. Put a 30 minute monthly check on the calendar. Ask each team one simple question: what new spreadsheet, form, script, or side tool did you start using this month? That catches shadow tools early, before they turn into dependencies.

Keep the process small enough that teams will do it again. If the list keeps growing, owners stay unclear, or automation choices pile up, Oleg Sotnikov can help as a fractional CTO. This is the kind of work where clear ownership and a few solid decisions save a lot of avoidable pain.