How I turned a personal frustration into a serverless marketplace on AWS, and what broke along the wayBefore we begin, let me ask you a question: Do you shop online?
If your answer is yes, how long does it take you to decide what to buy and, more importantly, who to buy from?
For me, the answer is embarrassingly long.
Not because I enjoy browsing endlessly, but because I am constantly trying to avoid being scammed or becoming the latest victim of the dreaded “what I ordered vs. what I got” experience. Between comparing vendors, reading reviews, checking social media pages, and looking for signs of legitimacy, shopping online often feels like a research project.
At some point, I began asking myself:
What if there was a platform where verified fashion vendors could showcase their products, allowing shoppers to browse with greater confidence and spend less time worrying about trust?
That question became the foundation of Topsy, a cloud-native fashion marketplace designed to connect shoppers with verified vendors.
Before writing a single line of code, I wanted to verify that I wasn’t the only person facing this problem. So, I conducted a small survey involving 18 women who regularly shop online. The results confirmed what I suspected: concerns about trust, scams, and product quality were common experiences among online shoppers. Their responses can be viewed here.
Over 57% had been scammed or nearly scammed while shopping through informal channels like Instagram, WhatsApp, and TikTok. Many spent between 30 minutes and over an hour searching for a single item across multiple platforms. And nearly every respondent said the same thing: they would use a trusted, dedicated marketplace if one existed.
The top features they wanted were not complicated. They wanted verified seller badges. They wanted buyer reviews. They wanted secure payment. They wanted to know that the person selling to them had been checked.
Trust was not a nice-to-have. It was the entire barrier.
As an Economics graduate, I immediately saw both a business opportunity and an analytics opportunity. Understanding customer behavior, purchasing patterns, vendor performance, and trust factors could help create a better shopping experience while generating valuable insights for marketplace operators.
At the same time, I had recently completed my AWS Cloud Practitioner certification and wanted an opportunity to apply my cloud knowledge in a practical setting. Rather than building another tutorial project, I decided to solve a real problem.
The result was Topsy.
What Topsy Is
Topsy is a serverless fashion marketplace built entirely on AWS. It allows buyers to browse verified fashion products across four categories (In-Office, Out-of-Office, Casual, and Spicy), select sizes and colors, add items to cart, and pay via Ghana’s mobile money ecosystem or card through Paystack. Sellers can list and manage their products. An admin analytics dashboard tracks marketplace performance, customer behavior, sales trends, and seller activity.
♦Topsy home page showing product gridThe marketplace currently features 15 products across the four categories, listed by three verified Ghanaian sellers: Abena Collections, Style by Ama, and Akosua Couture.
♦Product detail page with verified seller badgeIn this article, I’ll walk through the problem, the research, the architecture, and how I transformed a personal frustration into a cloud-native solution.
Turning the Idea into an ArchitectureEvery component of Topsy runs on AWS, provisioned across four CloudFormation stacks.
Storage and Databasetopsy-storage creates two S3 buckets (product images and frontend files) and eight DynamoDB tables covering products, orders, users, cart, reviews, inventory, payments, and market research data.
Authenticationtopsy-auth provisions AWS Cognito for user authentication, handling sign-up, email verification, login, and password reset. It supports two roles — buyers and sellers — routing each to the correct experience after login.
♦Topsy login pageContent Deliverytopsy-cdn puts CloudFront in front of the S3 frontend bucket, serving the site over HTTPS with an Origin Access Control (OAC) policy so the S3 bucket is never publicly exposed.
The Backend APItopsy-api provisions an API Gateway with ten REST endpoints and seven Lambda functions in Node.js 24.x — covering product browsing, cart management, seller product management, and order retrieval. Lambda runs code only when called, so there are no idle servers to pay for.
♦Lamda functionsCI/CD PipelineThe deployment pipeline was set up separately from the CloudFormation stacks using AWS CodePipeline and CodeBuild. Every push to GitHub triggers an automatic build, S3 sync, and CloudFront cache invalidation. Push code, it goes live, no manual steps.
♦CodePipeline executionsThe Frontend: What Users SeeThe buyer-facing side of Topsy is built in React and served via CloudFront. It includes a login page, a product browsing page with category and item type filters, individual product pages, and a cart with a full payment flow.
♦Cart page and payment processThe payment flow was designed specifically for Ghana’s ecosystem. Paystack is integrated as the payment gateway, supporting MTN Momo, Telecel Cash, AirtelTigo, and card payments. This reflects one of the strongest findings from the survey, that buyers want payment to feel safe and familiar, not foreign.
The Analytics Dashboard: Where the Data Tells the StorySince Topsy is a new platform with no real transaction history yet, I simulated a dataset to power the analytics dashboard. Crucially, this dataset was not random — it was designed to correlate directly with the findings from my 18-person survey.
Budget tiers in the simulation match survey responses: 50% of simulated users have budgets under 50 GHC, 28% between 50 and 150 GHC, and the remainder above that. Payment method distribution reflects Ghana’s mobile money reality, with MTN Momo accounting for 48% of transactions. Peak shopping hours, lunchtime and evenings, are weighted to reflect when Ghanaian women said they browse most. The casual and in-office categories are weighted as the most popular, consistent with what respondents said they shop for.
The result is a dataset that tells a believable, research-grounded story about what a Ghanaian fashion marketplace might look like in its early months.
♦What the Dashboard ShowsOverview tab — The headline numbers from the demo dataset: GHC 39,973 in total revenue across 383 orders, a 76% delivery rate, a 4% cancellation rate, and an average order value of GHC 108. Six business insight cards summarize the key findings in plain language — for example, that casual wear generated 52% of all orders between January and July, and that 80% of transactions were completed via mobile money.
♦Admin dashboard Overview tab based on simulated data.Sales tab — A monthly revenue trend line shows performance from January to July. A category breakdown confirms casual wear and in-office styles as the top performers. A payment methods chart shows the dominance of mobile money. The top products chart shows that the Basic Crop Top at GHC 45 was the highest-ordered product — consistent with the survey finding that the majority of respondents have budgets under 50 GHC.
♦Sales tab based on simulated data♦Sales tab based on simulated dataBehaviour tab — This is where the market research and the data connect most directly. A conversion funnel shows the journey from store visit to completed order. A retention curve tracks how customers return over time. Peak hour and day-of-week charts confirm the lunch and evening shopping patterns from the simulation. And two charts drawn directly from survey data show the most-requested platform features and the biggest pain points respondents faced — with vendor trust concerns topping both lists.
♦Behaviour Tab based on siumulated dataSeller's tab — Performance data for each of the three verified sellers, showing order counts, revenue, and average order value.
Why This MattersThe analytics dashboard demonstrates something that goes beyond the cloud infrastructure. It shows how primary research data can be used to shape a product and inform a simulated dataset, which then powers a live analytics layer. This is the loop that data analysts work in — define the question, collect data, model it, visualise it, draw conclusions.
The survey said trust is the barrier. The product addresses trust with verified seller badges and integrated reviews. The demo dataset reflects the budget and behaviour patterns from the survey. And the dashboard lets you see it all in one place.
Key Technical ChallengesNo project like this goes smoothly from start to finish. A few things that caught me out and are worth documenting:
API Gateway path conflicts. You cannot have two sibling variable path parts at the same level in API Gateway. Having /cart/{userId} and /cart/{cartItemId} as siblings causes a deployment error. The fix was to nest them: /cart/{userId} for fetching a cart, and /cart/{userId}/{cartItemId} for updating or deleting specific items.
Lambda handler naming. On Linux build servers, filenames are case-sensitive. If the Lambda function code file is named getProducts.js but the CloudFormation handler property says GetProducts.handler, it fails. Matching exactly matters.
CORS configuration. Cross-Origin Resource Sharing (CORS) errors occur when a frontend on one domain tries to call an API on another. The fix requires two things: enabling CORS in API Gateway and making sure every Lambda function returns the correct Access-Control-Allow-Origin header in its response, including error responses, and including the OPTIONS preflight request handler.
CloudFront caching. After each deployment, CloudFront can serve stale cached content until an invalidation request clears it. This invalidation is now automated in the CI/CD pipeline, but it took a few debugging sessions to understand why changes weren’t showing up after deploying.
IAM permissions. Every time a new AWS service interaction was introduced; CodePipeline writing to S3, Lambda reading DynamoDB, CodeBuild invalidating CloudFront, a new IAM permission had to be explicitly granted. AWS’s least-privilege model means nothing is permitted by default, which is the right security posture but requires careful attention.
What’s NextTopsy is a working foundation. There are several clear directions from here:
Expand the survey. The current dataset is drawn from 18 women. I am extending the same survey to male respondents to understand whether the trust and scam problems are specific to women’s fashion shopping or reflect a broader Ghana e-commerce pattern. The findings will inform whether Topsy should expand to menswear or remain focused.
Seller-side analytics. The seller inventory page currently uses placeholder data. Connecting it to the real API will allow sellers to see their own performance data. Orders, revenue, and stock levels, directly from the dashboard.
Bigger data infrastructure. The current analytics pipeline uses DynamoDB as the data store and a Lambda export function to write CSV files to S3. The natural next step is to replace this with AWS Glue for ETL processing, Amazon Redshift as a data warehouse, and Amazon Athena for SQL queries, the standard big data stack on AWS.
Final ThoughtsTopsy started as a personal frustration. It became a research project. Then a product. Then a cloud architecture. Then an analytics story.
The AWS Cloud Practitioner exam teaches you what the services are. Building Topsy taught me how they connect, why the configuration details matter, and what breaks when you get them wrong.
♦I Got Tired of Being Almost Scammed Online. So, I Built a Marketplace was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.