Startup portfolio health checks you can finish in 5 days

Why portfolio problems stay hidden

Most portfolio problems do not start as big failures. They start as small delays, repeated customer complaints, and workarounds the team quietly accepts as normal.

Board updates rarely show that mess. Founders compress a noisy month into a clean story, so daily friction disappears behind a few charts, a product demo, and a line like "launch moved by two weeks." If the same slip happens every month, those two weeks add up fast.

Revenue can hide trouble for longer than people expect. A startup can still close deals or renew customers while delivery slows down, bugs stay open, and product dates keep moving. On paper, the business looks steady. Inside the company, the team stops trusting its own plan.

Support pain usually shows up even earlier. Customers rarely cancel after the first broken workflow or slow reply. They complain, ask for manual fixes, and use the product less. By the time churn appears in a report, the support team may have carried the problem for months.

AI adds another blind spot. Teams often say they "use AI," but that can mean almost anything. One engineer using a coding assistant is not the same as a repeatable workflow that saves hours every week. If nobody checks output quality, speed, and error rates, AI becomes a label instead of a result.

That is why a portfolio check needs to look past polished updates and ask a simpler question: what is getting harder inside the company, even while the headline numbers still look fine?

What to collect before you start

A fast audit falls apart when you ask broad questions and get polished answers back. Ask for raw, recent material instead. Two or three months is usually enough to show how a startup ships, spends, supports customers, and uses AI.

You can gather most of it in one shared folder. Ask every company for the same items so the comparison stays fair:

• release notes, deploy logs, or changelogs from the last 8 to 12 weeks
• the last few monthly bills for cloud, hosting, tools, and software subscriptions
• support data from the same period, including ticket volume and repeated complaints
• a plain list of AI tools in use, who uses them, and what they use them for
• one named owner who can answer follow-up questions within a day

If a company cannot produce this basic material quickly, that tells you something on its own. Teams that run on memory, chat threads, and habit have a harder time spotting small problems before they turn into missed releases or rising costs.

Be strict about recency. Old board decks and annual summaries smooth over the details you actually need. Look at what happened last Tuesday, not what the team planned six months ago.

Run the audit in five days

Five days is enough if you keep the scope tight and ask every company for the same inputs. You are not trying to produce a perfect startup audit. You want a clean, comparable view of delivery, cost, support pain, and current AI use.

A simple five-day rhythm works well:

1. Collect the facts. Ask for one recent roadmap, release history, current team shape, cloud and software bills, top support issues, and any AI tools already in use.
2. Check delivery signals. Look at what shipped, what slipped, and what keeps getting stuck. One blocked approval step or one missing owner can slow a team more than a messy sprint board.
3. Review cost lines. You do not need a full finance pass. Look for duplicate tools, idle environments, oversized servers, and licenses nobody touched in weeks.
4. Read support pain and AI workflows side by side. Recent customer complaints show where the product breaks down. AI use matters only when it saves real time in coding, testing, support, or internal operations.
5. Score each company on one sheet and write the next action. Keep it blunt: what looks healthy, what needs attention now, and who owns the fix.

Keep it lightweight. If you spend half the week debating one metric, you lose the comparison across the rest of the portfolio.

A good final sheet is short. Give each company a simple rating for delivery, cost, support, and AI use, then add one note with the highest-payoff action for the next 30 days.

Check delivery without reading every task

You can learn a lot from three weeks of plans, release notes, and bug tickets. Ask for the last two or three planning cycles, then compare what the team said it would ship with what users actually got.

Do not get lost in story points or long arguments about estimates. Plain counts work better. If a team planned 12 meaningful items and shipped 5, that gap tells you more than a detailed sprint board.

A quick delivery check usually comes down to four signals: planned items versus shipped items, releases that slipped or paused, bugs that came back after a fix, and the number of people who can approve a production change.

Look for patterns, not a single bad week. One delayed release may come from a holiday, a customer request, or a server issue. If releases slip every other week, the team probably commits too much, finds problems too late, or waits on one person to unblock work.

Recurring bugs are another strong sign. If the same payment bug, login bug, or sync issue reopens two or three times, the team is probably patching symptoms and moving on. That slows delivery because engineers keep circling back instead of finishing new work.

Approval flow matters more than many founders expect. Ask who can say yes to a production change. If only one senior engineer or founder can approve every release, work pauses when that person gets busy, travels, or loses context.

A simple comparison makes this obvious. Team A planned 10 items, shipped 8, and had one reopened bug. Team B planned 14, shipped 6, paused two releases, and needed founder approval for every deploy. Team B does not need more tickets. It needs tighter planning and a simpler release path.

End this section with one sentence on your sheet: can this team turn planned work into shipped work without constant rework or waiting?

Check infrastructure cost without a full finance review

A fast cost pass is often enough to spot waste. You do not need a full finance review. You need the last month of invoices, the cloud bill, and a list of software vendors.

Start by grouping costs into three buckets: hosting, tools, and contractors. Hosting covers cloud servers, databases, storage, CDN, and backups. Tools covers product analytics, monitoring, support software, CI, design, and chat. Contractors covers freelancers, agencies, and part-time specialists.

That simple split makes the problem easier to see. If hosting is low but tool spend is high, the issue may be tool sprawl. If contractors cost more than payroll for the same work, the company may be paying to patch gaps it should fix inside the team.

Next, look for anything nobody used in the last 30 days. Ask for login data, deployment history, or even a screenshot from the admin panel. If nobody logged in, pushed code through it, answered customers with it, or reviewed alerts from it, put a question mark next to the cost.

Then mark any spikes. A higher bill is not always bad. A launch can raise traffic, and an outage can trigger extra logs, cloud usage, or emergency contractor hours. What matters is whether the team knows why the spike happened. If they cannot explain it in one sentence, dig deeper.

Duplicate tools are common, and they add up quickly. One company may pay for two monitoring tools, two analytics products, and a separate CI service on top of build features it already has. Another may still pay for an old support platform after moving the team somewhere else. This is where a quick infrastructure cost review often pays for itself.

End the section with plain notes: keep, downgrade, merge, or cancel. That is enough to show which startups need a deeper look.

Check support pain from recent customer issues

Start with the last 30 to 50 support tickets. That sample is usually enough to show what customers hit again and again without dragging you into old noise.

Read them quickly, but tag them by theme instead of by customer name. One angry customer can send five messages about the same problem. If you count messages instead of themes, you will overrate one issue and miss the pattern.

The usual themes are simple: login and access problems, billing confusion, broken workflow steps, missing product guidance, and bugs that need staff help.

Look for work the support team repeats every week. If agents keep resetting accounts, fixing imports by hand, changing settings for users, or explaining the same setup step, the product is pushing manual work onto the team. That is support pain, but it is also product debt.

Then compare first response time with full resolution time. Fast replies can hide a slow fix. A team may answer in 12 minutes, then take 4 days to solve the case because support needs engineering, finance, or operations to step in. That gap tells you more than reply time alone.

One small example says a lot: if ten recent tickets mention failed data imports, and eight of them needed a staff member to clean a file by hand, you do not have a support issue alone. You have a product issue that support keeps covering up.

For this part of the audit, write down only three things: the top themes, the repeat manual tasks, and the average gap between reply and resolution. That is usually enough to show where customers feel the pain first.

Check how teams use AI right now

AI use often sounds bigger than it is. A founder may say, "We use AI across the team," but that can mean anything from daily code review to one person testing prompts on Friday.

Start with recurring work. Ask each team where AI shows up every week, not where they hope it will help later. You want real habits tied to actual output.

Most of the time, the useful cases are easy to name: writing or reviewing code, drafting tests, summarizing support tickets, writing docs or release notes, and preparing sales or customer replies.

Then separate workflow use from experiments. If a team uses AI inside a repeatable step with clear inputs and clear review, count it as real use. If people open a chatbot only when they feel stuck, that is still experimentation.

The difference is obvious when you compare teams. One startup may use AI every week to draft test cases, write first-pass documentation, and suggest bug fixes inside the same delivery flow. Another may say the team uses AI a lot, but nobody can name a step that depends on it. Those are not the same thing.

Ask what humans check before anything ships. Someone should review code, customer replies, docs, and anything that touches private data. If nobody owns that review, the team has risk, not leverage.

Also note the failure pattern. Common problems are rework because the output looked right but was wrong, extra debugging time after AI-written code, weak support drafts, and sensitive data pasted into public tools.

You do not need a deep technical review here. You only need to know where AI saves real time, where it creates extra work, and where the team still needs tighter review rules. That gives you a clearer picture than any claim about being "AI-first."

Score each startup on one simple sheet

A short audit gets messy when each company uses different labels. Use one page and one scoring rule for all of them. That makes patterns easy to spot across the portfolio, even when the businesses are very different.

Keep the scale simple. A 1 means "needs action now," a 3 means "works, but not reliably," and a 5 means "healthy and repeatable." Keep that meaning stable from one company to the next.

Score the same four areas every time:

• delivery
• infrastructure cost
• support pain
• AI use

Under each number, add one short reason. One sentence is enough. "Delivery: 2 - releases slip by a week and nobody trusts the roadmap" is better than a long note nobody will read.

Then add one more line: "Act first on..." That matters more than the average score. A company may look fine overall and still have one issue that needs immediate attention, like rising cloud spend or support tickets piling up after every release.

If you advise several teams, resist the urge to rank everything with decimals. Clean scoring beats fake precision. A plain 1 to 5 scale, with one reason and one first action, is enough to start making decisions.

A realistic example from two portfolio companies

Two portfolio companies can look healthy for very different reasons. That is why the same four categories matter in every review: delivery, cost, support pain, and AI use.

The first company ships fast. It pushes updates three or four times a week, closes bugs quickly, and the product team rarely waits on engineering. On paper, that looks great.

The problem sits in the stack. The team pays for overlapping tools, keeps large staging servers running all month, and still has old subscriptions from earlier experiments. Its sheet might read: delivery 4/5, infrastructure cost 1/5, support pain 3/5, AI use 2/5.

That does not call for a process overhaul. It calls for a cost cleanup. Cut duplicate tools, shrink unused servers, and set one simple rule for new software: if a tool does not save time every week, drop it.

The second company has the opposite pattern. It keeps cloud spend low, uses a small tool set, and avoids extra software unless the team really needs it. Finance likes that.

Customers do not. Support tickets pile up, the same issues keep coming back, and engineers lose half a day here and there answering urgent questions. That sheet may read: delivery 2/5, infrastructure cost 4/5, support pain 1/5, AI use 2/5.

This team does not need a cheaper stack. It needs better support triage, a short list of repeat issues, and one owner who closes the loop with product and engineering.

The scoring sheet stays the same in both cases. The fix does not. That is the point. A fast review should tell you where to act first, not push every company toward the same answer.

Mistakes that waste a fast audit

A fast audit goes wrong when the numbers look clean but the team story says something else. Dashboards can miss workarounds, quiet delays, and support load that never reaches a report. Spend a little time with the founder, the person shipping product, and the person closest to customers. That short conversation often tells you more than a polished chart.

Another common mistake is treating one bad week as a pattern. A missed release, a cloud bill spike, or a flood of tickets may come from a launch, a holiday, or one broken integration. Ask for six to eight weeks of signals, not one screenshot from Friday.

Bad comparisons ruin the review too. A seed team with five people should not be judged the same way as a mature SaaS company with a full support team, stable revenue, and years of process. Judge each company by its stage, team size, and business model. Otherwise, the neatest company wins, not the one making the best progress.

The worst mistake is turning scores into blame. Once that happens, people start defending themselves instead of telling the truth. The audit stops being useful.

Use the sheet to choose next steps, not winners and losers. One delivery fix, one cost change, one support change, and one small AI test for the next 30 days is enough. If the team can act on the result by Monday, the audit did its job.

Quick checks before you share results

Before you send anything, look at each score and ask one question: can you point to one number, one recent incident, or one direct quote from the team? If the answer is no, lower your confidence or rewrite the note.

Plain language matters more than polish. Do not write "delivery concerns" if the real issue is "releases slip by 2 to 3 weeks and nobody can explain why." Do not write "support load is elevated" if five customers hit the same bug last month. Founders scan for risk quickly, so name the problem the way they would say it out loud.

Keep each company note short. One page is usually enough, and half a page is often better. If someone needs to read six blocks of text to find the problem, the audit is too heavy.

Each summary should include the score, the proof behind it, the urgent risk in plain words, and one action for the next 30 days.

That last part matters most. Do not leave a team with a pile of observations and no next move. If cost looks high, ask them to review the top three services by spend. If support pain keeps repeating, ask them to tag the last 20 tickets by root cause. If AI use looks random, ask them to pick one workflow and measure time saved for two weeks.

A portfolio review becomes useful when an investor or operator can read each note in two minutes and know what to do next month.

What to do after the first week

A fast audit matters only if each company leaves week one with one clear next move. Pick a single fix per startup, not a long wish list. Give it an owner, a deadline, and one simple success measure such as fewer support tickets, lower cloud spend, or faster release cycles.

If nobody owns the first fix, the audit turns into a document people mention and ignore. A product lead might own release delays. An engineering manager might own noisy alerts. A founder might need to own AI policy if people already use tools in an ad hoc way.

Not every company needs the same level of follow-up. Some startups need a small correction and a 30-day check-in. Others need a deeper review because the signals point to a larger problem: missed releases, rising infrastructure bills, repeat customer pain, or a team using AI with no process and no review.

Use the same scoring sheet again next month. Do not redesign it. A stable format makes change easy to spot. One company may cut cloud waste in two weeks. Another may show no movement at all, which tells you a lot.

Over time, these checks show which founders act quickly, which teams need hands-on help, and which problems keep repeating across the portfolio.

If the findings feel political or unclear, an outside review can help. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and this kind of short operating review fits that work well. A neutral second pass is often enough to tell the difference between a simple cleanup and a deeper company problem.