Home/Case studies/PromoStars: National Promotional Talent Discovery Platform
Named owned platform case study
PromoStars: National Promotional Talent Discovery Platform
A curated national platform that turned promotional-model profiles, location and service data, searchable discovery pages, shortlists, PDFs and enquiries into one structured demand-and-supply system.
PromoStars is an owned platform operated by Leobot Trading CC. It is a public discovery and workflow platform rather than a promotional agency. Profile and growth figures are rounded snapshots from the platform's early 2026 expansion and will naturally change as the marketplace grows.
Executive summary
The operational problem, not only the final interface.
PromoStars was launched in April 2026 to solve a fragmented South African discovery problem. Promotional models and brand ambassadors were spread across social media, agency rosters and informal networks, while buyers had no neutral national search layer for comparing people by city, service and profile evidence. INESSOFT built the platform as a structured directory and workflow system rather than a collection of static profile pages. Within its first growth phase it accumulated hundreds of curated public profiles, created national and city-specific search surfaces, introduced individual Z-cards and shortlist PDF packs, and generated real buyer enquiries without requiring the platform to become an agency.
Business context
Where the system had to operate
The promotional industry is two-sided. Models need visibility, credible profiles and a practical way to be shortlisted. Brands, agencies and event organisers need fast discovery, usable evidence and a way to move from a broad search to a small, shareable selection. The platform therefore had to serve two very different user groups while protecting personal data and avoiding the false impression that every listed person was employed, represented or vetted as agency staff.
Challenge
What the existing method could not control
The first challenge was not merely building registration and profile pages. PromoStars had to create enough structured supply to be useful, maintain profile quality, make the catalogue searchable by real buyer intent, generate indexable content without producing thin SEO pages, and provide a conversion path that did not expose personal contact details to scraping. The platform also had to distinguish a free discovery infrastructure from a traditional staffing agency.
Complexity
Why this was not a generic app
Marketplace software compounds technical and commercial uncertainty. More registrations do not automatically create more useful public supply; more profiles do not automatically produce demand; search visibility can attract the wrong traffic; and user-generated data becomes an SEO and trust liability when it is incomplete or duplicated. A profile directory is easy to demonstrate but difficult to make operationally credible because curation, moderation, privacy, internal linking, search intent and buyer workflow all interact.
Solution overview
How INESSOFT approached the system boundary.
INESSOFT built a controlled profile and discovery platform around a central model record. Registration created a private account and editable profile, but publication remained an administrative decision. Public profiles fed search and filter pages, city and service combinations, structured metadata, sitemaps, Z-card generation and shortlist workflows. Buyers could browse, filter, collect a shortlist, generate a shareable PDF pack and send enquiries through the platform without public email exposure. Administrative tools handled incomplete registrations, profile quality, featured status, partner invitations and ongoing catalogue maintenance.
PromoStars established a new national discovery surface in a category that previously depended heavily on agencies, social media and word of mouth. The platform reached hundreds of curated public profiles within its first months, earned strong organic visibility across national, city and service-intent searches, and created a repeatable buyer journey from search to shortlist and enquiry. More importantly, it taught INESSOFT how structured content, curation and operational marketplace design reinforce each other.
350+Hundreds of profiles were curated and published during the first growth phase rather than auto-enabling every registration.
NationalProfiles and landing pages were structured around South African cities, services and buyer intent.
Z-card + packIndividual profile PDFs and multi-person shortlist packs converted catalogue data into a practical selection artefact.
CuratedAdministrative review protected public quality, privacy and marketplace trust.
SEO-ledProfile depth, city-service routes, internal links and structured data created compounding organic discovery.
Live enquiriesThe platform progressed beyond profile collection and supported real buyer-to-model enquiry workflows.
Reconstructed system view
A visual model of the operating surface behind the case study.
This is a content-based reconstruction, not a client screenshot. It shows the kinds of live inputs,
controlled states, modules and evidence the delivered system had to bring together.
PromoStars: National Promotional Talent Discovery Platform
OPERATING VIEW
350+Early public profiles
Hundreds of profiles were curated and published during the first growth phase rather than auto-enabling every registration.
NationalDiscovery coverage
Profiles and landing pages were structured around South African cities, services and buyer intent.
Z-card + packBuyer documents
Individual profile PDFs and multi-person shortlist packs converted catalogue data into a practical selection artefact.
CuratedPublishing control
Administrative review protected public quality, privacy and marketplace trust.
CONTROLLED EVENT FLOW
01
A model registers and creates a private account.
02
The model completes profile information and uploads suitable images.
03
Administrative review checks completeness, duplication, public safety and presentation quality.
04
An approved profile becomes public and is linked into applicable city, service and discovery pages.
Reconstructed from the documented system boundary; confidential interfaces and client data are not reproduced.
Outcome evidence
Measured facts are stated where they can be defended.
This study contains retained or public quantitative evidence. The figures are presented as operating facts,
not converted into unsupported savings or productivity claims.
350+ Early public profiles
System architecture
The responsibilities were separated before the screens were polished.
Each layer had a specific operational responsibility. This made failures easier to diagnose and prevented one screen,
service or database field from becoming the accidental owner of the entire process.
01Identity and private account layer
Separated login, editable profile data and account administration from the public representation of each model.
02Curated profile publication
Used explicit visibility and enablement states so incomplete or unsuitable registrations did not automatically become public pages.
03Discovery and taxonomy
Structured cities, services, profile attributes and search filters around the way agencies and buyers actually look for talent.
04SEO content graph
Connected profiles, national pages, city pages, city-service routes, static guidance content, metadata, structured data and XML sitemaps.
05Shortlist and enquiry workflow
Allowed buyers to collect profiles, review a smaller set, generate documents and contact people through a controlled platform flow.
06Document generation
Reused the same profile records to create individual Z-cards and combined shortlist packs rather than maintaining separate document data.
07Administration and growth operations
Supported profile review, featured placement, incomplete-profile follow-up, partner-agency invitations, referral logic and catalogue maintenance.
08Trust, privacy and legal layer
Removed public emails, clarified the platform's role, added legal and safety content and kept public contact behind controlled actions.
Responsibility moves through explicit layers; no single screen or integration is treated as the whole system.
Operational workflow
What happened from the first input to the final controlled result.
A case study is useful only when the flow can be understood. The sequence below shows where users, devices,
databases or external systems entered the process and how responsibility moved.
01
Workflow step 1
A model registers and creates a private account.
02
Workflow step 2
The model completes profile information and uploads suitable images.
03
Workflow step 3
Administrative review checks completeness, duplication, public safety and presentation quality.
04
Workflow step 4
An approved profile becomes public and is linked into applicable city, service and discovery pages.
05
Workflow step 5
Search engines and buyers discover the profile through national, city, service or name-based routes.
06
Workflow step 6
A buyer filters the catalogue and adds suitable profiles to a shortlist.
07
Workflow step 7
The platform creates an individual Z-card or combined shortlist PDF from controlled profile data.
08
Workflow step 8
The buyer sends an enquiry through the platform rather than scraping a public email address.
09
Workflow step 9
Administrative records and platform signals reveal which profiles, services and locations attract demand.
10
Workflow step 10
Growth work then focuses on the supply gaps, profile quality issues and buyer-intent pages supported by real evidence.
Major modules
The practical capabilities that made the system usable.
These were not isolated feature requests. Each module supported a specific part of the operational lifecycle
and shared the same data, state and accountability model.
SYSDelivered capability
Model registration and profile editor
Captured identity, city, services, experience, measurements, images and other public-profile information through a private account.
SYSDelivered capability
Administrative publication queue
Allowed the platform operator to review profile completeness, image quality, duplication and public suitability before enabling discovery.
SYSDelivered capability
Search and filter catalogue
Supported buyers looking by city, service, name and other practical profile attributes instead of forcing them through a flat directory.
SYSDelivered capability
Dynamic city and service pages
Generated high-intent discovery routes from structured supply, with related links and counts grounded in real public profiles.
SYSDelivered capability
Profile detail pages
Created a stable public entity page with images, experience, services, city, metadata and a clear path into shortlisting or contact.
SYSDelivered capability
Z-card PDF generator
Converted approved profile data and images into a shareable individual document without repeated manual design work.
SYSDelivered capability
Shortlist and booking cart
Let a buyer collect several profiles before generating a combined pack or sending an enquiry.
SYSDelivered capability
Enquiry and scraper-safe communication
Removed direct public email exposure while still giving legitimate buyers a usable contact route.
SYSDelivered capability
Referral and partner tooling
Created controlled mechanisms for models and agencies to invite additional supply without giving up publication quality.
SYSDelivered capability
SEO administration
Managed canonical routes, sitemaps, structured data, internal links, 404 behaviour and indexable content as the catalogue changed.
Engineering decisions
Choices that protected the system from plausible failure.
The important work was often deciding what not to combine, automate or assume. These decisions made the resulting
system easier to support and more honest about its boundaries.
Curate instead of auto-publish
Raw signup volume was not treated as marketplace quality. Publication became a controlled state so the public catalogue remained useful and defensible.
Model search intent explicitly
Cities and services were stored as reusable data relationships, allowing the same supply to support filters, SEO pages, related links and buyer documents.
Generate documents from the profile source
Z-cards and shortlist packs were rendered from approved platform records so profile updates flowed into future documents.
Protect contact data by default
Public emails were removed because discoverability should not require exposing models to scraping, spam or uncontrolled contact.
Treat SEO as product architecture
Internal linking, route design, indexability, profile quality and useful page intent were built into the catalogue rather than delegated to isolated marketing copy.
Remain a platform, not an agency
The product language and workflow avoided claiming employment, representation or booking responsibility that the operating model did not provide.
Use evidence before monetisation
The early platform prioritised supply, discovery, trust and workflow utility before forcing subscriptions or transaction layers into an unproven marketplace.
Keep incomplete users separate from public supply
Registration interest, profile completion and public publication were measured as different stages rather than one misleading user count.
Delivery approach
A phased path from evidence to a supportable system.
The project was broken into phases that reduced the highest-risk uncertainty first.
This prevented a broad implementation from hiding an unproven data or workflow assumption.
01
Public catalogue foundation
Create registration, profiles, images, administration, enablement and reliable public routes.
02
Supply acquisition and curation
Invite existing industry participants, improve incomplete-profile follow-up and establish a usable national base of public profiles.
03
Structured discovery
Add filters, city pages, service pages, sitemap coverage, metadata and internal links around real profile supply.
04
Buyer utility
Introduce shortlist behaviour, individual Z-cards, combined PDF packs and controlled enquiry flow.
Use search, shortlist and enquiry evidence to decide which cities, services and workflow features deserve the next investment.
Risk controls
Operational risk was designed into the software, not added as a disclaimer.
The controls below reflect the kinds of failure that could produce wrong records, unsafe assumptions,
hidden exceptions or a system users would bypass.
Low-quality public supply
Kept publication behind administrative review and made incomplete registrations operationally visible.
Thin or misleading SEO pages
Built location and service routes around actual public profiles, related searches and genuine buyer intent.
Personal-data exposure
Removed public email addresses and used controlled enquiry paths.
False agency representation
Clarified that PromoStars is a discovery platform and did not imply that every profile was represented or employed by the operator.
Marketplace cold start
Focused first on creating enough curated supply and useful discovery depth before broad monetisation.
Duplicate or abandoned profiles
Used profile states, reminder workflows and administrative review rather than treating every account as a valid listing.
SEO dependency without conversion
Added shortlist, documents and enquiry paths so organic traffic had a practical next action.
Overbuilding the platform
Deferred escrow, complex agency accounts and other heavy features until demand evidence justified the operational burden.
Outcomes
What became more controlled or useful.
A national, searchable public catalogue of curated promotional talent.
Hundreds of live profiles created within the first months of operation.
Strong organic discovery across national, city, service and adjacent buyer-intent searches.
A practical path from profile discovery to shortlist, PDF pack and enquiry.
Reusable profile data powering public pages, filters, documents and internal administration.
Improved privacy through controlled communication rather than public email exposure.
A growing evidence base showing which locations, services and profile types attract attention.
Direct experience building and operating a two-sided marketplace under real search and user pressure.
Engineering lessons
What this system reinforced.
A marketplace is not one funnel. Registration, completion, publication, discovery, shortlisting and enquiry are separate operational stages.
Catalogue quality is a product feature. Curation, images, completeness and accurate taxonomy affect trust as much as interface design.
Structured SEO can become the distribution layer when pages are grounded in real entities and useful relationships.
Supply growth and buyer demand mature at different speeds and require different metrics.
A ranking is only useful when the visitor can compare, shortlist, share and contact without friction.
Public user data requires moderation, privacy defaults and explicit role boundaries.
Reusable documents can turn profile data into an artefact agencies and clients already understand.
The strongest moat is not one feature; it is the accumulated combination of supply, clean data, internal links, history and buyer utility.
What the platform taught us
Technical delivery created product, market and operating lessons.
These lessons came from operating the system under real users, data, commercial constraints and support pressure.
They now influence how INESSOFT scopes new platforms and internal operational systems.
Distribution can be engineered
Search visibility was not treated as a marketing task added after development. The data model, routes, profile depth, internal links and indexation behaviour were part of the product itself.
Category creation needs useful infrastructure
A new directory earns attention when it makes the market easier to navigate. Simply declaring a new platform category would not have created value without searchable supply and practical buyer tools.
Quality matters more than signup totals
A large pool of incomplete accounts can be operationally useful, but it should never be confused with a catalogue of credible public profiles.
Demand-side proof changes priorities
Once real buyers started shortlisting and enquiring, the next improvements could be chosen around conversion and workflow evidence rather than speculative feature lists.
Trust is operational
Privacy controls, publication review, honest platform positioning and safe contact paths create more durable trust than badges or generic claims.
Compounding assets take time
Each approved profile improves search depth, related pages, internal links, shortlist utility and future market intelligence. The catalogue becomes more valuable as history accumulates.
Where this pattern fits
Organisations likely to recognise the same underlying problem.
The exact sector or technology may differ. The closer match is usually the workflow shape, source data,
failure modes and operational responsibility.
Relevant operating pattern
Marketplace founders trying to turn fragmented supply into a structured discovery layer.
Relevant operating pattern
Directories that need to progress from static listings into shortlist and enquiry workflows.
Relevant operating pattern
Staffing, talent, professional or supplier platforms requiring curation and privacy controls.
Relevant operating pattern
Businesses building SEO around real entities, locations and service relationships.
Relevant operating pattern
Organisations needing profile-driven PDF packs or shareable selection documents.
Relevant operating pattern
Buyers evaluating INESSOFT's ability to operate a public platform, not only deliver a private internal system.
Related INESSOFT services
The service lanes most closely connected to this case study.
The case study provides evidence. The service pages define the current delivery boundary, first-step artefacts,
exclusions and technical scope for a new engagement.
SEO systems
Technical Website & SEO Systems
Build websites as structured lead-generation systems with searchable catalogues, detail pages, schema and internal linking.
technical SEO website developmentservice catalogue websiteSEO landing page system
Technologies used or directly represented by the case study.
Technology is listed for precision, but the system boundary and operating process determined the architecture.
ASP.NET CoreRazor PagesSQL ServerEntity Framework CoreAuthentication and profile administrationDynamic SEO routingStructured data and sitemapsPDF generationImage and file handlingEmail workflows
Case study FAQ
Questions a technical or operational buyer may reasonably ask.
Is PromoStars a promotional agency?
No. It is a public discovery and workflow platform. Models create profiles and buyers can browse, shortlist and enquire, but the platform does not present every person as represented or employed by an agency.
Why were profiles manually curated?
A public marketplace inherits the quality of its visible supply. Review reduced duplicate, incomplete, unsuitable and misleading pages while protecting search quality and buyer trust.
What made the SEO approach different from ordinary landing pages?
The pages were generated from real profile, city and service relationships. Search routes, internal links, counts, metadata and sitemaps reflected actual public supply instead of duplicating generic copy across locations.
Did the platform expose model contact details publicly?
Public email addresses were removed. Legitimate buyers could still contact profiles through a controlled enquiry path without turning the catalogue into a scraping source.
What is the most important commercial lesson?
Supply, search traffic and demand are different assets. A platform must measure and improve each stage rather than assuming that a larger directory automatically becomes a marketplace.
Can the same architecture apply outside promotional staffing?
Yes. The pattern is relevant to suppliers, specialists, contractors, venues, tutors and other curated directories where buyers need structured discovery, comparison, documents and controlled contact.
Related case studies
Other systems with overlapping engineering or operational patterns.
A long-running electronics commerce and operations platform that grew from surplus imported components into a technical catalogue, fulfilment system, internal-tool ecosystem and commercial engineering asset.
Named owned platformC# and .NETASP.NET and Razor-based web systems
A low-friction QR service-request system that let guests request assistance from their own phones while restaurant staff managed live table requests through a central dashboard.
Named owned platform.NET 8ASP.NET Core Razor Pages
A mobile field-intelligence platform that converted store visits, product observations, pricing, placement and competitor context into central management visibility for major consumer brands.
Does your operation have the same shape of problem?
Bring one real artefact: a report, spreadsheet, machine signal, job record, certificate,
import file, device or system error. INESSOFT can map the current process and define a credible first phase.
