Cloning a $43K SaaS tool with AI: what 72 builders learned

A SaaS vendor quoted $43,000 per year to run the four annual AI.Engineer conferences. The tool managed speaker submissions, scoring, scheduling, speaker portals, and role assignment—work the team needed done, but the vendor came with a fixed price and no flexibility. When Latent Space filed change requests, the vendor typically took 3 to 6 months to deliver, or never shipped the improvement at all.

The team used roughly a third of the software. No discount was offered for the unused portion. This mismatch—paying for features you don't need and waiting for features you do—became the rationale for an experiment: hire outside builders to clone the tool with AI coding agents, keep the best open source, and have the actual events team evaluate it.

Latent Space's founding contract explicitly prohibited internal software without approval. The reasoning was pragmatic: avoid "not invented here syndrome" and stay focused on the core business instead of chasing distracting side projects.

But this year the host reconsidered. AI agents had finally reached a capability threshold where a small team—or even a single person—could build personalized tools faster and cheaper than licensing off-the-shelf software. The vendor's $43,000 quote made the case even sharper. Rather than debate philosophy, the team decided to put real money toward the experiment and see if the premise held.

Speaker submits a talk. Reviewers score it. A review committee accepts it. Now the speaker needs a portal to upload a headshot and slides. If they haven't completed their profile, they get reminders. Once accepted, the speaker is placed on the schedule. Organizers move speakers between time slots. Speakers change their talk title. The public agenda refreshes to reflect all changes. Co-speakers get added. The workflow repeats for sponsors and attendees, each with separate portals and permissions.

One person can hold multiple roles at once—speaker, sponsor, attendee, organizer, volunteer, vendor—and the system must handle those overlaps without breaking. Organizers sometimes invent new roles on the fly for specific situations. This complexity is invisible until you actually run an event: the logic branches and loops in ways a spec document rarely captures.

Speakers, invited speakers, and sponsors each need their own portal. Most submissions built a single portal that tried to serve all three roles. That inflexibility caused friction because each group had different upload requirements and access patterns. A speaker portal needs to show the speaker's own submissions and profile. An invited-speaker portal skips the submission step entirely. A sponsor portal is a different interface altogether. One-size-fits-all never worked.

Drag-and-drop was another pitfall. Moving a speaker from one time slot to another seems simple until you build it: the UI has to update in real time, prevent double-booking, show visual feedback, and handle edge cases like a speaker appearing in two slots. Models struggle with drag-and-drop because it requires both visual confirmation and state coordination that text-based prompting makes easy to overlook.

The third failure was the admin shortcut: adding a talk without submitting it through the CFP form. Organizers sometimes invited speakers directly—no public submission, no scoring. The system had to accept a backdoor path for these VIP entries. None of the three problems were well documented in the provided spec or session boards. You only discovered them by using the product like someone running a real event.

Fifty-six apps ran through this gauntlet. Forty had enough feature coverage to be ranked.

The top seven finalists landed within 2.3 points of each other—basically a tie. The scoring was tight enough that teams could see weak spots and iterate. Some submissions, like Lectturn and Curtain Call, used the automated eval as a hill-climbing tool: they identified gaps, fed them back to the agent, fixed the weak areas, and resubmitted. That approach worked to a point, but it had a blind spot.

Hill-climbing against the automated eval helped teams improve quickly, but it also rewarded a specific kind of behavior: building more features to pass more test scenarios. Teams duplicated features with no connection between them because they were optimizing for checklist coverage, not usability. A headshot upload might save a photo to one location, but the public speaker page would read from a different location entirely—two features built independently, never tested together.

The real judging came next. Latent Space's events team, led by Kelsey (head of operations at AI.Engineer), used all 72 submissions as actual human testers. They clicked through like conference organizers would, looking for smooth workflows instead of technical correctness. The team found that many finalists by the automated metric fell apart under real usage. One winner of the AI evaluation ranked 19th in human testing. The disconnect proved that machines and humans measure software quality in entirely different ways.

The competition was framed as an exercise in taste-driven development. Organizers wanted to find people who understood the job to be done—not just someone who could mechanically clone a spec, but someone who could step into the shoes of the actual user and ask what a good experience should look like. That meant encouraging subjective design decisions and tolerating builders who deviated from the spec if the deviation made sense.

Rubrics and specs were intentionally left open-ended. A checklist existed, but it wasn't the main measure. The real question was: Do you understand what we're trying to accomplish? Do you care enough to fix the parts that break?

All three finalists used GPT-4o. So did 50 of the other 66 non-finalist submissions. The model choice alone offered no competitive advantage. Mixing models—Claude for some tasks, GPT-4o for others, Sonnet for edge cases—was common, but the outcomes didn't depend on which models were in the mix.

All three finalists reported one thing in common: they did extensive work before prompting any code at all. They explored the problem space, defined what they were building, wrote preliminary specifications, and thought through edge cases.

This front-loaded planning contradicted an assumption many submissions made—that you could dump a video walkthrough at Claude and get a working app in one prompt. The winners treated the agent as a tool that needed precise instructions, not a mind reader. The planning took time, but it compressed the iteration cycle later.

Valentin de Matos, the competition winner, spent substantial effort on what he called guardrails. Rather than write a specification document, he built the entire setup as a reusable GitHub template. New repositories could clone from it, inheriting all the code-review structure, links, and conventions built in.

The decision reflected a pragmatic choice: documentation gets ignored; code gets copied. If a future maintainer needed to take over the project, Valentin wanted them to write directly on the structure he'd created, not read a guide and rebuild it from scratch. The template approach, combined with open source licensing, meant the project could live beyond him.

Marco, one of the other finalists, took a more direct route: he extracted the API reference from Session Boards and recorded a walkthrough video of how the original tool worked. He fed both the video and documentation straight into Claude, with one constraint: use Convex and Next.js as the tech stack.

Convex was the key choice. It comes with a real-time database that handles performance without extra engineering. For a rapidly built clone meant to pass evaluation, choosing a stack that "feels good without a lot of work" meant fewer debugging cycles and fewer hours spent tuning slow queries.

One finalist observed that the agent was very good at building features but quite bad at noticing when those features didn't work together. A headshot upload feature might save a photo somewhere, but the public speaker page would read from a different storage location—two independent pieces of code, both functional in isolation, both broken in use.

Every finalist used their own product repeatedly as a regular user. Valentin employed a 5-minute smoothness test: if the product couldn't be used smoothly in 5 minutes, something was missing. When friction appeared, he didn't patch it manually. He investigated the root cause—usually a missing context or incomplete spec—and re-engaged the agent with that finding. The goal was to improve the agent's understanding, not just fix the symptom.

The others took similar approaches. They treated themselves as the primary test user and fed what they learned back into the build process, using the agent as an intelligent tool that could learn from failure.

Yazin, another finalist, kept clicking through the app while maintaining a running list of obvious friction points. He discovered that some workflows required signing out and signing back in just to switch between views—a sign that the system wasn't handling state transitions correctly. Rather than manually rewire the code, he documented what the problem was and asked the agent to rethink that part of the spec.

Seventy-two submissions produced decent first-draft clones. The breadth of quality meant that cloning a SaaS—translating the problem into working code—is now tractable for a skilled builder working with an agent. Someone still has to keep it running. That means taking bug reports, fixing critical issues at 2 a.m., and being available when something breaks an hour before a live conference.

Flo, one of the judges, deployed a dozen Codex agents to fix bugs in the token billionaires program the day before a conference began. Agents helped, but a human still had to decide which bugs mattered, which workarounds were acceptable, and when to stop iterating and ship anyway. Operating software requires accountability—a promise that if something is broken, you will fix it—and AI doesn't accept promises.

The phrase "If you break it, you own it" inverts to something more powerful: "If you own it, you can break it." Ownership means you have the authority to ship a fix immediately, without a vendor support loop, without an escalation chain. That power is worthless without the responsibility to use it.

A major sponsor hit a bug: they couldn't unassign tickets. Under the vendor model, the problem followed an escalation chain. The sponsor told Latent Space. Latent Space opened a chat with the vendor. The vendor opened a ticket with their engineers. The engineers replied to vendor support. Vendor support relayed the message back to Latent Space. The advice: try refreshing your cache.

Kelsey, head of operations, refused to ask a multi-million-dollar company to clear their browser cache to work around a system bug. The vendor couldn't accept responsibility for their own breaking changes. The problem was structural: the vendor had no skin in the game. Latent Space did, because they were the ones facing an angry sponsor.

Owning the software means accepting the mental load of ensuring it doesn't break for users. It means you can fix the bug in 10 minutes and have it live before the next coffee break, instead of waiting for a vendor to prioritize your ticket. The accountability gap—vendor doesn't fix it, user suffers—disappears when you own the code.

Five apps cleared the evaluation standard—something Latent Space would either adopt directly or seriously consider buying. Three finalists plus two additional projects met the bar. Another 12 projects had interesting ideas or components that the team planned to reuse even if they wouldn't deploy the entire app.

Valentin de Matos of Open Rostrum won $10,000. His submission built a software factory—an automated system that could debug itself, ship multiple portals, and produce a schedule that Latent Space's team actually wanted to use. Open Rostrum will ship for all 2027 AI.Engineer conferences.

But 2027's setup won't be a pure Rostrum deployment. Latent Space plans to mix Open Rostrum with Conferencer and borrow ideas from a dozen other projects. The cost of this hybrid approach: roughly $1,000 in tokens plus another $10,000 in AI engineering expertise to build and debug it. Compared to $43,000 per year for vendor software, the math is stark. Maintenance becomes the team's responsibility, not the vendor's problem.

The economics matter. AI agents have compressed the cost of entry for custom software. Twelve months ago, cloning a mid-market SaaS would have meant hiring a contractor for weeks. Now it means a skilled builder, some AI credits, and a competition. The savings are real enough that Latent Space can now afford to fund actual software improvements—like better speaker portals or real-time scheduling—that were previously unaffordable.

The evaluation process broke down under the weight of logistics. Latent Space was recording the podcast at AI Engineer New York, scheduling another conference (AI Engineer Code) for the following month, and judging 72 submissions in parallel. The host did this on top of regular day-to-day work. The result was less organized than ideal. Future iterations will structure the evaluation better, delegate judging to specialists instead of managing it solo, and separate the competition timeline from the conference schedule.