A supplier has suggested rebuilding your platform. Your lead developer thinks it is overdue. The estimate is substantial, and you cannot quite tell whether you are buying room to grow or a more expensive version of what already works.

As a non-technical founder, it is tempting to turn this into a question about the technology: is the old framework bad, and is the new one good? I would start somewhere else.

1. Name the problem without naming the solution

“We need a rebuild” is a proposal. “It takes three weeks to change our checkout” is a problem you can investigate. So is “we cannot explain why orders fail” or “only one person understands billing.” Each points towards different work.

Ask the team to describe the constraint in terms you can recognise. Where do customers get stuck? Which change keeps getting delayed? What does the team avoid touching? You do not need to diagnose the code yourself. You do need a shared account of what is hurting the business.

Write that account down before discussing a replacement. Otherwise, the appeal of a fresh start can become a substitute for an agreed objective.

2. Ask what becomes possible afterwards

A useful proposal connects the work to something you want to do. Perhaps you need to launch in another market, support a second product or make a particular customer journey reliable. “A cleaner architecture” might support that objective, but it does not tell you whether the investment is worthwhile.

Try this question: “If we finish this, what will we be able to do that we struggle to do today?” Follow it with: “How will we know?” The answer does not have to be a perfect spreadsheet. It should be concrete enough that you can return to it after the work.

Be wary of a proposal that promises to fix everything. A decision becomes easier to assess when its benefits and boundaries are both visible.

3. Look for the smaller experiment

Before agreeing to replace the whole platform, ask whether one difficult part can be improved first. Could the team separate billing from the rest of the product? Could they make the checkout easier to test? Could they try the proposed approach on a contained feature?

Sometimes the answer will be no, for good reasons. The value is in asking for those reasons. A smaller piece of work can reveal assumptions about effort, compatibility and the way your team will actually operate the new system.

This is also a conversation about opportunity cost. While the team is rebuilding, what customer work will wait? Which commitments need to change? Make that trade-off visible before it arrives in a missed launch.

4. Make the transition part of the decision

A new system is only part of the story. Existing customers still need to log in. Their data still needs to make sense. Payments, integrations and reporting still have to work while changes happen.

Ask who owns that transition, how it will be checked and what the team will do if a step does not go as expected. You are not asking for certainty. You are asking for a plan that includes the awkward middle, when the old and new systems may both need attention.

It is reasonable to ask how progress will be demonstrated along the way. A working slice that the team can explain is more useful to your decision than a reassuring percentage on a slide.

Put the responsibilities on the same page as the proposal. Who will check the customer journey? Who can decide to pause the transition? Who will answer questions from the rest of the business? These are useful questions even when the technical approach is sound. They make it easier for everyone to see what they are agreeing to, and to notice when an assumption needs another conversation.

A better question for your next meeting

You do not need to become the most technical person in the room. Your job is to keep the proposed work connected to the business you are trying to build.

So before asking, “Which technology should we use?”, ask: “Which constraint are we removing, what is the smallest useful way to test this, and what will change for the business if it works?”

That gives your technical team something clearer to respond to. It gives you a decision you can understand. And it makes room for the possibility that the right next step is smaller, or simply different, from the one first proposed.

For your next meeting, bring a short list of the changes you want the business to make over the coming months. Ask the team to connect each proposed improvement to that list. Where the connection is unclear, keep asking. The conversation may take a little longer. The decision will have a clearer starting point.