Testing Two Technical Approaches in Parallel Before Committing to One

Architecture decisions are hard to reverse once a product has users. For one of our own products, a consumer life-admin app, we chose not to settle the question on paper. We built two technical approaches in parallel, compared them on the same work, and only then committed to a production architecture.

This post explains how to run that kind of comparison so it produces a real answer, and when it is not worth doing.

The product

The app brings a household's subscriptions, bills and important documents into one dashboard. It uses AI to extract key details, such as amount, provider and renewal date, from photographed bills and contracts. It also tracks renewals and manages household tasks and reminders, on a cross-platform mobile app.

The technology in play included Laravel and Filament on one side, and Flutter with Supabase and Auth0 on the other. Each combination suggests a different shape of product: a conventional backend with an admin panel, or a mobile-first app on a managed backend.

Why test both instead of deciding

Both directions were credible. Each had real strengths for a product like this, and each carried risks that are difficult to judge in the abstract: how authentication fits together, how document extraction plugs in, how much operational work the backend needs.

When the options are this close, a debate tends to be decided by preference rather than evidence. Building a thin slice of each replaces opinion with something you can use and measure.

How to make a parallel test fair

A comparison only helps if it compares like with like. These are the rules we recommend.

Build the same feature in both

Both approaches implement the same slice of the product, with the same scope. If one gets the easy screens and the other gets the difficult integration, the result reflects the assignment, not the architecture.

Choose the riskiest slice

The slice should exercise what is most likely to go wrong. For a life-admin app, that means the path from a photographed bill to extracted, stored data, together with sign-in. A login screen and a list view would prove nothing, since every stack handles those.

Fix the criteria before starting

Write down how the winner will be chosen before any code exists. Useful criteria include:

• How well the riskiest feature works in practice.
• How much code and configuration the slice needed.
• How much operational work the backend will require.
• How easy the next features on the roadmap will be.
• Cost at the expected early scale.

Time-box it

A parallel test is a learning exercise with a deadline. Without one, both slices drift into half-built products.

What it costs, honestly

Building two versions of anything costs more than building one. The justification is that the cost of choosing wrong is higher: a production architecture that fights the product means months of workarounds or a migration with live users.

That is why this approach suits a narrow set of situations:

• Two options are genuinely close.
• The decision is expensive to reverse.
• The riskiest part of the product can be isolated into a small slice.

If one option is clearly better, or the decision is cheap to change later, just choose and build.

After the decision: delete the loser

The last step is the one most often skipped. Once an approach wins, the other slice should be archived and removed from active work. Keeping both "just in case" splits attention and leaves two half-maintained codebases.

A checklist for a parallel architecture test

• Confirm the options are genuinely close and the decision is costly to reverse.
• Pick the riskiest feature as the shared slice.
• Write the decision criteria before building.
• Time-box both slices equally.
• Decide, document why, and archive the other slice.

The anonymised write-up is in our work library. The same idea works for visual design: see building alternate designs side by side. A related technique for single unknowns, like an external AI service, is in proof of concept first. Helping founders make these early decisions with evidence is a core part of our MVP service.