The Argument, Up Front.
No platform can certify a person. This whitepaper argues that a marketplace trust architecture in a trust-critical category is not in the business of removing risk but in the business of supplying evidence, and that the distinction is architectural before it is legal: one posture describes a mechanism the platform controls, the other promises an outcome it does not. The Auntie App implementation is the evidence: a two-sided childcare marketplace where discovery, booking, messaging, live status, payment and review sit on one record, and provider onboarding documents what was checked rather than characterising who was checked.
The costs of getting the posture wrong run deeper than the legal exposure, and the deeper cost is the one teams miss. A team that believes a check at onboarding has solved trust stops building the layer that would actually help. Ratings, prior conversation, transaction history and status during delivery all get treated as refinements, because the hard problem is thought to be settled.
Four patterns dominate trust design in service marketplaces and this whitepaper rejects all four: the guarantee, the directory, trust theatre, and silence during delivery.
Five principles resolve it. Document the check, never certify the person. Keep the relationship on one record, or reputation never accumulates. Treat two sides as two products over one data model. Push state during delivery rather than only before it. And capture the transaction inside the platform so the amount is derived rather than remembered.
One boundary belongs here rather than at the end. None of this makes a decision safe. It makes it better informed, and a document that blurred those two would be committing the error it exists to describe.
NewAgeSysIT built the platform described here under the strategic advisory guidance of Giovanni Livia, as a two-sided on-demand marketplace rather than a directory with a payment step attached.
Evidence, Not Certainty.
No platform can certify a person. A verification service returns what is present in the databases it searches, a rating reflects who chose to leave one, and a conversation reveals what someone chose to say. So a marketplace in a trust-critical category is not in the business of removing risk. It is in the business of supplying evidence, and the difference is architectural before it is legal.
Risk removal
A promise about an outcome the platform does not control
- ·Unverifiable
- ·Moves liability toward the operator
- ·Sedates the roadmap
Evidence supply
A description of a mechanism the platform does control
- ·Checkable
- ·Leaves the decision where it already sat
- ·Keeps the evidence layer being built
The two postures, precisely. Risk removal is a promise about an outcome the platform does not control. Evidence supply is a description of a mechanism the platform does control. The first is unverifiable and moves liability toward the operator. The second is checkable and leaves the decision where it already sat.
The architectural cost, not only the legal one. A team that believes verification has solved trust stops building the evidence layer. Ratings, prior conversation, transaction history and visibility during delivery get filed as nice-to-have, because the hard problem is understood to be handled by a check at onboarding. The claim sedates the roadmap.
The asymmetry that makes this category distinctive. In most marketplaces a bad transaction costs money. Where a service is delivered to a person inside their home, the stakes are of a different kind and the user knows it. That is exactly why they will not accept a badge in place of information. The sceptical user is the normal user here, not an edge case to be designed around.
What evidence supply consists of. A set rather than a single control: documented checks at onboarding, signals that accumulate across completed transactions, direct contact before commitment, and visibility during delivery. No single element carries the weight. The combination is what gives a decision something to rest on.
The second of those four is better studied than the others, and the research is unflattering in a useful way. Nosko and Tadelis, working with internal eBay data, found that the platform's percent-positive feedback measure had a mean of 99.3% and a median of 100%, which is to say it distinguished almost nothing. Their proposed alternative divides positive feedback by total transactions rather than by transactions reviewed, on the insight that silence itself carries information about outcomes. Fradkin, Grewal and Holtz later ran a field experiment on Airbnb's two-sided review system and found that changing when reviews were revealed altered both who left one and what they said. Tadelis's survey in the Annual Review of Economics documents the same pattern across platforms. A rating is not a measurement. It is a sample of the people who chose to respond, and a trust layer that treats it as a measurement has misread its own best signal.
State the boundary here rather than leaving it implicit. None of this makes a decision safe. It makes it better informed.
If the platform cannot certify, the design question becomes what evidence to supply, when in the journey to supply it, and what it costs to supply the wrong kind. Section 04 answers all three.
Sources
- Nosko, C. and Tadelis, S. (2015), "The Limits of Reputation in Platform Markets: An Empirical Analysis and Field Experiment," NBER Working Paper 20830. Internal eBay data: percent-positive feedback had a mean of 99.3% and a median of 100%, distinguishing almost nothing. Their proposed effective-percent-positive measure divides positive feedback by total transactions rather than by transactions reviewed, on the insight that silence carries information about outcomes. Includes a randomised field experiment incorporating the measure into eBay's search ranking.
- Fradkin, A., Grewal, E. and Holtz, D. (2021), "Reciprocity and Unveiling in Two-Sided Reputation Systems: Evidence from an Experiment on Airbnb," Marketing Science 40(6). Field experiment showing that changing when reviews are revealed alters both who leaves one and what they say.
- Tadelis, S. (2016), "Reputation and Feedback Systems in Online Platform Markets," Annual Review of Economics 8:321-340. Peer-reviewed survey documenting the same biases across platforms, including the retaliation dynamic that led eBay to abandon two-sided feedback.
Got Problems? Let Us Help You With the Right Solution
Four Patterns That Promise Too Much or Say Too Little.
Four patterns dominate trust design in service marketplaces, and each one either promises something the platform cannot deliver or withholds something it already has.
The Guarantee
Marketing copy converts a verification step into an assurance: language stating or implying that because a check was run, the outcome is safe.
Three costs follow, in ascending order of how much they matter. It is unverifiable, so a sophisticated user discounts it, and here the sophisticated user is the typical one. It moves liability toward the operator, who has promised something the vendors performing such checks do not themselves claim. And it is architecturally sedating: a team told the problem is solved stops building the layer that would have helped.
The alternative is both the accurate version and the checkable one: describe the mechanism, not the outcome.
The counter-intuitive point is worth ending on, because it inverts what most teams assume about this copy. Precision reads as more competent than reassurance. A reader evaluating this category already knows what a records search can and cannot return, and a vendor writing as though it does not is telling that reader they have not thought about it. Hedging the claim does not rescue it either; a softened guarantee is the same promise with a qualifier in front.
The Directory
The platform's job is understood as discovery, so the product ends at contact details and the relationship continues elsewhere.
What is lost compounds rather than merely being absent. With the transaction off-platform there is no completed booking to attach a rating to, so reputation never accumulates. Every provider is permanently new, and the platform's hundredth visit is worth no more than its first.
The structural consequence is that a directory cannot supply evidence beyond what a provider asserts about themselves, because it holds no record of anything that happened. Self-description is its only signal.
The relationship has to stay on one record for the evidence layer to have anything to accumulate, which is less a feature decision than a definition of what the product is.
Trust Theatre
Badges, checkmarks and shields applied to profiles with no stated referent: the visual grammar of verification without the content.
A badge reading "verified" invites the reader to supply their own definition, and they will supply a more generous one than the platform can support. The platform has then made a claim it did not intend to make and cannot substantiate, which is a worse position than making no claim at all.
The rule is the most portable line in this section. A verification signal is only worth displaying alongside a statement of what was verified. "Identity and background-check verification completed" is longer than a badge, conveys more, and carries a fraction of the risk.
One design observation attaches to this. The impulse toward a badge is a space constraint rather than a trust decision, and it is worth recognising as one before it hardens into a claim. The card was too small, so the sentence became a symbol, and the symbol said more than the sentence did.
Silence During Delivery
Extensive information before the booking, a confirmation screen, and then nothing until it is over.
The misreading underneath it is structural. Teams design trust as a pre-purchase problem because that is where conversion is measured. But the point of maximum uncertainty in a service delivered to a home is not before it is booked. It is while it is happening, and the platform has usually stopped communicating by then.
Silence has a cost the platform does not see. The user fills the gap with a phone call, or with anxiety, and either way the platform has handed the most important part of the experience back to the participants. The alternative is to push state through the delivery itself, so the least visible part of the service becomes the most visible.
| Pattern | What it promises or withholds | Where it breaks | What it costs |
|---|---|---|---|
| The guarantee | Promises an outcome the platform does not control | A sophisticated user discounts it; a vendor would not claim it | Liability, credibility, and a roadmap that stops building |
| The directory | Withholds the record of what happened | Nothing accumulates; every provider is permanently new | The entire evidence layer |
| Trust theatre | Promises whatever the reader infers | The reader's definition is more generous than the data | A claim the product cannot substantiate |
| Silence during delivery | Withholds state the platform already holds | Uncertainty peaks after the conversion metric stops | The most important hour, handed back to the user |
Building an Evidence Layer That Accumulates.
A marketplace trust architecture is a set of decisions about what evidence to supply, when to supply it, and what to keep on the record so that it accumulates, and it begins with accepting that the platform's job is to inform a judgement rather than to replace one.
What follows is product-agnostic. An architect building a home services, tutoring, eldercare or trades marketplace could apply it without ever seeing the implementation in Section 05.
Document the Check, Never Certify the Person
The platform records and displays what verification was performed and what it returned. It never converts that into a statement about the person.
Anyone designing safeguarding into a platform serving children should be working with child-protection expertise alongside engineering, and the architectural observations in this document do not substitute for it. What follows describes how one platform structured and displayed verification data. It is not guidance on safeguarding design, and it should not be read as any.
Implementing it requires verification status modelled as a set of discrete, named checks each with its own state rather than a single boolean, display copy that names the check alongside the result, and a standing policy that the interface may not show a signal the underlying data cannot substantiate.
What it buys, in the order that persuades an operator: a claim that survives scrutiny, liability that stays where it belongs, and the one that is easy to miss, a team that keeps building the rest of the evidence layer because nobody has told it the problem is solved.
Name the discipline required, because this is where the principle fails in practice. The pressure to compress a sentence into a badge is constant, and it arrives from design, from marketing and from the number of pixels available on a card. All three are reasonable in isolation. Somebody has to own refusing them.
One Record, or Reputation Never Accumulates
Discovery, booking, communication, delivery, payment and review belong on a single record, because evidence that accumulates is the only kind that gets stronger.
The mechanism is plain once stated. A rating is only meaningful when it is attached to a completed transaction the platform can see. Move the transaction off-platform and the rating becomes an unverifiable opinion, which is worth close to nothing in a category where the user is already sceptical and knows to be.
Implementing this requires the record to span the full lifecycle, and enough value inside the platform at each stage that neither side wants to leave. A record only stays whole if staying is easier than leaving, which is a product problem rather than a policy one. Terms of service do not hold a relationship on a platform. Convenience does.
What it buys is compounding. A second transaction is better informed than the first, and a hundredth better than the second. That is the whole asset, and it is structurally unavailable to a directory no matter how good its search is.
Two Sides Are Two Products Over One Record
The two sides of a marketplace do not merely have different permissions. They want opposite things. One side optimises for search, comparison and speed. The other for schedule control, work selection and reputation built over time.
Implementing this means two journeys designed independently over a shared data model, with dedicated interfaces rather than one surface with elements hidden per role.
What it buys is that neither side reads as an afterthought, and the supply side in particular gets a product rather than a listing. That usually determines whether supply stays, and supply staying is what the evidence layer in Principle 2 depends on.
Push State During Delivery, Not Only Before It
The platform should communicate most where the user can see least, which is during the service rather than before it.
Implementing this requires a lifecycle modelled as named states rather than a binary, each transition pushed through a channel the waiting party will actually see, and the states chosen for what they resolve rather than for what is easy to detect. Those are different criteria and the second quietly wins by default.
What it buys is that the anxious interval stops being a silence the user fills themselves. This is also the cheapest evidence in the whole architecture, and worth saying so directly: the platform already knows every one of these states. The only decision was whether to say so.
It generalises past this category. Any service delivered out of the user's sight has the same shape, and most products under-communicate in the same window for the same reason. Conversion is measured before the transaction, so design attention concentrates there.
Capture the Transaction and the Money Conversation Ends
Capture the facts that determine payment as the service happens, so the amount is derived rather than negotiated.
Implementing this requires session start and end recorded in the product by the party delivering the work, an agreed rate held on the booking, and the fee calculated from the two, with payment running through the platform rather than settling between the participants.
What it buys has two halves and the second deserves equal weight, because it is the one teams miss. It removes a dispute neither party wants. And it protects the relationship the platform depends on: an end-of-session disagreement over an hour damages a repeat booking more reliably than almost anything else in the experience, and repeat bookings are where a two-sided marketplace makes its money.
The trust consequence ties the principle back to the thesis. A derived number is evidence. A remembered number is a claim, and in a conversation between a customer at their front door and a provider who wants to be rebooked, the weaker party usually concedes it.
At a Glance
The Five Principles
-
01
Document the check, never certify the person.
Sets what the platform may say
-
02
One record, or reputation never accumulates.
Gives it something worth saying
-
03
Two sides are two products over one record.
Keeps both sides present
-
04
Push state during delivery, not only before it.
The first exposed moment
-
05
Capture the transaction and the money conversation ends.
The second exposed moment
Giovanni Livia, Independent AI & Software Solutions Consultant | Implementation by NewAgeSysIT
Principle 1 sets what the platform may say, and Principle 2 gives it something worth saying over time. Principles 4 and 5 are the same idea applied at the two moments the user is most exposed, during delivery and at settlement. Principle 3 is what keeps both sides present long enough for any of it to compound. A platform with 1 but not 2 is honest and thin. With 2 but not 1 it is rich in evidence and careless about what it claims.
One Record, Five Live States.
NewAgeSysIT implemented this architecture for Auntie App, a two-sided childcare marketplace across iOS, Android and web where parents find, book, message, track and pay care providers inside one platform, under the strategic advisory guidance of Giovanni Livia.
Parents on one side, care providers on the other, one booking record between them. Everything below describes how that record is structured and what it carries; the full platform description and client narrative are published in the Auntie App case study.
Booking confirmed
Provider on the way
Provider arrived
Service started
Service completed
All of it on one record, which is what lets a rating attach to a transaction the platform can see
Principle 1 in practice. Providers complete a structured onboarding flow before they can take bookings. It covers a profile carrying background, experience, hourly rate and availability, identity verification, and an integrated background-check service through National Crime Search. That is the mechanism. The platform records which checks were run and what they returned, and it does not convert those records into a characterisation of the person they concern.
Principle 2 in practice. Discovery, booking, messaging, live status, payment and review are held on one record, so ratings and written reviews attach to completed sessions and accumulate across them rather than resetting with each job. A directory would have ended at contact details and had nothing to attach a rating to. The messaging channel matters more here than it looks: because conversation before a booking is confirmed happens inside the platform, the record already carries it by the time a decision is made, which means prior contact becomes one of the four evidence types from Section 02 rather than something that happened somewhere the platform cannot see.
Principle 3 in practice. Two journeys designed separately over a shared data model. Parents get search, filtering and comparison. Providers get availability management, booking acceptance, job status and an accumulating rating, which is a product rather than a listing. The asymmetry is the point: the two sides share a booking record and almost nothing else about what they are trying to do with it.
Principle 4 in practice. Five live states are pushed through the service lifecycle: booking confirmed, provider on the way, provider arrived, service started, service completed. Each transition is carried by push notification and email, so neither party has to ask. The platform already held every one of those states. The architectural decision was to say so.
Principle 5 in practice. Providers start and end the session in the app, which records actual hours and calculates the fee automatically against the rate agreed on the booking, with payment running through Stripe. The end-of-session money conversation does not happen.
The stack, named narrowly and deliberately. React Native, Node.js, Stripe, Twilio and AWS. No frontend or backend framework is named here, because the sources disagree and a whitepaper written for architects cannot ship an unverified stack claim.
Full delivery detail and the complete feature set are published in the Auntie App case study. This whitepaper borrows the evidence. The case study owns the story.
Client Story
Read the full Auntie App case study
Delivery detail, the complete feature set and the client narrative.
A Structural Result, Stated Without Metrics.
This implementation published no performance metrics, and in this category the most tempting kind of metric would be the one least defensible to produce. What follows is structural evidence: what the architecture makes possible, and what it declines to claim.
| Evidence | Conventional | Built | Principle tested |
|---|---|---|---|
| Verification posture | A check at onboarding, described as assurance | Named checks, described by mechanism, outcome never characterised | Principle 1 |
| Relationship boundary | Discovery ends at contact details; the transaction leaves | Discovery, booking, messaging, status, payment and review on one record | Principle 2 |
| Delivery visibility | Confirmation, then silence until completion | Five states pushed from booking confirmed through service completed | Principle 4 |
| Settlement | Hours agreed from memory at the end of the session | Session start and end recorded in-app; fee derived from the agreed rate | Principle 5 |
| Platform scale | Pre-launch | 1,200+ active users, figure dating from October 2025 | Context, not architecture evidence |
Lead on the first row, because it is unusual and worth naming. The most significant decision in this build is one a reader can verify by reading the product's own copy. That is rare. Most architectural decisions are invisible from outside the system, and this one is legible on a profile screen. A platform that describes its checks precisely has made a decision about what it is willing to be responsible for, and it has made that decision somewhere a prospective user can see it.
The remaining rows each trace to a principle rather than to competence in general, and the distinction is worth holding. Reputation accumulates because the record spans the relationship, not because the review feature is well built. The anxious interval closed because five states were pushed, not because notification infrastructure exists. Settlement disputes disappeared because hours are recorded as they happen rather than recalled afterwards. In each case the capability is ordinary and the decision about where to put it is not.
Now what the evidence does not support. There is no measurement of repeat booking rate, provider retention, dispute frequency or conversion. The architecture is evidenced. Its commercial effect is not, and this document does not claim it. The user count carries no baseline and dates from October 2025, so it sits here for context and nothing rests on it.
One figure is worth chasing and it is worth saying which, and why this one. Repeat-booking rate. It would show whether the evidence layer actually changes behaviour, it is obtainable without asking for anything commercially sensitive, and it carries no safety claim whatsoever. It measures whether people came back. That is the only kind of number this document can responsibly publish, and it happens to also be the most useful one available.
The boundary condition. This architecture earns its cost where the user's decision carries stakes beyond money and where the same parties may transact more than once. Where a transaction is one-off and low-stakes, most of the evidence layer is overhead, and a simpler product is the right answer.
Six Decisions Made Before the First Provider Signs Up.
Six decisions shape what a marketplace can honestly say about its supply side. Five of them are made before the first provider signs up, and the first is made in a sentence of marketing copy that nobody treats as an architectural decision.
| # | Decision | What to weigh |
|---|---|---|
| 1 | What you will claim verification does | The copy sets the expectation, and the expectation sets the liability |
| 2 | Whether the record spans the relationship | Off-platform is cheaper and costs you the entire evidence layer |
| 3 | What is checked once versus what accumulates | A snapshot is strongest on day one and never improves |
| 4 | Where in the lifecycle state is pushed | Attention goes where conversion is measured; uncertainty peaks later |
| 5 | Whether the transaction is captured in-product | Removes a dispute, adds real supply-side friction |
| 6 | What you allow to leave the platform | Every convenience that moves contact off-platform costs a piece of the record |
1. What you will claim verification does.
Settle the wording before the feature ships, because the copy sets the expectation and the expectation sets the liability. Describing the mechanism is longer, less punchy, and the only version that survives either a sceptical reader or an adverse event. Deferring this does not leave it open; it means the claim gets written by whoever drafts the landing page, under pressure, to fill a headline. This is not legal guidance. Take advice appropriate to your jurisdiction and your users.
2. Whether the record spans the relationship.
Off-platform transactions are cheaper to build and cost you the entire evidence layer, because nothing accumulates. This decision is usually made by omission. Nobody chooses to be a directory; they just stop building at discovery and discover two years later that their ratings mean nothing.
3. What is checked once versus what accumulates.
A check at onboarding is a snapshot. Ratings, completed bookings and message history are continuous. A trust layer weighted entirely toward the snapshot is at its strongest on the day a provider joins and never improves after that, which is the opposite of the shape you want. Deferring this decision usually means the snapshot wins by default, because it is the part that feels like the trust feature and the accumulating part feels like reporting.
4. Where in the lifecycle state is pushed.
Pre-booking communication is where conversion is measured, so that is where attention goes. The user's uncertainty peaks later. Pushing state during delivery is cheap because the platform already holds every state, and the cost of deferring it is measured in phone calls the platform never sees and anxiety it never learns about. This is the lowest-effort, highest-return item on the list, and it is consistently the last one built.
5. Whether the transaction is captured in-product.
Recording the facts that determine payment removes a dispute and protects the repeat booking. It also requires the delivering party to do something at the start and end of every job, which is real friction on the supply side and has to be designed for rather than assumed. There are products where this is the wrong call. Where sessions are long, irregular or hard to bound, a start-stop requirement adds a failure mode that costs more than the dispute it prevents, and a simpler settlement model is better.
6. What you allow to leave the platform.
Every convenience that moves contact off-platform, a phone number on a profile, a direct email, costs you a piece of the record. Early on, that may well be the right trade. A marketplace fighting for liquidity needs transactions more than it needs a complete evidence layer, and being strict about this before there is anything to protect can kill the supply side you are trying to build. Make it deliberately, and revisit it, rather than discovering later that reputation quietly stopped accumulating.
Speak With Our Consultant
Partners
Pressure-test your architecture before you commit to a data model. 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.
No platform can certify a person. A verification service returns what is in the databases it searches, which means a marketplace in a trust-critical category is supplying evidence rather than removing risk, and describing the mechanism rather than promising the outcome is both the accurate version and the one a sceptical reader finds more credible.
A directory ends at a phone number; a marketplace carries the relationship. Holding discovery, booking, messaging, live status, payment and review on one record is what lets a rating attach to a transaction the platform can actually see, and that is the difference between reputation that compounds and reputation that resets with every job.
A verification badge with no stated referent is worse than no badge, because the reader supplies a more generous definition than the platform can support. "Verified" invites an assumption. Naming what was verified conveys more information and makes a claim the product can stand behind.
The anxious moment in a service delivered out of sight is during it, not before it, and that is precisely the window most products go quiet in, because conversion is measured earlier. Auntie App pushes five live states from booking confirmed through to service completed, which is the cheapest evidence in the whole architecture: the platform already knew every one of them.
Capture the facts that determine payment while the work happens, and the end-of-job money conversation disappears. Recording session start and end in the product means the fee is derived from an agreed rate rather than negotiated from memory, which removes a dispute neither party wants and protects the repeat booking that both of them do.
From Architecture to Implementation.
Delivery Partner
NewAgeSysIT is a custom software development and AI solutions company in Princeton, NJ, specialising in two-sided marketplaces, on-demand service platforms, booking and dispatch systems, and full-cycle development across mobile, web and cloud.
Founded by Johny John, NewAgeSysIT has delivered software across on-demand services, community platforms, logistics, automotive, healthcare and fintech. 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.
Settle What You Will Claim, Before You Ship It
If you are building a marketplace where trust decides whether a transaction happens at all, request an architecture consultation with Giovanni Livia to settle what your platform will claim before it ships the feature that makes the claim.
Read the full implementation narrative in the Auntie App case study.
newagesysit.com | [email protected] | 1-609-331-9194 | 4390 US-1, Suite 110, Princeton, NJ 08540