AI DOERS
Book a Call
← All insightsAI Excellence

How a Non-Coder Rebuilt a $1.275 Billion App in 30 Minutes

Using Claude Opus 4.5 as a coding agent, a self-described vibe coder cloned only the Frame.io features his team uses daily, fixed bugs by describing them in plain words, then shipped the result to a password-protected live URL in about half an hour. Here is how I would apply the same playbook to your software bills.

How a Non-Coder Rebuilt a $1.275 Billion App in 30 Minutes
Illustration: AI DOERS Studio

Adobe acquired Frame.io in 2021 for $1.275 billion. A non-coder rebuilt the parts of it that his team actually uses in roughly thirty minutes using Claude Opus 4.5 as a coding agent. That gap between the acquisition price and the rebuild time tells you something important about the structure of modern SaaS, and about the leverage that AI coding agents now hand to small businesses that are willing to think carefully about which tools they actually need.

Frame.io is a video review platform. Clients watch a rough cut, click a point on the timeline, leave a comment tied to that exact timestamp, and the editor sees the comment attached to the specific frame it refers to. It is genuinely useful, and in a production environment where multiple stakeholders are reviewing video simultaneously, it solves a real coordination problem. It also costs money per seat, it includes dozens of features that most small teams never touch, and when Adobe owns the product, the roadmap reflects Adobe's priorities rather than yours.

The business case for cloning tools like this is straightforward. You are not paying for a product. You are paying for access to ten or twenty features, most of which you use daily, sitting inside a platform that contains a hundred features you will never open. The seat fee does not scale with the features you use. It scales with the headcount on your team. A six-person creative team paying per seat for a platform where they use five features is a team that is renting a warehouse to store five items. The same logic applies to any SaaS tool in your CRM and website stack: the per-seat model almost never maps cleanly to the value each seat extracts.

Cloning the features you actually use removes the recurring bill. The internal clone is not as polished as the original, and it will never have the enterprise integrations or the vendor support structure. But for internal use, polished is often the wrong goal. Functional, fast, and owned is the right goal.

Here is how to apply this playbook to your own SaaS stack.

Audit the SaaS tools you pay for against the features you actually touch

The first step is not building anything. It is spending twenty minutes with a spreadsheet. List every SaaS tool your team pays for. Next to each one, write the three to five things you actually do inside it every week. Be honest. If you have not opened the analytics tab in four months, analytics is not a feature you use. If the only thing you do in the project management tool is update task status and leave comments, then status updates and comments are the two features you need.

The gap between what you pay for and what you use is where the leverage is. Frame.io has timeline comments, version management, approval workflows, team permissions, integrations with Premiere Pro and After Effects, storage management, client portals, custom branding, analytics, and more. The team in the example used maybe six of those features. Timeline comments, video upload, playback, version comparison, download, and a link to share with clients. That is the thing you clone. Not the platform. The six features.

When you do this audit honestly across your full software stack, you will usually find two or three tools where the ratio is extreme: you are using less than twenty percent of the platform's features and paying for one hundred percent of its seat cost. Those are your targets.

How it works (short)

Write one tight spec and tell the agent to research the original product

Once you know which features you are cloning, the spec prompt is the most important thing you write. It does not need to be long. It needs to be precise. Name the product you are cloning. List only the features you need. Specify the technology you want (the Frame.io clone used a single HTML file with embedded JavaScript for maximum simplicity and zero infrastructure). Tell the agent to search the internet for context on the original product before building.

That last instruction matters more than it sounds. When you tell Claude Opus 4.5 to search for context on Frame.io before building, it pulls in the actual interface patterns, the terminology users expect, the flow that people who have used Frame.io are already trained on. You are not asking the agent to invent a video review tool. You are asking it to build a functional replica of a specific interface that your team already knows how to use. The onboarding cost for your internal clone is essentially zero because the mental model is already installed.

A tight spec might look like this: "Build a video review tool as a single HTML file. Features needed: upload a video file from disk, play it back in the browser, click any point on the timeline to leave a timestamped comment, see all comments listed in order with their timestamps, download this breakdown, copy a shareable link for the current project. Search the internet for context on Frame.io's interface before you start. No backend, no database, no login system, all state in memory during the session."

That prompt, with the research instruction, should produce a working first draft in roughly eight minutes. Not a finished product. A working first draft that you can click through and break.

Per-seat SaaS seats you stop paying for (illustrative)

Fix every bug in plain English, not code

The first draft will have bugs. Every first draft does. The workflow that made this rebuild fast was fixing every bug by describing it in plain English to the agent, not by touching the code yourself.

When the upload button asked for a URL instead of a local file, the fix was: "The upload button is asking for a URL. I want to upload a file from my computer. Fix that." When downloading opened a new browser tab instead of saving the file, the fix was: "Downloading opens a new tab instead of saving the file. I want it to save directly to my downloads folder." When a comment popup appeared in the wrong position relative to this breakdown, the fix was: "The comment popup appears in the top left corner of the page instead of near the timeline. Position it close to where I clicked on the timeline." When vertical videos appeared cramped because the player assumed a horizontal aspect ratio, the fix was: "Vertical videos look squished. Make the player adjust its aspect ratio automatically based on this breakdown's actual dimensions."

Four plain-English bug reports. Four fixes. Each one took less than ninety seconds to write and less than two minutes for the agent to implement. If you have ever spent an afternoon debugging CSS layout issues, you understand what that multiplier means.

The rule is: if you can describe the bug clearly enough that another human would understand what you are seeing, you can fix it through the agent. You do not need to know which file to edit or which function to change. You need to describe the symptom accurately. The agent finds the cause.

Add features the vendor never planned and never will

This is the step that separates an internal clone from a simple cost-cutting exercise. Once you have a working replica of the features you use, you can add features the original vendor has no incentive to build, because the vendor is building for the median user in their largest market segment, not for your specific workflow.

The Frame.io clone added a feature that the original product does not have: a SerpApi integration that lets editors drop reference images directly into their comments. When a client wants a color grade to match a specific aesthetic, or a director wants a shot composition to reference a particular still, they can paste a search query and the result populates as a visual reference inside the comment thread. Frame.io cannot add this feature easily because it would require negotiating image licensing at scale across their entire user base. An internal clone can add it in an afternoon because the only users are the people on your team.

Think about what your specific workflow needs that no vendor currently ships. A real estate brokerage using video for property walkthroughs might want a feature that automatically generates timestamps for specific rooms mentioned in the description, so reviewers can jump directly to "the kitchen" or "the master bedroom" without scrubbing. A marketing team producing video assets for Facebook and Instagram ad campaigns might want automated sentiment tagging on client feedback comments, so the editor sees at a glance whether the feedback is directional approval or a hard revision request. These are features that make sense for specific workflows and would never be prioritized by a general-purpose video review platform. They are exactly the features you can add to an internal clone. An agency running SEO and organic search content reviews might add a built-in keyword density checker so editors can verify on-page optimization without opening a separate tool.

Deploy behind a password, share individual projects by link

Internal tools do not need to be on the public internet. They need to be accessible to your team and your clients, and nothing else. Deploy the clone behind a password, share the URL with your internal team, and generate individual project links for client reviews.

The password protection step is simple: add a basic authentication layer before anyone can access the tool. The agent can implement this in minutes. The link-sharing step is equally simple: each project gets a unique URL that includes the project identifier in the query string, so you can share a link to a specific video review session without giving the client access to everything else in the system.

The deployment itself can be as lightweight as you want. A single HTML file with no backend can be hosted on any static file host for effectively zero monthly cost. No servers to manage, no databases to back up, no vendor to call when something goes wrong. You own the file. If you want to move it, you move the file. If you want to add a feature, you describe the feature to the agent.

A real estate brokerage reviewing walkthrough videos with ten agents would pay per seat for Frame.io at a cost that compounds every time the team grows. The internal clone has no seat fees because there are no seats. The initial build took thirty minutes. Each feature addition takes an afternoon. The ongoing cost is the static hosting bill, which for a single-file tool is measured in cents per month.

The broader lesson is not that you should clone every tool you use. Many SaaS products are worth every dollar you pay for them, because the value is in the vendor's infrastructure, their integrations, their security compliance, or their data at scale. You should clone the tools where the value you receive is almost entirely in the interface and the specific workflow the interface enables, and where the per-seat fee scales faster than your usage justifies. Those tools are more common than you think, they are discoverable through an honest feature audit, and they are now reproducible in a single afternoon by someone who has never written a line of code.

One thing I have noticed when people first try this approach is that they tend to underestimate how much of the value in their current SaaS tools comes from the data those tools have accumulated over time, rather than from the interface itself. Your Frame.io clone will not have a history of comments from previous projects on day one. Your internal CRM clone will not have four years of contact records on the first deploy. The clone solves the interface problem. Moving historical data requires a one-time export and import that is almost always worth doing, but it is a step that needs to happen separately. Plan for it before you cancel the old subscription.

The broader implication for businesses that adopt this pattern consistently is that their software stack starts to look very different from their competitors' after a few years. Instead of paying monthly fees to a growing list of vendors, each of which has its own pricing changes and deprecation decisions and support quality, they have a collection of internal tools that are owned outright, deeply customized to their actual workflow, and improvable on demand. The competitive moat in software is shifting from access to capability. Owned tools, extended over time by AI agents, compound in a way that rented tools never can.

The $1.275 billion acquisition price tells you what the platform was worth to Adobe at enterprise scale with enterprise integrations and enterprise support. It does not tell you what the five features you use are worth to your team. Those five features are worth thirty minutes and a description prompt, and they are now yours to extend however you need.

Do it with an expert
You can build this yourself, or have it set up right the first time.

That is exactly what we do at AI DOERS. Book a private 30-minute call with Madhuranjan Kumar and we will map the fastest path to it for your specific business.

Book your call →
Madhuranjan Kumar

Madhuranjan Kumar

Founder, AI DOERS · Performance Marketing

Madhuranjan Kumar brings 20 years of performance-marketing experience and has managed over $200 million in Facebook ad spend for brands across the United States and beyond. His expertise spans the full modern marketing stack: Meta, Google Ads, TikTok, email automation, CRM, and the websites that hold it together. At AI DOERS he turns that track record into lead-generation systems for businesses across every industry.

← Back to all insights
How a Non-Coder Rebuilt a $1.275 Billion App in 30 Minutes | AI Doers