How to Validate a Niche Trading Product When There Are No Direct Comparables

A client came to us with a niche commodity trading platform that did not exist yet. No build, no users, no revenue, and a funding round to raise. The first question every investor asked was the one they could not answer with confidence. How much will people actually trade on this, and how often?

A product with no direct comparable almost always has plenty of indirect ones.

There was no direct comparable. Nothing on the market did the same job, for the same people, in the same way, with the same commission model sitting underneath it. Founders treat that as a dead end for a forecast. It is usually the opposite, because a product with no twin still sits inside a market where people are already spending money solving the same problem badly.

What follows is how we built that forecast. Splitting the product into the jobs it does, finding the products already doing part of each job, scaling their traction down to something a launch can realistically hit, and then modelling commission revenue rather than a tidy flat fee, all of which sit at the heart of a solid app planning and strategy process. At the end of it, the client had one, three and five year numbers that held up in a room, SEIS registration, and a staged plan for raising.

Why 'No Comparables' Usually Means 'No Obvious Comparables'

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products. The plan was to merge several of them into one. He was excited and pleased with himself, and the spreadsheet was genuinely thorough. Then we started asking about the people who were meant to use it. Why pick an all-in-one product over three specialist apps they already liked? Does merging the features water each one down?

He deflated. That is uncomfortable, and it is our job, because a product built on a founder's own opinion of the market serves nobody.

The spreadsheet habit is telling. Mapping features gives you instant agreement with yourself, and it costs nothing. Speaking to real users costs money and carries the risk of hearing that the idea is wrong. Lack of market need is the single largest cause of startup failure in roughly 42% of the post-mortems analysed by CB Insights, more common than running out of cash.

When a founder says there are no comparables, they usually mean nothing on the market has the same feature list. The spending is still happening somewhere. People are paying brokers, paying fees, using forums, using spreadsheets, or putting up with a product built for a different trade entirely.

Breaking the Product Into Jobs Before You Look for Benchmarks

On the toll management project, the client wanted the platform to talk directly to established toll operators through their APIs. We had to walk them through how those relationships actually get built, and make the case that a brand-new, unproven product has very little to bargain with. Incumbents do not open their data to an app with no users. So we split the product into what it needed to do on day one and what it needed to do later, launched on the preloaded credit model, and left API integrations for the point where the platform had credibility. The client accepted that staging.

That split only became visible once we stopped describing the product as a whole thing and described it as a set of jobs.

1. What does the user want to get done, in their words?
2. How are they getting it done today, including badly?
3. What do they pay for that, in money or time?
4. Which part of the job does our product actually own?

Once a product is in pieces, benchmarks appear. A commodity trading platform does price discovery, counterparty trust, transaction handling and record keeping. Four jobs, four different sets of products to look at, four sets of numbers.

Finding Adjacent Products That Do Part of the Job

We did proof-of-concept work for a company building an app where people share memories with audio attached. The first plan was Spotify for short clips. Spotify had no proper API for clips, and users needed their own account to hear anything, which pulled the whole experience apart. We moved to Deezer, which supported clips, had a well built API, and did not force a login. Users searched a catalogue larger than Spotify's and attached clips inside the app.

The second benefit arrived without being designed for. Anyone who wanted the full track had an upsell to a Deezer subscription, which opened affiliate referral revenue alongside the product's own income.

The product next door is already doing part of your job, and its numbers are doing part of your maths.

Adjacent products are useful twice over. They give you published pricing, visible subscriber claims and app store positions you can read. They also hand you revenue lines you had not thought of, because somebody near you has already found a way to earn from the same user moment.

For the trading platform, we looked at products that handled part of what it would handle, studied their revenue and subscription models, and used those as a starting baseline rather than a target.

Reading Someone Else's Numbers: What You Can and Cannot Infer

Published numbers are written to attract investors and customers, so read them for what they are. A subscriber count tells you a demand pool exists. It says nothing about how many of those people pay full price, stay past month three, or transact often enough to matter in a commission model.

We keep this separation explicit when we build the model, because a founder reading a competitor's press release will take the headline figure as a ceiling to aim for.

The honest version of a benchmark sounds like this. A product in an adjacent market, with three years of marketing behind it, reports this many users at this price. We are starting from zero, in a narrower niche, with no brand. Here is the fraction of that we think is reachable in year one, and here is why.

Scaling Down a Mature Competitor's Traction to a Launch Figure

When we modelled the trading platform, we based projections on what comparable products in adjacent markets were doing, then applied an uplift or a downlift depending on where each product sat. A product with real traction already got used as a guide, and then scaled right down, because ours was new.

How far down is a judgement, and the judgement has to be defended with specifics rather than modesty. Platform coverage is one of the sharpest. On the social football platform we built, launching iOS-only halved day-one adoption, because the audience was younger and skewed heavily towards Android. We had built the more polished version of the product for the smaller half of the market. Post-launch, the client brought in advertising and dropped the subscription model entirely, having too few users to make subscriptions work.

Write the downlift as a short list of named reasons with a percentage against each, so an investor can argue with the reasoning instead of the total.

A launch figure built this way survives questioning. Fifteen per cent of a mature competitor's first-year volume, because we cover one platform, one territory, one trade category and have no paid acquisition budget in quarter one, is a sentence you can hold.

Modelling Commission Revenue Instead of a Flat Subscription

The hardest part of the trading platform forecast was that revenue came from commission on trades. A flat subscription is almost restful by comparison. You take users, multiply by price, subtract churn, and you have a line. Commission revenue has no single lever, because the same number of users produces wildly different income depending on how often they trade and how large each trade is.

So the model needed layers. Users arriving each month, users leaving each month, the share of downloads that become active trading accounts, how many transactions each active user makes per month across their life on the platform, average trade value, and the commission rate applied to it.

Compare that with the music backing track app we worked on, where revenue was a price multiplied by downloads and nothing else. One number set the ceiling. On a commission model, no single number sets the ceiling, which cuts both ways. There is more room to grow and far more room for a forecast to drift into fantasy.

The discipline is to keep every assumption separate and visible, so that changing trade frequency from two a month to one a month changes the whole model in front of the investor rather than inside a hidden cell.

The Input Variables: Acquisition, Churn, Conversion and Transaction Frequency

For the trading platform we mapped user acquisition at the start of each month, then churn, then the conversion rate between downloads and active revenue-generating users, then transaction frequency across the life of a user, then commission, platform fees and dispute amounts. Those inputs produced the one, three and five year forecasts investors saw.

1. New users acquired at the start of each month
2. Monthly churn, split by how long someone has been on the platform
3. Download to active trader conversion rate
4. Transactions per active user per month
5. Average transaction value
6. Commission rate on each completed trade

The gap between downloads and active traders is the one founders underweight most. A download is a person who was curious once. An active trader has verified an account, trusted the platform with money and completed a first trade, and the drop between those two states is steep in any product that touches payments.

Downloads flatter a forecast, and only completed trades pay wages, so model the gap between them.

Churn deserves the same care. People who leave in week one and people who leave in year two are different behaviours, and lumping them into one monthly percentage hides the shape of the business.

Platform Fees, Disputes and the Deductions Founders Forget

Commission is not what lands in the bank. On the trading platform we had to take out app store fees, payment processing and an estimate for disputes, because a marketplace handling money between strangers will always have trades that go wrong and get refunded. Leaving disputes out makes the model look cleaner and makes it wrong.

Build costs get forgotten in the same way. On the alcohol buying and selling platform, being forced to embed web elements rather than build a proper API layer added around twenty per cent uplift in work across the full length of the project. The client held the budget flat, so we dropped features near the end to pay for it. That uplift existed in the real project whether or not it existed in the plan.

Put a named line in the model for disputes and refunds even if the figure is a guess, because an investor trusts a visible estimate more than a silent omission.

Marketing sits in the same category. Acquisition numbers have a cost attached, and a forecast that grows users month on month with no spend behind the growth is a hope rather than a model. Name the channel, name the cost per user, and let the model show what growth actually buys.

Building One, Three and Five Year Forecasts That Hold Up

The three horizons do different jobs, and writing them with the same confidence is what gets a founder caught. Year one is a plan. Years three and five are a shape, and everyone in the room knows it.

For the trading platform, year one was built month by month from acquisition, churn and transaction frequency, because that is the period the raise actually funds. Years three and five carried fewer moving parts and more stated assumptions, around market share, a widening of trade categories and a second platform. Each of those assumptions had a sentence attached explaining what has to be true for it to happen.

Three things keep the later years honest. Growth that slows rather than compounds forever. Churn that rises as the easiest, keenest users are used up. Costs that grow with headcount instead of staying frozen at launch levels.

We also keep a low case alongside the base case, usually at half the acquisition rate. Founders resist this, worried it undercuts the pitch. It does the reverse, because a model that survives being halved reads as a business, while a model that only works at full speed reads as a wish.

Triangulating the Model: Cross-Checking Your Figures Three Ways

One route to a number is an opinion. Three routes that land near each other is a forecast. We cross-check every model three ways before it goes near a deck.

1. Top down, scaling an adjacent product's traction to launch reality
2. Bottom up, building revenue from acquisition, conversion, frequency and commission
3. Demand side, checking the numbers against what target users say and already pay

When the three sit close together, the model is probably sound. When the top-down number is five times the bottom-up number, something in the acquisition plan is doing imaginary work, and finding that before an investor does is the entire value of the exercise.

The demand-side check is the one founders skip, and it carries the most weight in a room. Waveup describe a client pitch deck for an AI prospecting tool where 90% of 100 customers surveyed responded positively to the idea, though that is self-reported interest gathered by the company itself rather than observed buying.

Stated interest and paid behaviour are different things, so treat survey warmth as the softest of the three checks and let the bottom-up build carry the weight.

Stress-Testing Assumptions Against How the Audience Actually Behaves

In financial trading, a product with better interaction design can perform worse. Experienced traders who understand commodities markets need to reach a time-sensitive trade fast. Guiding them through extra steps and contextual information strips out the speed they came for, and the denser, barer competitor feels easier to them because it maps onto how they already think. In most products, confusion leads to anxiety and anxiety leads to abandonment, so guidance helps. Here it hurts.

That matters for the model, not only the interface. If expert users trade in seconds, transaction frequency climbs and onboarding assumptions change. If the audience skews towards occasional traders, frequency drops and the commission line shrinks with it.

Forecasts break where the model assumes one kind of user and the market sends you two.

Platform behaviour deserves the same treatment, and the social football platform is the reminder. The forecast assumed a user base the launch build could not reach, because the younger audience was on Android and the product shipped on iOS. Revenue assumptions then collapsed far enough that the subscription model was abandoned and advertising brought in to cover the hole.

Pricing Decisions the Model Should Make for You

On the music backing track app, we recommended a low price point to drive mass adoption. The market was niche and split between professional musicians and casual players, which is exactly the shape where volume does the earning. The client pushed for a high price instead, because the price had to reflect what the recordings cost to produce. Sales came in low, as expected. Lower introductory pricing or a volume model, on our reading, delivers more downloads and more total revenue.

They came from the music world and knew what the recordings cost, and they wanted that money back within weeks. Consumer app economics do not work on that clock. The cost-of-production anchor stopped them from even testing a lower price.

Run your price options through the same model, side by side, before you argue about them, because a spreadsheet settles price arguments that opinions cannot.

A commission model has the same trap in a different costume. A high commission rate looks like a faster route to revenue and quietly suppresses the trade volume the whole business depends on. Model both. Let the five-year line decide.

Preparing the Numbers for SEIS Registration

With the commodity trading platform client, we refined what the idea actually was and what made it different, built the financial projections, set out the marketing strategy and produced the pitch decks. We also helped them get SEIS registered, which makes the investment a great deal more attractive to the people they were about to speak to.

Registration asks you to describe the business and the use of funds plainly, so the forecast and the raise have to agree with each other. If the model shows twelve months of runway at the stated acquisition spend, the raise cannot quietly assume eighteen. Those mismatches get found.

Their fundraising then ran in stages. Friends and family first, which brought in early money and early belief, then matched funding with institutional investors on the back of it. Waveup, working with more than 500 founders, report that those who validated their ideas closed pre-seed rounds 40% faster, which is their own client data rather than independent research, though it points the same way our work does.

The practical gain of preparing numbers for SEIS is that it forces the model into a form a stranger can read.

Taking the Forecast Into Investor Conversations

We worked with a client who had an idea for a trading card trading platform, no funding, and technical skills from a gaming background. We built him a set of pitch materials so he had something to take into conversations. He skipped the angel and VC route, spoke to friends and family, and got real buy-in from his own network. Then he built a vibe-coded version of the product, which changed every meeting after that, because he had something to demo rather than describe. It worked.

A forecast and a working demo support each other. The demo proves the thing can exist. The model proves someone has thought about whether it earns.

Keep the deck version of the forecast short. Waveup report that investors spend an average of 12 seconds per deck page, which is stated without a named source, so treat it as a rough signal rather than a measurement. The instruction it gives is sound either way. One chart, three assumptions, the rest in the appendix.

Then know your own numbers well enough to be challenged on any of them without reaching for the file.

Conclusion

Validating a niche product without direct comparables is slower than copying a competitor's pricing page, and it produces something far sturdier. Break the product into jobs. Find the products already doing part of each job and read their numbers honestly, for what they prove and what they hide. Scale a mature competitor's traction down to a launch figure you can defend out loud. Model the revenue mechanism you actually have, with every input visible.

For the commodity trading platform, that meant acquisition, churn, download-to-trader conversion, transaction frequency, commission, platform fees and disputes, all mapped out until the one, three and five year picture made sense. The forecast then carried the pitch decks, the SEIS registration and a staged raise that started with friends and family.

The founder with the colour-coded spreadsheet had done real work. The work just answered the wrong question. Feature maps tell you what exists, and only user behaviour and money tell you what will be bought.

If you are sitting on a product with nothing to benchmark against and a round to raise, we build these models from the ground up. Let's talk about validating your product.

Frequently Asked Questions