StudyVent: Student Research Marketplace
StudyVent connected students who needed a paper with students who already had one. Anyone could upload a thesis or term paper; StudyVent moderated it, cut it into a gated preview, and paid the uploader back in free access days instead of cash. Readers who didn’t want to upload anything could subscribe or buy single documents outright. CimpleO took over active development on the platform, running monthly milestones across the reading experience, the payment models, and the site’s search visibility.

The Challenge
StudyVent had already launched with a live, paying user base, so every change had to ship without breaking a subscription or a payment mid-flight. The business model itself moved during the engagement: it started as a free-preview-then-paywall structure and shifted toward a pay-per-document option the client wanted to test, which meant rebuilding the paywall UI and the plan logic behind it without disrupting subscribers already on the old plan.
The upload side had its own problem. A document-sharing marketplace lives or dies on trust: a reader has to believe the gated preview is really gating something, and an uploader has to believe the reward is worth the upload. Getting that balance wrong either lets people read for free or kills the incentive to contribute new documents.
On the SEO side, the site was invisible in search for reasons a features team rarely touches: broken hreflang tags, an unreliable sitemap, and canonical tags pointing at the wrong pages. Fixing search visibility meant fixing the plumbing search engines depend on, not writing more content.
What We Built
Server-side PDF gating
The paywall isn’t a UI overlay a reader could bypass by inspecting the page. Every uploaded PDF goes through a Symfony service (built on FPDI/TCPDF) that generates two derivative files server-side: a restricted preview that processes only the first half of the document’s pages and swaps every third one of those for a stamped “this page is not available in the preview” placeholder, and a watermarked full copy with StudyVent’s logo stamped on every page for paying access. The original file never gets served directly to a browser.
Upload-for-access moderation pipeline
A Symfony Workflow state machine drives every uploaded document through pending, declined, published, and unpublished states. An admin’s own uploads auto-approve; anyone else’s queue for review and trigger an email notification to the admin. Approving a document dispatches async jobs (via Symfony Messenger) to generate the restricted and watermarked variants and a thumbnail, and grants the uploader a premium-access window: 3, 7, 21, or 50 days depending on the document type (essay through master’s thesis), emailing them the exact number of days they earned. Decline emails go out the same way, so an uploader always hears back either way.

Custom PDF viewer
The viewer plugin StudyVent launched with silently failed to render some documents. CimpleO replaced it with a custom Angular component wrapping pdf.js directly (via ng2-pdf-viewer), with its own loading state, scroll behavior, and page-visibility rules tuned to work with the server-generated restricted PDFs rather than fighting them.
Free-tier metering
Anonymous, logged-out visitors get a limited number of free document views before hitting the paywall, tracked server-side by IP address rather than a client-side cookie a visitor could just clear: each IP gets its own counter row, checked and incremented on every view. Logged-in free accounts get the same allowance tracked per user instead of per IP, so switching networks doesn’t reset it.

The gate is real, not cosmetic: with access, the same document opens straight into the text, no modal in the way.

Subscriptions and pay-per-document
Recurring subscriptions run on PayPal’s Billing Plans and Subscriptions APIs. A webhook endpoint handles eight subscription lifecycle events (created, activated, re-activated, updated, expired, cancelled, suspended, payment failed) plus completed one-off sales, but only after checking that every required PayPal signature header is present and the event validates against PayPal’s own verification endpoint; anything short of that gets logged and rejected with a 401 rather than trusted. Even a validated event gets cross-checked again: the handler pulls the subscription and sale by ID from PayPal’s live API and confirms they reference the same billing agreement before touching a user’s access, and if the corresponding subscription record hasn’t landed in the database yet, it throws a recoverable exception so Messenger retries instead of dropping the event.
Mid-engagement, the client asked for a pay-per-document option as an alternative to the recurring plan: a separate purchase flow that unlocks one document without committing to a subscription, tested end-to-end against PayPal’s sandbox before going live alongside the existing plans. A user’s own dashboard shows subscription and purchase history so a support question doesn’t need a database lookup to answer.
Search and recommendations
Search matches against title, abstract, tags, and the uploader’s name in one query, then a custom relevance sort pushes title matches above tag or abstract matches, so a search for “marketing” surfaces a thesis titled around marketing before one that merely mentions it in passing. Each document page shows the most-viewed documents from the same category, and logged-in readers get a capped list of their own recently viewed documents, trimmed automatically once it passes the limit.

SEO and infrastructure
Hreflang and canonical tags corrected across the site, noindex applied to pages that had no business in search results, and the Swagger API documentation pulled out of public reach. The sitemap generator ran fine in staging and broke in production; the fix shipped alongside a monitoring check so a silent sitemap outage wouldn’t happen twice. The staging environment moved onto the client’s own AWS account, then onto a fresh EC2 instance once the original one needed replacing, so the client owned the infrastructure StudyVent ran on rather than a contractor’s personal server.
Platform
Angular 11 workspace split into three projects, client, admin, and a shared base library, so the reader-facing app and the moderation panel share components without duplicating them. The API is Symfony with API Platform (DataPersister/DataProvider/DataTransformer classes throughout, not raw CRUD controllers), documents live in AWS S3 behind an interface that also supported local disk storage for development, and Redis backs session and caching needs.
Delivery
Work ran in monthly milestones from August through December 2021, each one scoped around a specific product or SEO goal rather than a fixed backlog. The pay-per-document pivot landed mid-engagement without touching subscribers already on the recurring plan, and the infrastructure moved fully onto the client’s own AWS account before the engagement wrapped.