This content is incomplete and may be inaccurate, feel free to look around & please check back later for updates.

This is the stage which is very well known in the industry, and most often associated with tech founders. How to turn a fantastic world-changing tool or technology in to a useable application. It’s where great technologies and ideas unravel. Where groundbreaking concepts remain undiscovered. Where money ultimately runs dry and a problem that you were sure existed remains unsolved. There’s a few reasons behind this, often combined with one another:

  • You feel your tool or technology isn’t perfect or shiny enough for the potential customer, or the potential customer might (in your mind) ask for something slightly different. So you keep building it until the potential customer has absolutely no reason to say no.
  • What if someone steals my idea and takes it away from me. I must keep it entirely under wraps until it has a fighting chance at beating all the (non-existant) competitors.
  • If it’s so difficult to make, everyone else will have the same trouble and take the same amount of time.
  • We have some overlap with company XYZ, what if they come after us?

These roadblocks are all very common, and it wouldn’t be incorrect to say those thoughts were present before launching the Mediafai platform. However the important part was to get it out there, get it so at least a demo could be shown or a customer could be onboarded with assistance, and to make sure users couldn’t cause too much trouble in it.

The highlighted parts are key – it’s not a full platform that can be launched and forgotten about, it needs to be just enough of a shell to allow a potential customer to see the value in it, and therefore validate the idea. This is most commonly referred to as the MVP (Minimum Viable Product), or pre-MVP.

The “Minimum” in MVP

There was already an interface for mediafai in order to easily create the example videos & prove the technology. This would need to be segmented off so the average user couldn’t get in to where they shouldn’t, and complete enough for a few reasons:

  • Allow walk throughs and show screenshots or screen captures of the product for marketing.
  • Sustain customers who are daring enough to sign up (with assistance) and accept that it’s a beta product.
  • Support the existing client base with the features they are used to from the product that once existed in the market.

In other words we needed to be able to do what we say we can do, with a little sprinkle of that magical startup buffer.

Required features

The existing client base were global automotive brands, with dealerships as their franchisees. They made heavy use of global assets overlayed with localised details such as the franchisees name, location, and phone number. These assets could be background images and videos, overlay images, audio overlays, and predetermined text overlays. Its important that the brand can outline what could be chosen, and that a franchise could then cherry pick out of those options. There also needed to be oversight to see what was being used and how often. This gave us our minimum feature set:

  • Logins with permissions, and the ability for one user to belong to multiple customers (like a manager or brand in this case).
  • Automated subscription payments to reduce financial workload.
  • A quick glance dashboard to see what’s ready and when.
  • Flexible asset database with sharing permissions.
  • A dynamic form to accommodate what the brand sets, that can adjust based on what the client or franchise chooses.
  • Responsive interface for rapid demos in person.
  • Analytics to show how the assets and media are being used.
  • And the main problem we’re solving – automatic fetching of assets from a pre-existing landing page.

Subscriptions

Video generation and capture

scraping

solving months