Why Swarajya Went Open Source

While we've always had a good experience with all our technology service providers (thanks, Quintype!) we realized we need a different style of operation to scale subscriptions.

We wanted to be able iterate through ideas and designs very quickly, deploy customer data platforms and sharpen our subscriptions stack.

The broad requirements for daily Swarajya operations stood as below

- A Content Management System and a Back-end to serve the content

- A Web App and a Cross Platform App for mobiles

- Subscriptions Management and Email Marketing Tool

- A way to send large volumes of emails at affordable prices without damaging our domain's reputation

- A customer data platform that didn't break the bank

Cross Platform Mobile App

We began our transition by first working on the peripheral apps - we ended up building the cross platform Flutter app rather quickly and rolled it out with all the customizations we wanted.

These include subscriptions messaging, paywall customisation, CDP integration, messaging and more. We've now bookmarks, podcasts and quiz featured built as well.

Each of these were taken up and turned around within a couple of weeks - allowing us to try new variants and settle on what worked for us. The app now has a 4.5/5 rating on the Google Play store.

Subscriptions Management

We chose to use Strapi CMS, although technically we could have simply used a NodeJS backend. But Strapi came with several out of box features such as content editing/ability for users to verify data, API end points and other things.

We did have to customise Strapi for cron jobs and other functionalities but overall using Strapi helped save quite a bit of time in development.

CMS Lite + Front End

Our previous design for the web app was ageing quite a bit. We wanted to bring some fresh air but without compromising on the one key aspect: we could not afford a clutter, clunky website - it needed to have a clean look and feel.

There aren't many news/news content related websites that are as uncluttered and clean as ours - while we do realise the value of our real estate we'd rather ensure a cleaner experience for our readers and subscribers.

From an architectural standpoint we had the following mandates

• Have a CMS lite that will retain a copy of all content and serve it forward to the front end (We continue with our old CMS)

• Scalable front-end app - with content cached and served mostly from the front-end and not rely on cached backend adding to latency.

• Scale without being expensive on monthly cloud bills.

Our solution lay, once again, in using Strapi CMS to receive incoming webhooks from the CMS. The Strapi instance then caches the particular endpoints on redis and also pings the front-end to invalidate stale cache there.

For the front-end after much studies, we decided to adopt NextJS - the ability to handle Incremental static regeneration (ISR) was a key win for us. We've set up a simple Kubernetes cluster with every pod managing its own cache.

We did face some issues with containerizing and deploying the NextJS app on a Kubernetes set up (a stand-gap arrangement of hosting on Vercel did damage the bank severely) but once we were over the curve it all settled in quite nicely.

Email

We quite literally send millions of emails every month. It would ruin us if we were to pay popular email marketing platforms to do this for us. We've set up the required stack to run our own email servers - costs are there but within acceptable limited and we're keen to help anyone looking to do this for themselves.

Customer Data Platform

While several premium grade CDPs exist with complicated pricing structures we opted for Tracardi - open source variant that has been able to do the job for us. Over 100k events from our website and apps are captured triggering about a dozen workflows on follow up emails, WhatsApp messaging, profile updations and so on. Thank you Tracardi!

In every stack component - CMS, CDP, Email and so on the subsequent performance we've seen in production and concomitant costs saved have been enormous and very welcome within the company.

While the requirements of every publisher is different and in most cases requires outside help - tech vendors are great because they take care of our headache, it is perhaps time for media companies to also tinker with their stacks a little to see how far we could go on open source.

It does take a non-trivial amount of time and effort to get things right with open source, this is likely where most of us need help. We're open to supporting publishers looking to do this.

Lastly, while we have benefited enormously from open source we haven't 'given back' enough yet. We plan on devoting significant time next year to contribute meaningfully (in code and money) to the open source movement.

Swarajya is happy to assist publishers and others looking to build a better, open source tech stack. Please write to tech@swarajyamag.com