Short answer
RaftLabs built Sponzee, influencer marketing software for creator discovery, collaboration requests, in-app negotiation, tracked promotions, a short-form feed, and manual admin review. The documented mobile build took 16 weeks. The client reported 200% engagement growth in month one and a 25% lift in brand sales; RaftLabs has not independently audited those outcomes.
Sponzee's founders wanted influencer marketing software that joined the buyer journey and the campaign workflow. Brands needed to find creators, agree collaboration details, issue trackable promotional assets, and review results. Creators needed one place to receive requests, discuss terms, and see the product, code, link, and conditions attached to each collaboration. End users needed a feed built for content discovery. Operators needed an admin surface for accounts, posts, and platform activity.
RaftLabs turned that brief into a mobile product in 16 weeks. The delivered scope joined creator discovery, collaboration requests, in-app chat, affiliate links and collaboration codes, a short-form feed, and manual content approval. It used Flutter for the mobile experience, React.js for the admin surface, Hasura for the data and API layer, and AWS Cognito for authentication and authorization.
The client reported 200% growth in user engagement during the first month and a 25% lift in brand sales. Those are client-reported post-launch outcomes retained in the project record, not results independently audited by RaftLabs. This case study therefore uses them as outcome evidence with that boundary, rather than claiming that one feature alone caused either change.
For teams assessing a similar build, the useful evidence is the implemented workflow: RaftLabs shipped a multi-role mobile app development project that connected the consumer feed with the operational work behind each creator campaign.
before & after
The product brief and the delivered workflow
- Creator discovery was difficult to manage as a repeatable brand workflow
- Brands and creators lacked one collaboration record for the request, discussion, product, promotional assets, and terms
- Promotions were difficult to connect back to the creator and collaboration that generated them
- Creator, brand, end-user, and admin responsibilities needed distinct product experiences
- Platform operators needed a way to manage accounts, review posts, and monitor basic activity
- Brands can search creator profiles and send collaboration requests from the product
- In-app chat keeps the discussion beside the collaboration workflow
- Each collaboration can carry the product details, collaboration code, affiliate link, and agreed terms
- Users can discover creator content through a continuous short-form feed
- Admins can manage accounts, approve posts before publication, and review collaboration, post, and user activity
The product decisions that made the build difficult
- 01
One product had to serve four roles without blurring responsibility
Creators, brands, end users, and administrators enter the product for different reasons. A brand searches and initiates a collaboration. A creator evaluates the request and produces promotional content. An end user consumes that content. An administrator governs accounts and publication. We treated those roles as separate workflows sharing one data model, so each screen could expose the actions and information relevant to the person using it.
This is a central diligence question for any marketplace development project. The interface can look simple while permissions, record ownership, status changes, and exception handling remain complex underneath.
- 02
The content feed and campaign operation had to meet at one traceable record
The feed was only the visible surface. Behind each promotional post, the brand and creator needed a collaboration containing the product, terms, affiliate link, and collaboration code. That record connected discovery and negotiation to the promotional asset used later. It also gave the admin team enough context to review content before it appeared in the feed.
The retained project material confirms that linkage. It does not preserve a complete attribution specification, so this case study does not claim a particular cookie window, last-click rule, server-side redirect design, fraud model, or cross-device matching method.
- 03
Manual moderation needed an operational home
Sponzee used admin review and approval before posts appeared on the timeline. The admin product also exposed counts and activity for collaborations, posts, and users. This was a manual governance workflow. The project evidence does not support claims of AI feed ranking, automated moderation, or machine-learning recommendations, so none are attributed to this build.
the build
What RaftLabs built for Sponzee
The implementation followed one path from creator discovery to governed promotional content. That path matters more to a buyer than a long feature inventory because it shows whether the team understood how the product's consumer and business sides depended on each other.
Creator profiles turned discovery into the start of a workflow
Creators could create profiles and connect their social accounts. Brands could search for relevant creators, review those profiles, and initiate a collaboration request. Discovery therefore ended in a product action rather than a separate email or spreadsheet handoff.
For a future version, the search filters and data imported from each social platform would need to be agreed during discovery. The retained case record confirms account linking and creator search, but it does not justify claims about live follower verification, audience authenticity scoring, or automated matching.
In-app discussion stayed attached to collaboration details
Brands and creators could discuss a collaboration through in-app chat. The collaboration record gave creators access to the product being promoted, the collaboration code, the affiliate link, and the terms and conditions. Active work was therefore represented as structured product data rather than conversation alone.
The evidence confirms the collaboration workflow and chat. It does not establish an escrow, contract-signing, invoicing, or creator-payout system. Buyers who need money movement should treat payment onboarding, refunds, disputes, tax reporting, and payout reconciliation as a separate scope.
Affiliate links and codes connected promotions to collaborations
Brands could generate a masked affiliate link and share it with the creator. Creators could use the affiliate link and collaboration code when publishing promotional posts on Sponzee or other social platforms. Brand-side reporting exposed campaign activity tied to those promotional identifiers.
That is the documented boundary. A new product still needs an explicit attribution contract covering conversion events, attribution windows, refunds, duplicate events, consent, and reporting reconciliation. Sponzee's retained materials do not document those rules, so this case study does not fill the gaps with assumptions.
A short-form feed and admin review joined discovery with governance
End users could move through a continuous feed, follow creators and brands, and interact with promotional content. Before a post appeared on the timeline, an administrator could review and approve it. The admin surface also supported account management and visibility into collaboration, post, and user activity.
This gave Sponzee both sides of the operating model: an audience-facing discovery surface and a controlled publishing workflow. Teams planning a similar e-commerce product should decide early which content requires review, who can overturn a decision, and what happens to an active campaign when a post or account is rejected.
The stack notes below separate the project record from general platform capability. Flutter's architecture documentation describes code reuse across iOS and Android, Hasura documents GraphQL subscriptions, and AWS documents permission management through Cognito user groups. Those sources explain what the technologies support. They do not prove which optional capability or configuration Sponzee used.
stack
The documented Sponzee technology stack
- 01FlutterThe project record identifies Flutter as the mobile application framework. Flutter's documented cross-platform model supports code reuse across iOS and Android, which fits a product serving one shared creator and brand community.
- 02React.jsRaftLabs used React.js for the browser-based admin experience covering account management, post approval, and activity views. The retained record confirms that surface without claiming a specific component architecture or performance benchmark.
- 03HasuraThe project used Hasura GraphQL for data access and API development across creator, collaboration, content, and admin workflows. Hasura supports GraphQL subscriptions, but the retained project record does not preserve the exact subscription topology or production configuration.
- 04AWS CognitoAWS Cognito handled authentication and authorization for the product. Cognito supports user groups and permission mapping; this case study does not infer Sponzee's exact role-claim configuration from that platform capability.
outcomes
What we achieved
The founders began with a product vision spanning four roles, creator discovery, collaboration, promotional tracking, a content feed, and administration.
The earlier workflow did not provide one product record connecting creator collaboration details with affiliate links and collaboration codes.
Sponzee was a new product combining campaign operations with a short-form content experience. The retained evidence does not isolate which feature caused the change.
Buyer questions about the Sponzee build
The documented scope includes a Flutter mobile app, a React.js admin surface, a Hasura GraphQL data and API layer, and AWS Cognito authentication and authorization. Product workflows covered creator profiles and connected social accounts, brand search, collaboration requests, in-app chat, product and terms records, affiliate links and collaboration codes, short-form content, manual post approval, account management, and basic platform activity views.
That scope makes Sponzee relevant proof for buyers evaluating custom influencer marketing software or a creator marketplace. The 16-week timeline is a historical project fact, not a promise that every product with a similar label will take the same time.
They are client-reported outcomes recorded with this project: 200% engagement growth in the first month and a 25% lift in brand sales. RaftLabs does not hold an independent audit or raw analytics export in the retained case-study evidence, so the page labels both figures as client reported. It also avoids claiming that the feed, affiliate links, or another individual feature caused the outcomes on its own.
The documented implementation used a masked affiliate link and a collaboration code associated with the brand-creator collaboration. Creators could use those assets in promotional content on Sponzee and external social channels, while brands could review activity associated with the campaign.
The retained material does not specify the attribution window, event deduplication, cross-device rules, consent model, refund handling, or fraud controls. Those decisions belong in the acceptance criteria for a new build and should be tested with real campaign scenarios before launch.
The available project evidence does not support either claim. It documents a continuous social content feed and an admin workflow that reviewed and approved posts before publication. RaftLabs therefore presents Sponzee as influencer marketing and social commerce software with manual moderation, without adding an AI discovery, ranking, matching, or moderation story that the record cannot prove.
The retained scope documents affiliate links, collaboration codes, campaign details, and reporting. It does not document checkout, escrow, invoicing, refunds, tax reporting, or creator payouts. A buyer who needs those capabilities should scope the complete money flow separately, including who receives funds, when a creator becomes eligible for payment, how disputes affect settlement, and which payment provider or marketplace rules apply.
Start with the operating path rather than a feature list: who can join, how creators are verified, what a brand sees during discovery, how a collaboration changes status, what data belongs in the agreement, how promotional events are attributed, which content needs approval, and what happens when a post, link, account, or payout fails.
Then define the first release around one complete campaign loop. A searchable creator directory without collaboration operations leaves work outside the product. A feed without governance creates an operating burden. Attribution without a written event and reconciliation policy produces numbers the commercial team cannot trust. RaftLabs can map that first loop before estimating the build.
Sponzee's retained case-study record does not include its contract value. Under RaftLabs' current planning model, a social-platform MVP generally falls between $35,000 and $70,000, while a fuller build generally falls between $70,000 and $120,000. User roles, video handling, social integrations, attribution, moderation, payments, and reporting can move the scope within or beyond those bands. The pricing guide explains the current delivery model; a project estimate follows a written feature and risk scope.
