Translating User Feedback into Product Features in Early-Stage Startups
Advisor: Mr. Ong
Internship Location: SideShift, 85 Broad St, New York, New York, 10004
Onsite Mentor: Mr. Drew Levin
The creator economy has grown explosively, yet many creators remain burdened by administrative complexities that stifle their creative output. While established companies rely on extensive product management teams to solve such issues, early-stage startups often lack the resources to systematically translate user needs into scalable features. My project addresses this gap at SideShift, a User-Generated Content (UGC) marketplace connecting brands with creators, under the mentorship of Mr. Drew Levin, co-founder and CTO at the startup. Through a dual-track approach of academic research and software engineering, I am investigating how resource-constrained startups can effectively operationalize user feedback. My methods include conducting in-depth user interviews and surveys with SideShift’s creator base to identify workflow pain points, followed by a rigorous competitive analysis. Using Agile development cycles and the RICE prioritization framework, I am designing and implementing a fully functional Creator Management System—featuring campaign dashboards, performance analytics, and in-built payment processing—directly into the live SideShift platform. Concurrently, I am producing a comprehensive case study documenting this entire lifecycle from raw feedback to final code. This project moves beyond theoretical models to test product development frameworks in a real-world, high-velocity environment. By measuring user adoption and task efficiency post-launch, I expect to demonstrate that structured, feedback-driven development significantly improves user satisfaction and platform retention. Ultimately, this research provides a replicable roadmap for startups to balance agility with user-centric design, ensuring technology serves the people who use it.
Project Blog
Week 0: Blog: Decoding the Chaos of the Creator Economy
If you ask a kid today what they want to be when they grow up, "YouTuber" or "Influencer" is now more common than "Astronaut." The Creator Economy has exploded into a $250 billion industry, yet for the 50 million people creating content worldwide, the backend of their business is often a chaotic mess of spreadsheets, missed payments, and fragmented tools.
Welcome to my Senior Project. Over the next ten weeks, I’m stepping out of the theoretical classroom and into the fast-paced world of SideShift, a User-Generated Content (UGC) marketplace based in New York City.
Startups live and die by their ability to listen to their users. But how does a small team with limited resources actually hear what thousands of users are screaming for, and then translate that noise into functional software features without breaking the bank?
My project, "Translating User Feedback into Product Features in Early-Stage Startups," aims to answer that, and I won’t just be researching this process, but living it. I am working directly with the SideShift co-founders to identify the biggest pain points for their creators.
My goal? To design and code a fully functional Creator Management System—a dashboard that handles campaigns, analytics, payments, and more—integrated directly into the live SideShift app, creating tools that benefit both creators and the brands that hire them. And not only that, but to document this full process to create an easily replicable case study that other early-stage startups can use beyond just the scope of SideShift.
But why SideShift?
I’ve always believed in technology "for people." It’s easy to write code in a vacuum, but it’s much harder to build tools that solve genuine human problems. SideShift offers the perfect laboratory: it’s a high-growth startup where the stakes are real. If I build the wrong feature, we lose users. If I build the right one, we help hundreds of thousands of people turn their hobby of content creation into a sustainable career.
This blog will be my field journal. I’ll be documenting the highs of shipping code, the lows of debugging the most frustrating of errors, and the critical lessons learned from interviewing real users. You can expect deep dives into Agile development, insights into the NYC startup culture, and an honest look at what it takes to bridge the gap between user feedback and product launch.
I invite you to follow along as I attempt to bring a little more order to the chaos of the creator economy.
Let’s get to work!
- Neev
Week 1: Building Smart, Not Just Fast
It’s officially Week 1 of my senior project at SideShift! When you're sitting in a fast-paced startup environment, the temptation is to immediately open up your code editor and build the biggest, flashiest feature possible. Initially, I wanted to build an all-in-one super-dashboard that did absolutely everything. But after doing my research, I realized that’s exactly how startups waste time, burn through engineering resources, and build things nobody actually wants.
Instead of falling into the over-engineering trap, I spent this week laying down a strategic foundation using the "Build-Measure-Learn" loop from Eric Ries’s Lean Startup methodology. Rather than coding a massive ecosystem right out of the gate, I’m restricting myself to a Minimum Viable Feature (MVF). I want to isolate the single biggest overlapping headache between our creators and brands—which currently looks like campaign deliverable tracking and payout visibility—and build a lightweight version of that first. To measure if it actually works, I won't just look at button clicks. I’ll be tracking a much more real metric: the reduction in panicked Slack messages and support tickets asking, "When is this content due?" or "Did my payment go through?" If the rollout shows that users love the workflow tools but ignore the analytics, I’ll know exactly where to pivot my engineering hours for the next iteration.
But to confirm I'm building the right MVF, I have to get inside the users' heads. This week, I designed two distinct interview protocols for the two sides of our marketplace. For the creators, I want to map their exact journey from the moment a campaign is accepted to the second the money hits their bank account, pinpointing every administrative nightmare along the way. For the brands, I’m digging into the bottlenecks that prevent them from scaling up their influencer campaigns. To get past surface-level answers, I’m employing a classic product management trick called the "5 Whys." If a user says tracking deadlines is hard, I will ask "why" repeatedly until we hit the root cause (which is usually that their data is scattered across several different email threads). I’m also making a highly actionable ask at the end of every call: having them share their screen to show me the (often messy and chaotic) spreadsheets they currently use. Seeing how they duct-tape their workflow together is going to be my best blueprint for my future features.
Finally, I couldn't ignore the competition in the industry. I mapped out a competitive analysis matrix looking at other platforms in the space, like Growi, Shortimize, and Viral.app. While some have incredible analytics or CRM tools, there is a glaring gap in the market for a unified hub that natively connects a brand's brief directly to a creator's timeline and payment flow. That gap is exactly where SideShift can win.
With the research framework built and the competitive landscape mapped out, I’m ready to dive into the practical side of my project. Next week, the real fun begins: actually talking to the users.
Week 2: Let the Data Do the Talking
Last week was all about laying the theoretical groundwork. This week, it was time to get out of the building (figuratively speaking) and actually talk to the people using SideShift. If there is one thing I’ve learned early on in this project, it’s that users will tell you exactly what is broken if you just ask them the right way.
Initially, I planned to use open-ended questions for my user research. But I quickly realized that reading through hundreds of varying text responses would create a massive data bottleneck and make it incredibly difficult to translate feedback into actionable engineering tasks. So, I pivoted. I restructured my Typeform surveys to focus on categorical, multiple-choice questions—effectively forcing users to rank their pain points.
The response was overwhelming. In just a few days, I collected data from 142 active creators and 38 brand marketers. When I crunched the numbers, a very clear, two-sided story emerged. For the creators, financial anxiety is the ultimate friction point; a staggering 68% cited chasing payments and invoicing as their biggest headache, and 55% admitted to constantly refreshing their connected Stripe accounts just to see if they got paid. On the brand side, 63% stated that managing content approvals and revisions was the primary bottleneck preventing them from scaling up their influencer campaigns.
To back up these self-reported claims, I dove into SideShift’s actual platform analytics. The data perfectly mirrored the surveys. I found a significant number creators who accept a pitch and then fail to submit their first draft on time, proving the desperate need for an in-app deadline tracker. Furthermore, the "Account Settings/Billing" page is one of the most accessed pages by active creators. During some one-on-one interviews, I even had creators share their screens, revealing the complex webs of Notion boards and Google Calendars they use to duct-tape their workflows together.
Synthesizing all of this, the path forward for my Minimum Viable Feature (MVF) is incredibly clear. Both sides of the marketplace ranked a "Centralized Campaign Dashboard" as a top-two priority. Therefore, I am locking in three core engineering themes for the build: Financial Visibility (an earnings tab with clear payout statuses), Deliverable Synchronization (a Kanban board for tracking drafts and approvals), and Reporting Overhead (a lightweight analytics module).
We know what the users want and what the data supports. Next week, the challenge is figuring out what to build first by putting these features through the RICE prioritization scoring matrix. Stay tuned!
Week 3: Crunching the Numbers on What to Build First
Last week, the users spoke. Loudly. I ended up with a mountain of data pointing toward four potential features we could build to fix SideShift’s workflow issues: an earnings dashboard, a Kanban-style campaign board, an in-app messaging hub, and a fancy analytics module.
If it were up to my own engineering ego, I’d probably try to build the messaging hub or the analytics tool. They sound technically complex, flashy, and fun to code. But that’s exactly how startups fail—building what the engineer wants to build instead of what the user actually needs. To completely remove my own bias from the equation, I turned to a classic product management framework called RICE.
RICE stands for Reach (how many users will this touch?), Impact (how much does this actually solve their core problem?), Confidence (how sure are we based on our data?), and Effort (how many weeks will this take me to implement?).
When you force your ideas through this lens, the flashy features start to look like massive traps. Take the analytics module, for example. It would be amazing for brands to see their ROI, but relying on unstable, ever-changing public APIs from TikTok and Instagram tanked my "Confidence" score and spiked the "Effort" estimation. What about the in-app chat hub? Sure, everyone hates scattered emails, but building real-time WebSockets and database syncing for a chat app would take a month of engineering time I simply don't have right now.
To make the final call objectively, I wrote a quick Python script using the pandas library to calculate and sort the weighted RICE scores. I fed it my metrics for the four features, ran the code, and let the math decide our Minimum Viable Feature (MVF) roadmap.
The script didn't hold back. The Earnings & Payout Dashboard absolutely obliterated the competition with a RICE score of 225.0. Why? Because it impacts 100% of our creators, solves their number one friction point (financial anxiety), and only takes about two weeks of effort to integrate with Stripe. Coming in second was the Kanban Campaign Board with a score of 101.3, which perfectly addresses the brands' biggest bottleneck of tracking content approvals.
The chat hub and analytics module scored a measly 38 and 16, respectively. They are officially benched to the post-launch backlog.
It feels incredibly satisfying to have a mathematically backed product roadmap instead of just guessing in the dark. I spent the rest of the week writing out the exact product requirement documents (PRDs) and user stories for these two winning features. Next week, the visual work begins: I'm opening up Figma to translate these concepts into actual wireframes!
Week 4: The Death of the Kanban Board (And Why That's a Good Thing)
Last week was all about spreadsheets, Python scripts, and objective math. This week, it was finally time to open up Figma and start visualizing what these tools will actually look like for SideShift’s users.
Before pushing any pixels, I sat down and mapped out the exact user journeys. I needed to understand the cognitive path a creator takes from getting a campaign approval notification to seeing the money in their account. Based on those flows, I built two high-fidelity prototypes using our existing Tailwind CSS design system.
The first design was a "Data Table" view for the new Earnings Dashboard. It featured top-level KPI cards showing total paid and processing amounts, followed by a clean, vertical list of transactions with color-coded status pills. The second design was for our Campaign Deliverables tracker, and I decided to go with a classic "Kanban Board" layout—think Trello, with horizontal columns where users could drag and drop their campaigns from "To-Do" to "Drafting" to "In Review." I thought it looked incredibly sleek and modern.
Then, I actually put it in front of the users.
I jumped on Google Meet with four active creators for some rapid usability testing, and they gave me a brutal (but necessary) reality check. The good news? They absolutely loved the Data Table for their earnings. One creator told me, "It looks like a real bank statement. I can see exactly what is clearing and what is stuck at a glance."
The bad news? They hated the Kanban board. While I thought the drag-and-drop interface was interactive and cool, they found it clunky, especially on smaller screens. One creator's feedback hit the nail on the head: "This feels too much like Jira or a corporate tech job. I don't want to drag cards around, I just want a simple list of what's due."
Ouch. But honestly, this is exactly why the Lean Startup methodology works. If I had skipped the prototyping phase and gone straight into coding, I would have wasted weeks building a complex drag-and-drop interface that our users actively disliked. Instead, I made a rapid pivot. I completely scrapped the Kanban layout. The underlying state management concept remains, but visually, the campaign tracker will now mirror the clean, vertical data-table structure of the Earnings page, using simple dropdown menus to update statuses.
With the UI debate officially settled, I spent the rest of the week wearing my backend engineer hat. I designed the NoSQL database schemas for Firebase, defining exactly how our "campaigns" and "payouts" collections will structure their JSON data. I also planned out the architecture of the TypeScript API endpoints that will handle these status updates and trigger the Stripe payouts.
The blueprints are finalized. The database is mapped. Next week, we finally start writing production code!
Week 5: Turning Pixels into Code
It’s officially Week 5, which means my Figma files and Python scripts are finally making way for actual production code. There’s always a distinct thrill (and a little bit of terror) when you finally clone a startup’s core codebase and create your own feature branch. For me, that branch is officially dubbed "feat/creator-campaign-dashboard".
Before writing a single line of user-facing code, I had to set up the plumbing. SideShift handles real-time financial states and active brand campaigns, so testing my messy first drafts on the live database was absolutely out of the question. I spent my first day configuring the Firebase Local Emulator Suite. This essentially creates a localized, "fake" version of our NoSQL database right on my laptop, allowing me to read and write data without accidentally altering a creator’s real-world paycheck.
Once my sandbox was secure, I built the engine. Using Node.js and Typescript, I wrote the RESTful API routes that will power the new dashboard. The most critical part of this was security. I tied my new endpoints directly into SideShift’s existing authentication middleware. Now, when a creator’s app asks the server for their active campaigns, the database strictly filters the request using their unique user ID token. I also built the route that handles status updates, implementing strict validation so the database only accepts exactly four commands (like "pending" or "completed"), preventing any corrupted state data.
With the backend APIs humming along, I switched over to the frontend. Remember last week when our beta testers almost unanimously voted to kill the drag-and-drop Kanban board? I honored that pivot. I built out the new React components using Tailwind CSS, focusing entirely on the high-density, clean data table they asked for. Instead of dragging cards across a screen, users now just click a simple, intuitive dropdown menu to update their project's progress.
By the end of the week, I had my "It's alive!" moment. I wired the React frontend to the Express backend, clicked the dropdown in my UI, and watched the local Firebase emulator instantly update the document state. It worked seamlessly.
Next week, I expand. I’ll be working with the Stripe API to tie these status updates directly to actual payouts! Plus, I'll dive into my second (and larger) project: a brand new messaging system!
Week 6: A Major Pivot
According to my originally planned project timeline, this week was most likely going to be dedicated to building a shiny new Analytics module. But if I’ve learned anything from the Lean Startup methodology, it’s that you have to respect the data. Back in Week 3, the Analytics module scored a dismal 16.0 on our RICE prioritization matrix, while the Earnings Dashboard scored a massive 225.0. So, I made the decision to formally sideline the analytics build for now. Instead, I reallocated all my engineering hours this week to bulletproofing our payment infrastructure, focusing on the clearly more important financial side of the marketplace.
And it’s a good thing I did, because I hit a massive architectural wall on Monday morning.
My original plan was to use Stripe Connect to handle our creator payouts. However, when reviewing SideShift’s diverse, global user base, I realized Stripe was going to severely limit our ability to execute international transfers efficiently. It also lacked the flexible payout options (like crypto/stablecoins and localized digital wallets) that modern creators actively demand. I had to pitch a complete pivot to the engineering team. Enter: Whop. It’s an API payment infrastructure built specifically for the creator economy, and it handles cross-border friction beautifully. Plus, we know the team as their office is just 15 minutes away!
I spent the next few days tearing out the old plans and writing a new backend service to communicate with the Whop API. Now, the moment a brand decide to approve and pay a creator for their posts/views, our backend automatically updates the database and triggers a Whop payout to the creator. On the frontend, I wired up the React dashboard with a polling hook to listen for these changes. The creator's screen will literally update from a yellow "Pending" badge to a green "Paid" badge instantly, without them even having to refresh the page.
Feeling pretty proud of my functional Minimum Viable Product (MVP), I opened this major Pull Request and started to do a live code review alongside SideShift's CTO, Drew. He loved the Whop integration. It was better, more flexible, and more intuitive. However, he quickly pointed out a glaring flaw: I hadn't implemented any rate limiting on my API endpoints. If a user maliciously (or even accidentally) spammed the refresh button or toggled between views rapidly, it would trigger thousands of unnecessary database reads. In a NoSQL environment like Firebase, you pay per read, meaning my code theoretically could have costed the startup a fortune in server fees. To fix this, I quickly setup this system with express-rate-limit, a popular npm middleware that easily blocks incoming requests once a user exceeds a specified limit within a set timeframe. Although it was a bit humbling, the oversight that came from the excitement of the working feature gave me a fantastic lesson in thinking beyond just "making the code work" and actually "making the code production-ready."
To cap off the week, I stepped away from the code editor to begin drafting my academic Case Study (my second deliverable for this project). I structured the overall layout, outlining the general things I'll be writing about.
So now, the core engine of payments is officially built. Next week, we prepare for launch.
Week 7: Raising Dead Features and the Magic of SDKs
Welcome back to week seven! If you remember all the way back to my Week 3 blog post, I used a mathematical framework called RICE to ruthlessly cut features from our product roadmap. One of the biggest casualties of that process was the "In-App Communication Hub."
Even though creators and brands desperately wanted a place to chat without using scattered email threads, building a real-time messaging system from scratch (complete with WebSockets, message persistence, and UI rendering) was going to take a month of engineering time. For an early-stage, resource-constrained startup like SideShift, that was simply too expensive. So, I sent the chat feature to the backlog graveyard.
Or so I thought.
My core research thesis asks how startups can maintain agility when building features. This week provided the ultimate case study. Following my massive pivot to the Whop API for payments last week, I was reading through their documentation and discovered a goldmine: Whop recently released their own plug-and-play In-App Chat SDK (Software Development Kit).
Suddenly, the math changed. By leveraging their existing chat infrastructure, the "Effort" variable in my RICE calculation dropped from 4.0 weeks of custom coding to just a few days of integration work. The feature's RICE score skyrocketed, and just like that, the Communication Hub was resurrected and pulled into this week's active sprint. This is exactly what startup agility looks like in the real world: your roadmap isn't a static document, but rather a living entity that shifts the moment new technology becomes available.
I spent the first half of the week integrating the Whop React SDK directly into our new Campaign Dashboard. I wrote the logic to map the chat channels 1:1 with our Firebase campaign documents. Now, when a creator clicks on a specific project, they immediately see a secure, isolated chat room dedicated solely to that brand and that specific deliverable.
But of course, nothing works perfectly on the first try. During integration testing, I found a frustrating user-experience bug. If a creator used our new dropdown menu to update the campaign status to "COMPLETED" (triggering the escrow payment), that action didn't reflect in the chat log. A brand could be sitting in the chat waiting for an update, completely unaware the project was finished.
To fix this, I wrote a Firebase Cloud Function acting as a sort of robotic moderator. Now, whenever the database detects a status change or pending payment, it automatically injects a system message directly into the Whop chat stream (e.g., “Handles sent for approval” or "Payment of $150.00.has been transferred for your work on [CAMPAIGN]").
With the chat feature officially working alongside the earnings dashboard and status tracker, our core ecosystem is finally complete. I spent my Friday jotting all of these insights down to next week wire all of these wild technical pivots into the "Development Process" section of my academic case study. Next week, it’s time to start polishing the UI and squashing bugs as we head toward full beta testing!
Week 8: Surviving First Contact with Real Users
It’s one thing to build a feature on your own laptop where everything works perfectly; it’s entirely another to watch real people try to break it. This week, we officially entered the Alpha testing phase. Following the Lean Startup methodology, I didn’t just push my raw code to the live app. Instead, I deployed the new dashboard to a secure Vercel staging environment and invited an exclusive "Alpha Cohort": the exact same five creators and three brand marketers I interviewed way back in Week 2.
As expected, real-world usage immediately exposed edge cases my local testing completely missed. For example, a creator left the dashboard open overnight, and when they tried to send a chat message the next morning, the app silently failed because their security token had expired. I had to jump in and write a refresh hook tied to Firebase to keep their sessions alive automatically. Then came a much more terrifying bug: a brand clicked "Approve" twice in rapid succession, which briefly attempted to fire the payout webhook twice! I quickly implemented an optimistic UI update that instantly visually disables the button after one click, and paired it with an "idempotency key" in the backend payload to mathematically ensure the system can never process the same escrow release twice. Crisis averted.
Beyond squashing bugs, I noticed a fascinating behavioral trend. Because I integrated the Whop Chat SDK last week, users were spending almost all their time inside the chat window discussing video drafts. Forcing them to exit the chat just to change the campaign status in our main data table suddenly felt incredibly clunky. To fix this, I set up a rapid A/B test. I injected dynamic "Submit Deliverable" and "Approve Content" buttons directly into the header of the chat interface. The data spoke for itself: brands approved content 40% faster when the button was hovering right above the video link they were actively discussing. I happily added that UI pivot into the main branch.
The absolute highlight of my week, however, was sitting down on Thursday with a current Stanford student who represents a rare "super user" on SideShift. He actually films UGC as a creator and sources it as a brand marketer for his own consumer apps. Because my entire research thesis hinges on balancing the competing demands of multi-sided marketplaces, getting him to click through the staging app was pure gold. He deeply validated the unified system, noting that having chat rooms locked to specific campaign IDs saved him from digging through chaotic iMessage threads. Crucially, he also pointed out a blind spot: while the Whop API handles the actual money transfers flawlessly, brands desperately need a button to export clean PDF invoices for their accounting. I immediately logged that into our backlog as a high-priority post-launch feature.
The bugs are squashed, the UI is faster, and the dashboard is stable. Next week, we take the training wheels off. It’s time for the full production launch!
Week 9: Launch Day, Panic Fixes, and Zero Support Tickets
There is no feeling quite like launch day in a fast-paced startup. But before I could officially merge my code and ship this massive feature to SideShift’s users, I had to execute one last 24-hour engineering sprint. If you recall my conversation with the "super user" at Stanford last week, he pointed out that brands desperately needed exportable PDF receipts for their bookkeeping once a payout was processed. Instead of wasting time building a complex backend rendering engine from scratch, I pulled in a frontend library called "jspdf". It allowed me to automatically format and generate clean, downloadable receipts directly from the campaign data already loaded in the user's browser. It was a quick "fast-follow" feature, but it was the final puzzle piece the marketplace needed.
On Tuesday morning, I took a deep breath, merged the feature branch into our main repository, and watched the Vercel CI/CD pipeline push the code live to production. And, because this is the real world of software engineering, something immediately broke.
Almost right away, a power user with a massive roster of active campaigns logged in, and their dashboard simply refused to load. My stomach completely dropped. I dove into the Firebase error trackers and immediately realized my mistake: while testing locally, I had created a specific database rule to sort documents, but I had completely forgotten to deploy the required Firestore Composite Index to the live production environment. I scrambled into the Firebase console, built the index manually, and within five agonizing minutes, the data populated and the dashboard was working perfectly. That was a long five minutes.
With the system finally stable, I spent the rest of the week answering the core question driving my entire research thesis: did any of this actually solve the problem? I built out analytics dashboards to track our new user funnels, and the quantitative data absolutely blew my mind. Back in Week 2, our baseline metrics showed that 81% of creators were wasting over three hours a week updating Notion boards and tracking down rogue payments. Post-launch, the average creator session length on the new Earnings Dashboard is exactly 42 seconds. They log in, instantly see their yellow "Processing" or green "Paid" pill, and log out with total peace of mind.
The impact on the brand side was just as dramatic. Remember that A/B test I ran last week where I moved the "Approve" button directly into the Whop Chat window? That single UI tweak dropped the average time brands take to approve content from several days down to just 14 hours. But the absolute best metric of the week? Support tickets. Before this launch, SideShift leadership was fielding about 14 frantic messages a week from users asking if content was approved or if money was sent. In the four days since we deployed, payout-related support messages dropped to zero. The automated UI statuses and Whop webhook integrations completely cannibalized the need for manual support.
To cap it all off, I deployed a lightweight survey in the app asking users to rate the new system. We scored a 4.8 out of 5.0, and one creator left a comment that made all the late nights entirely worth it: "The new messaging system is incredible! Everything is in one place and the money hits instantly when they click approve. Finally. Props to the team"
The software is live, and the data proves it works. Next week, I just have to compile all these graphs into my final academic case study and prepare for my presentation at the Senior Project Symposium. See you at the finish line!
Week 10: Zero Support Tickets, the Final Case Study, and the Finish Line
Ten weeks ago, I set out to answer a question that plagues almost every early-stage startup: How do you translate a mountain of noisy user feedback into actual, shipped product features when you barely have enough engineering resources to keep the lights on?
Welcome to the final entry of my senior project blog. This week, the coding officially stopped, and the data synthesis began. It was time to look at the analytics, format the academic case study, and see if the Creator Management System I shipped at SideShift actually solved the problem.
The Results
In product engineering, your code is only as good as the metrics it moves. I pulled the final PostHog analytics and Firebase data to compare our Week 2 baselines against our post-launch reality. The results absolutely blew my mind:
- Administrative Burden: Down from a self-reported 3+ hours a week to a measured average session length of just 42 seconds. Creators log in, see their money is processing, and log out.
- Approval Velocity: By embedding the "Approve" button directly inside the Whop Chat UI, the average time it takes a brand to approve content plummeted from 3.2 days to just 14 hours.
- User Satisfaction: We captured a 4.8/5.0 CSAT score from our active users.
- Support Ticket Volume: This is my favorite metric. In the two weeks post-launch, manual support tickets asking "Has this been paid yet?" dropped from an average of 14 per week to zero. We completely automated the anxiety out of the workflow.
The Replicable Framework
Because this, at its core, is a research project, my final deliverable had to be something other startups could actually use. Drawing from my successes (and my stressful pivots, like killing the Kanban board and scrapping Stripe for Whop), I finalized my academic Case Study document.
Within the paper, I formalized the Feedback-to-Feature Acceleration Model. It’s a blueprint for resource-constrained teams that includes:
1. Categorical Discovery: Using strict multiple-choice surveys to prevent qualitative data sprawl.
2. Dynamic RICE Prioritization: Using objective math to rank features, but keeping the "Effort" variable highly flexible if you discover a third-party SDK (like we did with Whop Chat).
3. Tech-Debt Auditing: Identifying infrastructure roadblocks before designing the UI.
4. Context-Embedded Actions: Placing state-change buttons exactly where the conversation happens.
5. The "Fast-Follow" Loop: Leaving a 10% engineering buffer post-launch to build quick, high-value tools requested by power users (like our PDF Invoice generator).
Preparing for the Symposium
For the upcoming Senior Project Symposium, I initially wanted to do a live coding demonstration. But as any developer knows, relying on live third-party APIs on a school Wi-Fi network is a recipe for disaster. Instead, I spent a day recording and editing a demo video showcasing all the features in the final software.
It has been an incredibly challenging, intense, and rewarding ten weeks. I’ve learned that the gap between academic theory (like the Lean Startup methodology) and actual startup practice is much narrower than people think; you just need the discipline to apply it.
A massive thank you to my internal advisor Mr. Daniel Ong, my external advisor Drew Levin, and the entire team at SideShift for their support in granting me access to the data and insights I needed to see this project through.
If you want to see the final app in action and read the full case study, come see my presentation at the Senior Project Symposium!