I was brought in to a very small digital agency, as a client had just signed a contract to come on board and they needed a full-time senior engineer to replace a contracting senior engineer. With a small team of 5 including a founder with a big vision, I spent a fair bit of time at the start learning, absorbing, and seeing what’s what to work out how to improve this business by building the beneficial traits & reducing/hiding the concerns. On to the table:
| Beneficial | Concerning |
|---|---|
| 6+ months of internal tech department communication history Years of multiple prototype history Long company existance Initial functional MVP Decent client brand history, new big client signed on Direct links / Integrations with Google Public press releases from the founder on their vision | Incohesive codebase Minimal / no infrastructure Very top-down culture, overly corporate for the size Negative trends on glassdoor Cost-cutting hugely apparent Unorganised / difficult to get anything to happen Misaligned / negative / incorrect communication trends |
Technical Debt
I think it’s important to dig in to the incohesive codebase as listed above as it’s a huge tell to what the company is like internally. What this indicates is that a number of different developers had worked on it over time, with no overarching guidance. It ends up being a patchwork of different directions and coding styles which while functional means it’s much more time consuming and difficult to add/modify/patch the code as time goes on. This is what is commonly referred to as technical debt and also what the recent vibe coding trend is bringing closer to the surface. For a codebase to succeed well, it needs a person who is across it all and understands it all. This can be applied to anything outside of a codebase also which will become apparent further down in this case study.
Early stage / Existing MVP
This stage was invaluable to study and work out how to enhance the business and overcome the concerning traits. The company was a small digital agency, that provided “automated” advertising campaign creation across franchises. The prior MVP’s showed a clear path of what this business was trying to achieve product-wise, where it was struggling, the sales strategies used & timeframes, and where it was wanting to get to. The latest MVP (currently in use) was a mostly automated product, tailored to a single company – basically a dedicated software development tailored towards a single client.
The communication history and over-corporateness showed a culture of mis-trust from somewhere, either caused by or causing an imbalance where the people in power/management/leadership took their titles too literally.
Around the time COVID was starting to hit globally, we were told to prepare for a huge influx of customers within months – 4000 of them from a single offshore brand, along with another 1000 or so from a different industry, and a partnership that promised 30,000 individual customers through a third party. The existing MVP was not capable of delivering on this – it was struggling to hold together for 10 customers. It took 10+ minutes to make the videos for just one customer, and that was if no other customer was online at the time. So this was the catalyst to build what would make this company scalable and sustainable using the strengths of the staff, and attempting to hide/neutralise the weaknesses from the new customers.
How to grow
The business had a problem – it wasn’t overly unique, and very maintenance-heavy / non-scalable. It didn’t have the point of difference above an agency or a templated video generator. It had too many overheads and could be wiped out overnight by someone who just wanted to provide the man hours a little cheaper. But the founder had a knack of connecting with big global brands and known people in the industry. So to support the founder’s vision and goal of servicing a potential 35,000 customers a new product was needed to counter that – supporting rapid scaling, providing a few unique features to hook customers, and using the strengths of the existing staff as there was no time to get more (but they would be urgently needed soon). Here’s what our tiny two -member IT team decided to build:
| Modular | The platform would be split into logical components, each a product in itself. This allows for multiple individuals or teams to work individually on each product without interfering or (merge) conflicting with the others. All API’s would sit in an API product, all videos would be rendered with a video product, communication to and from services such as Google and Facebook would be handled with an IO product, and so on. This has numerous other benefits so I might break this out in to a dedicated explainer or article later. |
| Shared | A hidden product would house shared components and libraries allowing for rapid development across all modules/products through re-use, while also providing a cohesive feel to the entire platform of products. |
| CI/CD | There would be a dedicated development->testing->demo->staging->production chain, to force the non-technical staff to view the platform while catching any bugs on the way through, saving on testing overheads while doubling as a much needed demo platform. |
| Unified Systems | Each underlying system would be loaded in the same way, with the same libraries, with common proven technologies & languages to keep everything consistent and simplified – allowing for rapid scale while keeping costs extremely low. |
| Globalisation | The entire system would have globalisation baked in, as the influx of customers about to be onboarded used multiple languages, currencies, timezones, and data laws. |
| Easy & Flexible UI | The ordering system for the customers in the original MVP was a massive code nightmare – we needed to avoid this by splitting it in to logical steps, using methods that severely reduced development time and technical debt. |
| No AJAX | The UI was to use a standard LAMP stack so everyone could understand it, nothing was hidden, and page loads are baked in meaning no need to keep track of statuses or triggers for refreshes of components. It also removes a layer as no dedicated interface API’s are required. |
| Recurring Tree Structure | Brands could set up their assets, and customers could belong to many brands, with customers also belonging to other customers. The best part was each branch or node on the tree work identically, so complex businesses can be created with very minimal upfront development, also minimising training for staff and customers. |
| Simple Customer Onboarding | This was a tie-in to the existing sales strategy discovered from the years of MVP’s. The sales strategy was to develop a working prototype before visiting the customer, to show the customer it’s already there and done so no complicated onboarding in theory. So a customer (demo) needed to be easy to create on the system rapidly. |
| No-Code | Remove the man-hours and incredibly high costs of custom work, by making the entire process a customer requires doable from within a web based interface without ongoing technical help or development. If a developer is required to do something, then that needs to be accessible within the UI by non-developers. |
As it’s a small team, this was the only way forward to making the business scaleable, profitable, and unique while avoiding the concerns from being visible, and avoiding total collapse. Without this, the impending mountain of customers couldn’t sign on profitably. It all boiled down to one technical proof of concept before it could begin:
Is it possible to generate a scalable brand-compliant video, with no pre-editing required, including animated dynamic layers, easily and quickly from the web UI without any developer input or After Effects – in under 10 minutes – for more than one customer simultaneously?
With 35,000 customers all around the world creating videos, the existing mvp could only handle 144 videos per day even IF customers all waited their turn.
a total of If we can’t do that, then the new platform (and company) is at risk, with the fallback being to maintain the existing MVP and just scale the man-hours per customer. Not a true scaleup, so this needs to be proven first.
The key piece – Automated & rapid layered video generation
The key component to the platform and the business was automated video generation, with the customers details and chosen options rendered in. Each time an adjustment was needed, a new base video needed to be created, new command line, and a lot of testing. This would take a week or two and works well when there’s only one brand. In addition the way it was achieved was extremely limiting in regards to fonts, colours, placement of elements. There were no animated elements aside from simple fades. Understandably each brand has a different video style, look, colours, etc. so the existing method won’t scale.
Using my history of 3d animation I knew of a technique, which if I could get a few technologies to work together in a specific way to achieve this technique then it would allow the business to have a fully functional video generator with unlimited* layers, animations, fonts, pretty much anything you can think of – all automated, and rapid. This would be a massive cost saving measure across the board, and allow for a huge increase in onboarding efficiency.
After about a month of testing I had the eureka moment where the technique had worked. I had proven a layer based video generator could be made and therefore automated. The business was saved. It was even worthy of a photo.
This went on to become the ‘video’ module, which avoided the limits of the original MVP by being truly scalable – more instances could be added when more customers came onboard – which kept video generation to just below 10 minutes for simultaneous users.
A further rendering optimisation algorhythm was added to change the order in which layers were rendered – instead of rendering the longest duration layers first, it would choose one long, then a few short. This resulted in the average time reducing to around 6 minutes and therefore multiplying the scalability and reducing costs by 40%.
Platform, Customers, Globalised
Once the platform was developed it’s first trial was with ~800 customers, where it was proven to be the saving grace. It handled the workloads, it onboarded customers quickly and cost effectively.
It allowed for the rapid onboarding of customers across Australia, Asia & Europe – all translated to their languages, currencies, and timezones – a truly global platform. There were at times 80+ customers onboard simultaneously, with the servers easily handling the capacity keeping video rendering rates in the target times.
The platform allowed for the company to expand while keeping development and server costs extremely low. The planning paid off with the original two IT staff able to maintain the entire system, servers and all. With the entire cloud hosting costs of around $500 per month using clever methods.
While it never got those originally forecast 35,000 customers, we had hundreds of steady paying big brand customers and extremely low development/maintenance costs – all thanks to the platform and its architecture working perfectly, allowing the company to play to its strengths, and overcome it’s weaknesses.
Investment & Aftermath
Off the back of the platform success, the business secured decent pre-seed VC investment in order to keep the momentum going, and reach the next stage of growth. Unfortunately this was also the straw that broke the camels back. While the platform was succeeding greatly in what it was designed to achieve – and validated with the investment – the concerning traits observed in the beginning (aside from the incohesive codebase) carried through where the investment unfortunately multiplied them. The platform could no-longer cover those traits, which as a result the business suffered and the majority of staff including our IT team of two were let go or parted ways.
Retrospective
The platform was a tremendous success achieving well beyond what it was designed for. For a product to be expecting 35,000 customers within months, to be able to be developed and supported entirely by a team of two – it received so many surprised comments as I don’t think people know how easily it can be done. In addition it grew the business allowing it to support so many more staff across the world.
The issues only began as a result of a leadership team that ballooned and was unsuitable, expensive, and didn’t attempt to truly understand the platform or the customers. This resulted in them wanting to add their stamp on the platform which destroyed it from the inside. The top-down hiring was always going to happen (as seen in the concerning traits) with the surge of funds – the only way to save it would be for the founder to appoint a CEO and step aside, or for the growth to happen organically and slowly to restrict the ability to hire costly members to the leadership team. The issues ultimately came down to culture which started at the very top. I actually had a chat with the founder a while after who said…
Why can’t people do what they say they’ll do
As for what happened, the platform became too much to manage as it was no-longer cohesive, there was no individual remaining that truly understood what the company needed, so the IT costs ballooned and become unsustainable. The last I heard was that the leadership were scrambling towards a rewrite for a new patform in an unrealistic timeframe (this is a typical buying-time strategy) which couldn’t be achieved. My understanding is that either the once successful platform is no-longer used, or just a very small portion of it is used for data collection with the remaining tasks being performed manually – resulting in the company being set back 7 years to the same level as when I was brought in.
As it was a successful platform with a decent market that were about to have nothing to turn to, I used this as a basis to create a new platform which both expanded the audience & reduced the technical cost even further. This is how Mediafai was born, read about building a SaaS platform here.