Overview
An AI capability without a product around it
When I joined the project, the PhD research team had already built a powerful AI workflow: it could ingest .docx interview transcripts and produce a structured analysis report. The underlying capability was valuable — but it was not yet a usable product.
There were no user accounts, no payments, no upload flow, no report delivery, and no way for real researchers to access it independently. My role was to build everything between the AI engine and the user.
Over roughly two years, I built the web application and application backend around the AI workflow: authentication, API endpoints, database models, file handling, payments, subscriptions, usage tracking, report generation, and the user-facing analysis flow.
The Challenge
Turning a research prototype into something users could operate independently
The core challenge was not simply "build a frontend." The real challenge was to make a research tool simple enough for non-technical academics, robust enough to process real files at scale, and flexible enough to support a changing commercial model — all under tight budget constraints.
Qualitative researchers spend days reading transcripts, coding themes, and pulling out patterns. MyRA aimed to reduce that work to minutes. But that meant the product had to handle file uploads from real users, manage a long-running AI process it didn't fully control, and deliver a usable output at the end.
The project also needed to work around a backend AI workflow that already existed as a separate system — my job was to integrate with it, not redesign it.
Role
Full-stack product engineer, founding scope
I was initially brought in as a frontend developer, but the scope quickly expanded into something closer to a founding engineer position. The AI research team created the core analysis workflow. The designer owned the UI/UX direction in Figma. My responsibility was to build the application layer around that capability.
Frontend
- → Next.js / TypeScript on AWS Amplify
- → Upload, question, themes, waiting, download screens
- → Account management and pricing flows
- → Freemium / subscription-gated access
Backend / Application Layer
- → Serverless API endpoints and application logic
- → User, analysis, and subscription data models
- → File upload and report storage
- → Stripe: checkout, webhooks, customer portal
- → Email-based report delivery pipeline
- → .docx report generation from structured AI output
Product
A simple journey backed by a complex system
The main product journey was designed to feel effortless. Behind that simplicity was a connected set of systems handling authentication, permissions, storage, async processing, and report delivery.
- 01 Sign up or log in
- 02 Buy tokens, start a subscription, or use a freemium allowance
- 03 Upload transcript files
- 04 Enter a research question
- 05 Optionally define themes or select an analysis type
- 06 Submit the analysis
- 07 Receive an email when the report is complete
- 08 Download a polished .docx report through a time-limited link
Architecture
Serverless AWS, end to end
MyRA used a serverless AWS architecture. The frontend was a Next.js application connected to a set of application backend services handling auth, data, and file storage. Those services sat in front of the AI analysis pipeline, which processed uploaded transcripts and produced structured output. Report generation and delivery ran as the final step — producing a downloadable file and notifying the user by email. Stripe handled all payment and subscription flows.
Next.js frontend
↓
Application backend
(auth · data · file storage · payments)
↓
AI analysis pipeline
↓
Report generation + delivery
(downloadable .docx · email notification) Key Decisions
Three choices that shaped the product
Email-based delivery over synchronous waiting
AI analysis could not be treated like a normal instant API call. Rather than forcing users to sit in the browser during long-running processing, we redesigned the flow so users submit, close the tab, and receive a download link when their report is ready. This made the product feel reliable and matched how researchers actually work.
Supporting three payment models without rebuilding each time
The product went through pay-as-you-go tokens, monthly subscription, and freemium access tiers. Each model changed what users could do, how usage was counted, and where the source of truth lived. The challenge was not just taking a payment — it was making Stripe state affect access inside the product without breaking the existing system each time.
Shipping the core path instead of the full wishlist
Several useful features — analysis history, a chat assistant, richer report views — were intentionally cut to keep the product shippable within budget. We focused on what mattered most: upload transcripts, ask a research question, receive a polished report. That focus got the product in front of real users with real usage data.
Impact
A prototype that became a product with paying users
The product grew beyond a prototype and became a working platform. Researchers could create accounts, pay for access, upload their own material, and receive a finished report — without the team manually operating anything.
"We fly 12 people from the US to Europe twice a year to do what this just did in 2 minutes."
"Just one click to upload all my transcripts, and I got a full report in under 10 minutes. Saved me a ton of time and hassle, a real game-changer!"
"MyRA helped me meet deadlines, provided accurate insights, and made the research process feel like working with a skilled assistant than just a tool. Incredibly user-friendly!"
Reflection
Building an AI product is mostly about the systems around it
MyRA taught me that the AI model is rarely the hard part of shipping an AI product. Authentication, payments, storage, permissions, uploads, report delivery, and clear user-facing flows — those surrounding systems are what turn a capable AI workflow into something people can actually use.
It also showed me how closely monetisation and architecture are connected. Token-based pricing, subscriptions, and freemium access each created different requirements for the database, backend validation, Stripe integration, and frontend experience. Changing the pricing model meant touching almost every layer of the application.
Finally, the project reinforced that technical value, user value, and willingness to pay are related but not identical. MyRA generated real value for researchers — but finding the right price point and market access proved harder than building the product itself.