The Argument, Up Front.
A user count tells you that people arrived. It says nothing about whether the product works. This whitepaper argues that a marketplace repeat rate is not a retention outcome to be improved later but a design outcome decided early, at the moment someone chooses what unit the platform sells, and that the decision is usually made quickly and by whoever configured the payment integration. The Honu implementation is the evidence: a marketplace selling multi-lesson packages that learners draw sessions from, where 80% of users book recurring packages rather than single sessions.
Separate the two kinds of number, because the confusion between them is where this goes wrong. Headcount and signups measure acquisition, which is bought with marketing spend and rises whether or not anyone is satisfied. Repeat rate measures whether the thing you sold was worth buying again, and no amount of spend moves it.
Four patterns explain why marketplaces with healthy signup numbers report disappointing repeat rates, and this whitepaper rejects all four: vanity ordering, selling single transactions for a multi-session service, treating a balance as an arithmetic result, and building the demand side while listing the supply side.
Five principles resolve it. Put the repeat rate first, everywhere. Sell the unit the market actually buys. Treat a balance as state rather than a calculation. Give the supply side a product rather than a listing. And say what you check, while keeping coordination inside.
NewAgeSysIT built the platform described here under the strategic advisory guidance of Giovanni Livia, as a two-sided booking marketplace rather than a directory with a payments page attached.
One boundary belongs here rather than at the end. This pattern earns its cost only where the service genuinely has a multi-session shape. Forcing a package onto a one-off service produces commitment friction at the point of first purchase, which is the opposite failure and a worse one.
One Metric Says You Launched. One Says It Works.
A user count tells you that people arrived. It says nothing at all about whether the product works, and most marketplaces put it first anyway, because it is the number that goes up on its own.
Headcount and signups
Repeat rate
Measures
Headcount and signups
Acquisition
Repeat rate
Whether what you sold was worth buying again
Moved by
Headcount and signups
Marketing spend
Repeat rate
No budget line
Claims
Headcount and signups
That a product launched
Repeat rate
That it works
Separate the two kinds of number precisely. Headcount and signups measure acquisition. Acquisition is bought, it responds to spend, and it rises whether or not a single person was satisfied by what they found. Repeat rate measures whether what you sold was worth buying again, and there is no budget line that moves it.
Why the wrong one gets the headline is not mysterious. Acquisition figures are available from launch, they are almost always growing, and they are comfortable to present. A repeat rate is only available once enough time has passed for people to decide, and it can come back low. The metric that is easier to report is the one that ends up on the slide.
There is a stronger version of this argument than "one number is better than the other", and it comes from the research literature on customer-base analysis. Fader and Hardie's review in the Journal of Interactive Marketing organises that entire field around one distinction: contractual settings, where a customer's departure is directly observable because they cancel, and noncontractual settings, where it is not. A marketplace is noncontractual. Nobody cancels a marketplace. They simply stop coming, and no event is generated when they do. The models built on that insight, running from Ehrenberg's foundational work on repeat buying through to the BG/NBD model published in Marketing Science in 2005, all infer whether a customer is still active from their repeat transaction behaviour, because there is nothing else to infer it from. So the repeat rate is not merely the better metric here. In a marketplace it is the only signal that exists.
Name what leading with the wrong number does to a page, because this is the observation the section turns on. A case study headed with a learner count is claiming that a product launched. A case study headed with a repeat rate is claiming that it works. Those are different claims, and only one of them is worth a reader's attention.
The reporting problem becomes a design problem, which is where the paper is going. Once a team treats acquisition as the headline, product decisions follow the headline. Effort concentrates on the funnel and the first purchase, and the second purchase gets reclassified as retention, which is somebody else's department and usually somebody else's quarter.
So the reframe. The repeat rate is not a retention outcome to be worked on later. It is mostly decided at the point where you choose what unit to sell, and that decision is usually made early, quickly, and by whoever set up the payment integration.
If the commercial model decides the repeat rate, the question becomes what unit the market actually buys, and what the software has to hold in order to sell it. Section 04 answers both.
Sources
- Fader, P.S. and Hardie, B.G.S. (2009), "Probability Models for Customer-Base Analysis," Journal of Interactive Marketing 23(1):61-69.
- Fader, P.S., Hardie, B.G.S. and Lee, K.L. (2005), "Counting Your Customers the Easy Way: An Alternative to the Pareto/NBD Model," Marketing Science 24(2):275-284.
- Ehrenberg, A.S.C. (1972), Repeat-Buying: Theory and Applications.
Building a Booking Marketplace? Decide What Unit You Sell Before You Build the Checkout
Four Patterns, Three of Them Set Before Launch.
Four patterns explain why marketplaces with healthy signup numbers report disappointing repeat rates, and three of the four are decided before a single user arrives.
Vanity Ordering
Acquisition figures are placed first in every report, deck and case study, with repeat behaviour appearing last if it appears at all.
What you put first is what you optimise. A team reporting signups weekly will design experiments that move signups, and will get better at moving them. The second purchase becomes nobody's problem, not through neglect but because nothing in the reporting pointed at it.
The diagnostic is easy to run and slightly uncomfortable. Look at what the last four internal reports led with. If it was acquisition every time, the commercial model has probably never been examined, because nothing was directing anyone's attention toward it.
This is the failure mode the thesis answers most directly, and it is the cheapest of the four to fix. Changing what goes at the top of a report costs an afternoon. The other three cost a rebuild.
Selling Single Transactions for a Multi-Session Service
The checkout is built around one booking, because that is the simplest thing to build and every payment integration demonstrates it first.
Services taught or delivered in courses are bought in courses. Instruction, therapy, coaching, training and treatment all have a natural unit larger than one session, and a product that sells one session at a time is asking the buyer to make the same decision repeatedly when they already made it once.
State the consequence in the buyer's terms rather than the operator's. Every repeat becomes a fresh decision with a fresh opportunity to not bother. The friction is tiny each time, which is exactly why nobody fixes it, and it compounds across every session in a course.
The alternative is to sell the block. The repeat purchase stops being an upsell and becomes the default path, which is a product decision rather than a marketing one.
Treating a Balance as an Arithmetic Result
Remaining sessions are computed on demand by counting transactions and subtracting bookings, rather than held as a thing in its own right.
The buyer cannot see what they have left without the system performing a sum, and every edge case, meaning a cancellation, a reschedule, a refund or an expiry, has to be reflected in that sum by every piece of code that performs it. They will not all agree.
Name the cost in the only terms that matter here: billing disputes, in a market where trust is the product. A learner who believes they have two sessions left and is told they have one will not buy the next block, and the operator will never learn that is why.
The alternative is that the balance is state, held against the purchase, updated deliberately, and legible to the buyer at all times without anyone calculating anything.
Building the Demand Side and Listing the Supply Side
The buyer side gets a designed product and the seller side gets a form, because the buyer side is what a founder can picture and what a demo shows.
The supply side is the harder half of any marketplace to fill and the easier half to lose. A seller who cannot control their own calendar, cannot see their reputation accumulating, and cannot get paid without chasing goes back to the referral network that worked before, and takes their learners with them.
What supply actually needs is more than a listing: reach beyond their existing contacts, control over their own availability, reputation that carries forward rather than resetting with each engagement, and administration that takes less time than the informal arrangement it replaced.
The test is one sentence. If the supply-side experience is a subset of the admin panel, it is a form rather than a product.
| Pattern | Why it gets chosen | Where it breaks | What it costs |
|---|---|---|---|
| Vanity ordering | Acquisition is available early and always rising | What you report is what you optimise | The commercial model is never examined |
| Single transactions | The simplest checkout to build | Course-shaped services are bought in courses | Every repeat is a fresh chance to not bother |
| Balance as arithmetic | Faster to ship, no model needed | Four edge cases, three implementations | Billing disputes where trust is the product |
| Listing the supply side | It is not what the demo shows | The harder half to fill, the easier to lose | Sellers return to the network that worked |
Selling the Unit the Market Already Buys.
A marketplace's repeat rate is mostly set by three decisions taken before launch: which number you treat as the headline, what unit you sell, and what the software holds in order to sell it. The rest is execution.
What follows is sector-agnostic. An architect building for tutoring, physiotherapy, personal training, music lessons or therapy could apply it without ever seeing the implementation in Section 05.
Architecture Diagram
The Package, the Balance, and Where Each Principle Applies
Supply side as a product
Reach, calendar control, reputation that carries forward, lighter administration
The trust layer
Describe what was examined and by whom, and keep coordination inside
Put the Repeat Rate First, Everywhere
Make the repeat rate the headline metric, internally and externally, from launch, before it is good.
Implementing it requires defining the repeat event precisely for your product, meaning a second purchase, a renewed block, or a booking beyond the first package, then instrumenting it on day one and putting it at the top of whatever report the team actually reads.
What it buys is that product attention follows the headline. A team reporting repeat rate weekly will notice within a quarter that the commercial model is the lever, because nothing else moves the number much and they will have tried the other things first.
Name the discomfort, because it is why this rarely happens. Early on the repeat rate will be small and the acquisition number flattering. Leading with the smaller one is a choice somebody senior has to make and keep making every week, usually in front of people who would prefer the other number.
Sell the Unit the Market Actually Buys
The transaction unit in the software should match the transaction unit in the world. If the service is delivered as a course, sell a course.
Implementing it requires identifying the natural unit by asking how practitioners in your market already sell the service offline, not by asking what is easiest to charge for. Then building the package as a first-class product with its own definition, pricing and lifecycle, rather than as a discount applied to repeated single purchases. Those two look similar in a pricing table and are entirely different in the data model.
What it buys is the paper's central claim, so state it plainly: the repeat purchase stops being a separate decision the buyer has to make again. They decided once, at the point where they were most motivated, and the product honours that decision instead of re-asking it every week.
The boundary is real and worth naming here rather than in a caveat at the end. This only holds where the service genuinely has a multi-session shape. Forcing a package onto a one-off service produces commitment friction at the point of first purchase, which is the opposite failure and a more expensive one, because it costs you the buyer you already had.
A Balance Is State, Not a Calculation
Remaining entitlement is held as its own thing, against the purchase that created it, and drawn down deliberately.
Implementing it requires the balance modelled explicitly with its own lifecycle, every event that changes it applied through one path rather than reimplemented wherever it happens to be needed, and the current figure visible to the buyer without them asking anyone. The events are booking, cancellation, reschedule, refund and expiry, and the list is longer than teams expect at specification time.
What it buys is one number that both sides agree on. The operator can answer a query instantly and the buyer never has to trust an arithmetic they cannot see.
Name where this goes wrong in practice, because it is specific and useful. The failure is almost never in the happy path, which is why it passes review. It is in the fourth cancellation policy edge case, added six months later by someone who had no reason to know the balance was being computed in three places.
The Supply Side Needs a Product, Not a Listing
The seller side of a marketplace is the harder half to fill and deserves design effort proportional to that difficulty, not proportional to how visible it is in a demo.
Implementing it means four things the supply side actually needs: reach beyond their existing network, control of their own calendar, reputation that accumulates across engagements rather than resetting, and administration that costs less time than the informal arrangement they were using before. The fourth is the one most often missed, because it is measured against a baseline nobody documented.
What it buys is supply that stays. A marketplace with a full demand side and a leaking supply side is a directory with a payments page.
On calendar ownership: the argument that a schedule should be maintained by whoever has to honour it is made at length in the Eco Auto School whitepaper in this series, and it applies here unchanged. It belongs in this principle as one of the four, not as an argument of its own.
Say What You Check, and Keep Coordination Inside
In a marketplace where a buyer is choosing who will work with their child, the platform describes what it examined and who examined it, rather than applying an adjective to the result. The full argument for describing the mechanism rather than asserting a conclusion is made in the Auntie App whitepaper in this series and is not restated here.
The second half has a fresh angle worth having. In-platform messaging is usually justified as a record-keeping decision, and that undersells it. For a parent arranging lessons for a child, being able to ask a question without handing over a personal phone number is itself part of what makes the marketplace usable. Coordination staying inside serves the buyer before it serves the operator, and a platform that treats it purely as a data-retention feature has misread who it is for.
At a Glance
The Five Principles
-
01
Put the repeat rate first, everywhere.
What the team looks at
-
02
Sell the unit the market actually buys.
What gets sold
-
03
A balance is state, not a calculation.
What survives refunds
-
04
The supply side needs a product, not a listing.
Keeps the other half present
-
05
Say what you check, and keep coordination inside.
The trust layer
Giovanni Livia, Independent AI & Software Solutions Consultant | Implementation by NewAgeSysIT
Principle 1 decides what the team looks at. Principle 2 decides what gets sold. Principle 3 is what makes Principle 2 survive contact with cancellations and refunds. Principle 4 keeps the other half of the marketplace present. Principle 5 is the trust layer underneath all of it. The first three are set before launch. The last two are maintained forever.
Three Roles and One Booking Record.
NewAgeSysIT implemented this approach for Honu, a marketplace connecting swimmers and their parents with swimming instructors across mobile and web, under the strategic advisory guidance of Giovanni Livia.
Three roles act on one booking record: learners searching and booking, instructors managing their calendar and reputation, and administrators overseeing accounts, sessions and payments. The full platform description and client narrative are published in the Honu case study.
Principle 2 in practice, and the core evidence. Swimming is taught in courses rather than one-off sessions, so the platform sells multi-lesson packages that a learner buys as a block and then schedules against. The repeat purchase is the default path rather than an upsell, because the product was built around the way the service is actually taught rather than around the way a checkout is easiest to build. That is the whole thesis, implemented, and it is why the number in Section 06 looks the way it does.
Principle 3 in practice. The platform holds a balance of remaining sessions against each purchase, applies each scheduled lesson to it, and keeps what is left clear to the learner. The reason is worth stating plainly rather than treating as an implementation detail: in a market where trust is the product, a billing dispute costs considerably more than the disputed amount, and the customer who quietly stops rebooking never explains why.
Principle 4 in practice. Instructors get discovery beyond their existing contacts, their own calendar which feeds directly into what learners see, reviews and ratings that attach to their profile and carry forward across students rather than resetting, and booking and payment administration handled inside the platform. The calendar decision is the Eco Auto School argument applied to a different trade.
Principle 5 in practice. Instructors list their credentials, experience and teaching specialisations on their profile, and accounts are reviewed and approved by an administrator before appearing in search. Conversations stay in the platform, so a parent can ask an instructor a question without handing over a personal phone number.
The admin layer. Administrators approve and suspend accounts on both sides, and track transactions and instructor payouts. It is delivered as a web application rather than squeezed into the mobile apps, because an operator reviewing a week of payouts is not doing that on a phone. That is a smaller decision than the others here and it belongs in the record anyway: the surfaces were scoped by who uses them and where, rather than by what was cheapest to reuse.
One thing worth noting about what search does here. Learners filter across location, experience, specialisation, packages and ratings before choosing. That is not a feature note, it is the precondition for everything else in this section. A buyer who could not compare had not really chosen the first time, which means their second purchase would have evidenced nothing about the product either way.
The stack, named narrowly. React Native across iOS and Android. The backend framework and the database are not named here, because the sources conflict on both and this document's reader is the kind who checks.
Full delivery detail and all six components are published in the Honu case study.
Client Story
Read the full Honu case study
Full delivery detail and all six components.
Three Figures, and Why Only One of Them Counts.
Three figures came out of this implementation and only one of them is interesting. The other two say the marketplace filled. The first says it worked.
| Evidence | Before | After | What it evidences |
|---|---|---|---|
| Recurring package booking | Not offered. A single-session checkout makes every repeat a fresh decision | 80% of users book recurring lesson packages | Principles 1, 2 and 3 together. The only figure here that demonstrates the product rather than the launch |
| Supply side depth | Instructors reaching only their existing contacts, administration run on messages and memory | 200+ instructors onboarded with profiles, calendars and accumulating reputation | Principle 4. The harder of the two headcounts to reach |
| Comparison before purchase | Referrals, local social media groups, and whoever a friend recommended | Filtered search across location, experience, specialisation, packages and ratings | Not a metric, and the condition that makes a repeat rate meaningful at all |
| Billing clarity | Cash and informal arrangements | In-app payment with receipts, and a session balance both sides can see | Principle 3. The dispute that does not happen is invisible, which is why this work is chronically underspecified |
| Learner base | 0 at launch | ⚠ Figure held pending verification | Acquisition evidence only. Nothing in this document rests on it |
Separate the figures into their two kinds, exactly as Section 02 argued. The instructor count and the learner count measure that the marketplace filled. The 80% measures that what it sold was worth buying again. Only the third supports the thesis, and a document that blurred them after spending a section distinguishing them would have argued itself out of its own conclusion.
Trace the 80% to its cause rather than reporting it, because the causal claim is the useful part. It is not a retention success and it should not be described as one. It is a commercial-model outcome. The product sells the unit the market already buys, so the repeat purchase was never a separate decision anyone had to be persuaded into. Had the same platform shipped a single-session checkout, the number would have been different and the team would have called it a retention problem and gone looking for it in the funnel.
State plainly what the evidence does not support. No baselines exist for any of the three figures. No measurement window is stated, so 80% over what period and among which cohort are both open. And one figure is under verification. There is also no figure at all for how long learners stay, which is the gap that matters most, because a high repeat rate over six weeks and a high repeat rate over two years are different claims.
The ask, and why this one. Average lessons per learner, or average packages purchased per learner. Paired with the 80% it converts a repeat rate into a retention story, which is a materially stronger claim than either figure carries alone. It is also obtainable from the platform's own data without asking the client for anything commercially sensitive.
Two rows carry no number and should not. Filtered comparison before purchase and a visible session balance are both binary architectural facts, and a percentage attached to either would be decoration. The billing row is the more interesting of the two, because what it prevents is invisible by construction. Nobody logs the dispute that did not happen, which is exactly why this kind of work is chronically underspecified and why it tends to be built only after a marketplace has already had the argument once.
The boundary condition. This pattern earns its cost where the service has a genuine multi-session shape. Where it does not, packaging creates commitment friction at first purchase and the simpler model is the correct one. The question to ask before building any of it is how the service is already sold in your market, and if the honest answer is one session at a time, this paper describes a more expensive way to be wrong.
Six Decisions Before the First Transaction.
Six decisions shape whether a marketplace produces repeat buyers or a growing list of people who tried it once. Three are made before the first transaction, and the first is usually made by whoever configured the payment integration.
| # | Decision | What to weigh |
|---|---|---|
| 1 | Which number you lead with | Whatever sits at the top of the weekly report is what gets optimised |
| 2 | What unit you sell | Ask how the service is already sold offline, not what is easiest to charge for |
| 3 | Whether a balance is state or derived | Derived is faster and eventually disagrees with itself |
| 4 | What the supply side gets | A product or a form |
| 5 | What you say you check | Describe what was examined and by whom |
| 6 | Whether coordination stays inside | Preserves the record, and spares the buyer handing over a phone number |
1. Which number you lead with.
Acquisition is available immediately and always flattering. Repeat rate arrives late and can be disappointing. Whichever goes at the top of the weekly report is the one the product will be optimised toward, so choose deliberately rather than by default. Deferring this costs a year of experiments aimed at the wrong thing, and nobody will notice they were aimed wrongly because the number they were aimed at went up.
2. What unit you sell.
Ask how practitioners in your market already sell the service offline. Building packages costs more than single bookings and is close to unrecoverable later, because pricing, entitlement and cancellation logic all sit on top of the unit you chose. There is a legitimate single-session answer wherever the service genuinely is one-off, and choosing packages there is the more expensive mistake of the two.
3. Whether a balance is state or derived.
Derived is faster to ship and puts the same arithmetic in several places, where it will eventually disagree with itself. Held state costs a model and a lifecycle. The difference only shows up in edge cases, which is why it is usually discovered through a dispute rather than a test, and why it is the other close-to-unrecoverable decision on this list. Deferring it does not keep the option open either: by the time the disagreement surfaces, the arithmetic has been copied into three or four places by people who had no reason to know the others existed.
4. What the supply side gets.
A product or a form, proportional to how hard that side is to fill rather than to how visible it is in a demo. Under-serving supply is the most common way a marketplace with good demand numbers quietly stops working, and it is slow enough that it gets attributed to something else.
5. What you say you check.
Describe what was examined and by whom. An adjective invites the reader to supply a more generous definition than you can support, and in a category where one side is a parent they will supply the most generous one available. If you do check credentials, say how. That is a paragraph rather than a word, and it is worth the space, because the description is also the differentiator: a competitor using the adjective has told a careful reader nothing at all.
6. Whether coordination stays inside.
Keeping conversations in the platform preserves the record and, more importantly for the buyer, means they do not hand over a personal number. It also costs build effort and creates a support surface somebody has to staff. Genuinely optional in business-to-business marketplaces, and much less so where one side is a parent arranging something for a child.
Two of those six have legitimate answers in either direction, and saying so is what should make the other four land. If you want a cost frame before settling any of them, the development cost estimator gives a working range.
Speak With Our Consultant
Partners
Look at what you are selling before you look at your funnel. Work directly with Giovanni and Bibin to validate your technology direction, align the platform with business goals, and make confident decisions that reduce risk and accelerate outcomes.
Request an Architecture Consultation
Five Insights, Each Independently Quotable.
A user count proves that people arrived. A repeat rate proves that what you sold them was worth buying again. Acquisition rises with marketing spend whether or not the product works, which is exactly why it is the comfortable number to lead with and the wrong one to optimise toward.
Sell the unit the market actually buys. Swimming is taught in courses, so Honu sells multi-lesson packages that learners draw sessions from, and 80% of users book recurring packages as a result. A single-session checkout would have produced a very different number, and the team would have called it a retention problem.
A package balance is state, not a calculation. Remaining sessions held against the purchase, drawn down through one path, and visible to the buyer without anyone doing arithmetic is what keeps a multi-session product from generating billing disputes, in a market where trust is the entire product.
The supply side of a marketplace is the harder half to fill and the easier half to lose, and it needs a product rather than a listing: reach beyond an existing network, control of one's own calendar, reputation that carries forward across engagements, and administration that costs less time than the informal arrangement it replaced.
Where a buyer is choosing who will work with their child, describe what the platform examined and who examined it rather than applying an adjective to the result. An unqualified label invites a parent to read a guarantee from the platform where the platform has only relayed a claim from the instructor.
From Architecture to Implementation.
Delivery Partner
NewAgeSysIT is a custom software development and AI solutions company in Princeton, NJ, specialising in two-sided marketplaces, booking and scheduling platforms, recurring-commerce products, and full-cycle development across mobile, web and cloud.
Founded by Johny John, NewAgeSysIT has delivered software across coaching and fitness, insurance, transportation, on-demand services and community platforms. Recent work is in the client portfolio.
The company works closely with Giovanni Livia, Independent AI & Software Solutions Consultant, strategic advisor, who helps business leaders scope and sequence platform initiatives before connecting them with NewAgeSysIT for implementation.
A Repeat Rate Nobody Wants to Talk About?
If your marketplace has good signup numbers and a repeat rate nobody wants to talk about, request an architecture consultation with Giovanni Livia to look at what you are selling before you look at your funnel.
Read the full implementation narrative in the Honu case study.
newagesysit.com | [email protected] | 1-609-331-9194 | 4390 US-1, Suite 110, Princeton, NJ 08540