Raised paid subscribers 20% while running a 500K-user media platform for 4.5 years
I built and ran a regional digital subscription platform for 4.5 years, raising paid subscribers 20%, crossing 500,000 monthly users, and keeping uptime at 99.9%.
Client: A regional digital subscription media platform
Timeline: February 2017-September 2021, roughly 4.5 years
Stack: PHP, MySQL, Nginx, Redis
Challenge
A competitor had already launched, and every week without a product was a week the competitor’s subscriber base compounded. The founders had business connections and a closing market window. They did not have a product, a codebase, or anyone technical, and the brief was two sentences: be in the market, be better. Better than something already live, already taking money, already winning.
The temptation was to copy. Match the competitor feature-for-feature, ship fast, fight for parity later. That is the path most pre-launch engineering takes when the market is racing. It is also the path that produces a v1 nobody can operate by year 2.
Approach
I refused to start with production code. For weeks, I studied the competitor’s product, mapped where their reader experience broke under load, and made “better” measurable before anything got architected. The founders wanted to ship. I wanted to know what shipping meant, because a brief like “be better” produces a different system depending on what you measure.
Three things came first: subscription and billing, the reading experience, and the load profile. Nothing else. No custom CMS. No sprawling admin dashboard. No analytics layer before the money and reading loops worked. The competitor had more features; I had three things that worked under load and a subscription flow that did not break. That decision paid for itself across the next four years. Every feature request afterward got measured against those three things first. The system stayed operable instead of becoming the thing everyone was scared to touch.
Outcome
Paid subscribers rose 20% within 12 months of the platform launching. Monthly users crossed 500,000 on a platform that had not existed a year earlier. Uptime sat at 99.9% across 4.5 years. Mean time to resolution dropped 45% as monitoring and alerting matured.
The pattern: the founders kept me. Not for a project, for the operating layer of the company. Over those 4.5 years, the work I was trusted with deepened: setting the technical roadmap, hiring developers onto the team, and making architecture calls across new product lines. Work that started as “build the platform” became “be the technical judgment layer the company didn’t have.” The platform was still running on the architecture I had refused to rush.
Quote
“If you’re looking for a standard developer, this isn’t it. If you’re looking for someone who takes responsibility, solves hard problems, and thinks long-term, definitely work with him.”
— Founder, after 4.5 years of working together
Lesson
Every architectural decision I make now has to pass one test: would year-4 me thank year-1 me? I spent 4.5 years inheriting my own decisions, watching which ones aged well and which ones I quietly rewrote at 2am. Most freelancers never get that feedback loop. It is why I default to boring and operable on someone else’s product, especially when the brief is “ship fast.” Fast is cheap. Operable in year 3 is what founders actually pay for, even when they do not know it yet.