RepeatPosts is a SaaS platform built and owned by OLXR. It is a live, commercial product - not a demo or a side project - conceived, designed, engineered, and taken to market without external development resource. This page describes how it was built, the decisions we made along the way, and what we learned in the process.
The Problem
Most businesses understand that consistent, on-brand social media content matters. The reality of producing it is something else entirely.
Existing design tools require a level of skill most marketing teams do not have. Even for teams that do have the skills, producing correctly sized, on-brand graphics across every platform, every week, is slow and labour-intensive. Outsourcing to a designer is expensive and hard to keep consistent - brand guidelines need to be applied across hundreds of assets, and the back-and-forth adds up quickly.
The result is predictable. Businesses either produce content inconsistently, or they produce it at a quality level that does not reflect the brand they have worked to build. Neither outcome is acceptable when social media is a primary channel for reaching customers.
The problem we set out to solve was not design - it was volume and consistency. A business should be able to produce hundreds of on-brand graphics, across every platform, without needing a designer involved in each one.
What We Built
RepeatPosts is a web application that lets businesses create social media graphics without a designer. A business sets up their brand once - their logo, colours, and fonts - and the platform applies it automatically to any template they choose. The same graphic is then exported in the correct size for every social media platform at once, rather than having to resize and adjust it manually for each one.
Beyond the core generation, the platform includes a library of templates covering 15 different industries, a drag-and-drop editor for customising designs, the ability to generate large batches of graphics from a spreadsheet, animated graphics and video output, and team features for businesses where more than one person is involved in creating or approving content.
Technical Decisions
Building RepeatPosts required solving a number of technical problems that were not straightforward. Below are the decisions we made, including the ones that did not work out as expected.
From SVG templates to browser-based rendering
We started with SVG - a standard web graphics format - as the basis for templates. For static graphics it worked well. The problem emerged when we needed to support animations: SVG animation is inconsistent across platforms and cannot be exported reliably to video. Rather than engineer workarounds, we moved the rendering approach entirely. Templates are now rendered inside a headless version of Chrome running on the server, which gives full access to CSS animations, web fonts, and the complete browser layout engine. Output is captured as an image or passed to a video encoder. The result is consistent and accurate across every format. The trade-off is that running a full browser on a server is resource-intensive, which made the job queue - already in development - a necessity rather than a nice-to-have.
We introduced a background job queue early
Generating graphics - particularly in bulk or as video - takes time. If we had processed generation requests synchronously, the user interface would freeze while each job ran. For a platform where an agency might submit hundreds of graphics at once, this was not acceptable. We introduced Hangfire - a background job processing library - early in the build. It decouples generation from the request: a user submits a job, the platform processes it in the background, and the user is notified when the output is ready. It also gave us automatic retry logic if a job fails, visibility into the job queue, and the ability to control throughput without changing the core application.
We integrated FFmpeg for video output
Animated social media content - MP4s and GIFs - requires a video encoder. FFmpeg is the standard tool for this. Integrating it into our .NET application and managing it reliably in a cloud environment took careful work. The browser renderer captures frames, which are passed to FFmpeg, which handles the encoding to the correct format, resolution, and frame rate for each platform. Because this sits inside the same background job queue as image generation, the same retry logic and monitoring applies regardless of whether the output is an image or a video.
We replaced Fabric.js with a custom-built editor
The original template editor was built on Fabric.js, a well-known open-source canvas library used widely for browser-based design tools. It is a capable library and handles standard editing tasks well, including basic animation on shapes and images. Where it fell short for RepeatPosts was in two areas: text animation - which was not well supported out of the box - and dynamic data binding, where changes to a user's brand colour, logo, or fonts need to propagate automatically across every template element that uses them. Building these reliably on top of Fabric.js's internal data model would have meant engineering around the library rather than with it. Rather than continue extending someone else's abstractions to fit our exact product requirements, we built a custom editor that treats brand-aware data binding and advanced animation as core architectural features - designed specifically for how RepeatPosts works.
Building the Template Library
Template libraries were built for multiple industry verticals - real estate, fitness, restaurants, professional services, and e-commerce. Each vertical has different social media communication patterns: the content types that matter, the visual conventions that audiences expect, and the formats that actually perform. A real estate agent needs property listing graphics, price reduction announcements, and sold notices - not the same generic quote card templates a restaurant would use.
Understanding what each sector actually needed required research into how those businesses use social media before a single template was designed. The library was built around those realities, not around what was easiest to produce.
Some content types are universal - quotes, promotions, announcements, testimonials, how-tos. Others are specific to a sector: a real estate agent needs property listings and open house notices; a fitness studio needs class schedules and transformation posts; a restaurant needs daily specials and seasonal offers. The library reflects that split. The generic foundations serve every vertical; the specifics were researched and designed per sector so that what users see when they pick their industry actually matches how businesses in that industry communicate.
Screenshots
RepeatPosts.com Demo 1/4
RepeatPosts.com Demo 2/4
RepeatPosts.com Demo 3/4
RepeatPosts.com Demo 4/4
Where the Product Stands
RepeatPosts is live. It is a fully operational multi-tenant SaaS platform with a functioning subscription model, a template library spanning multiple industries, and a custom rendering pipeline producing image and video output across 15 platform formats.
Building and launching RepeatPosts taught us things about SaaS product development that client engagements alone would not have. We made decisions under real commercial pressure, iterated based on real user behaviour, and solved problems that only emerge when a product is actually in use.
Technical Reference
Have a project in mind?
We are happy to discuss what you are building and whether we are the right fit.
Start the Conversation