The End of the Software Backlog: When Every Business Can Build Its Own Tools (2026)

In December 2025, Garry Tan asked a question in a post that drew more than 1.7 million views: why pay $30 per seat for bundled software when nontechnical people could build their own? He named Taskade with Replit and Emergent. The interesting part was not the $30. It was who gets to build.

For decades, businesses adapted to the tools they could afford. Every missing feature became a workaround, a ticket or another spreadsheet. Now the person who understands the problem can build the solution, and change it when the business changes. That raises a harder question than "can anyone build software?" The harder question is this one: who keeps it running?

TL;DR: Anyone can build software now, so the hard part is vibe coded app maintenance: what happens after the first build. Measure feedback-to-fix latency, the time from a real operational problem to a verified change that people use. Taskade Genesis builds the app, and projects, agents and automations keep it working. Free includes 3 apps. Build your first tool →

The $30 SaaS Seat

Garry Tan, President and CEO of Y Combinator, posted on December 1, 2025 (San Francisco time) that Zoho's business could be the first one competed away by people who build custom software with Replit, Emergent and Taskade. By October 19, 2026, the post had more than 1.7 million views, 1,560 likes, 426 quotes and 647 replies.

The post first said that Zoho could be the first business that customers compete away with software they build themselves. Then it asked the question that matters here:

"Why pay $30/seat/month for over bundled SaaS when soon even nontech ops ppl can vibe-code a custom solution in a weekend?"

Garry Tan on X, December 2025

The debate that followed, with the reply from Zoho and the reaction across the industry, is covered in Will Vibe Coding Kill SaaS?. This essay does not ask whether SaaS dies. It asks what a business does on the Monday after the weekend build, and in month six.

Two words in the post matter more than the price. The first is "ops". The post does not say "engineers". It says the operations people who run the business can build. The second is "weekend". A weekend is enough time to build a first version. It is not enough time to learn whether the version survives real customers, new requirements and new staff.

The Workaround Economy

The workaround economy is every spreadsheet, copy-paste step, side inbox and unanswered feature request that a business uses to cover the gap between its tools and its work. Each workaround looks small. Together they become the real operating system of the business, and nobody owns it, tests it or improves it.

Most businesses do not run on their software. They run on the space between their software. A sales lead arrives in a form tool, gets copied into a spreadsheet, gets pasted into a CRM, and gets a follow-up email that someone writes by hand. A client asks for a status update, and an account manager searches three places to answer. A machine needs service, and the reminder lives in one person's calendar.

None of these steps is a failure of effort. They are a failure of fit. The software was built for the average customer of the vendor, and your business is not the average customer. So the people closest to the work fill the gap with what they have. Retool's 2020 State of Internal Tools survey found that Google Sheets was the most popular software for building internal tools. The spreadsheet is the oldest app builder in the office.

The cost of the workaround economy is rarely on an invoice. It shows up as slow answers, missed follow-ups, and the quiet decision to stop asking for improvements. A team that stops asking stops improving.

The backlog is the visible part of this economy. In agile teams, a backlog is a ranked list of work for a product team (see the wiki entry on the backlog). In most small and mid-size businesses, the software backlog is less formal. It is a set of complaints about the tools that people stopped saying out loud.

Who Changes the Tool When the Work Changes?

The people closest to the work are the operations leads, account managers, coordinators and owners who see each problem first. They know which field is missing, which step repeats and which customer question comes back every week. Until now, they could describe the fix but could not build it. AI app builders change who can build.

The dispatcher who moves jobs every morning knows what a field-service schedule needs. The account manager who answers the same three questions every Friday knows what a client portal must show. In the old model, their knowledge passed through a chain: a request, a meeting, a spec, a ticket, a sprint, a release. Each step lost detail and added time.

The table has one honest limit. Removing handoffs removes delay, but it also removes review. A developer who ships a change also asks, "What breaks if I do this?" When an operator builds, that question still needs an owner. Most of this essay is about how to keep that question alive without bringing back the queue. For a deeper look at the operator as builder, read Agentic Engineering Without Code.

Feedback-to-Fix Latency Across Five Eras

Feedback-to-fix latency is the time from the first report of a real operational problem to a verified change that people use. For fifty years, that latency depended on someone else: the IT department, the ERP consultant, the SaaS vendor. AI-built software is the first era in which the person who reports the problem can also make the change.

The table below asks one maintenance question of each era: when a tool must change, where does the request wait, and what sets the latency? It gives no wait-time numbers, because no reliable source measures them across eras. For the dated history of build vs buy, read When Customers Build Their Own Software.

Each era moved the change one step closer to the work, and each left a workaround behind: the paper form, the spreadsheet beside the ERP, the shadow tool beside the SaaS app. In 2025, the workaround and the fix can be the same thing. The person who would have built a spreadsheet can now build the tool, if they also learn to verify it.

From Feature Request to Working Software

A feature request becomes working software in five steps: describe the problem in a prompt, get a live app, connect it to real data, add an agent that reasons over that data, and add automations that run the repeat steps. Taskade Genesis builds all five layers in one workspace, so the change is live the same day.

Here is one complete example with a real kit: the Maintenance Tracker Dashboard. It tracks equipment maintenance schedules, service history and upcoming repairs with automated reminders. The kit holds 3 projects, 1 AI agent and 2 automations.

The problem. A facilities team tracks equipment service in a spreadsheet. A machine misses its service date because the reminder lived in one coordinator's calendar. The team asks the vendor of its asset tool for a reminder feature. The request goes into a roadmap with no date.

Step one, the prompt. The coordinator clones the kit from the app gallery, or describes the job in Taskade Genesis: "Track each machine, its last service date, its service interval and the technician who owns it. Remind the technician seven days before the next service is due."

Step two, the app. Taskade Genesis builds a live dashboard with machines, service history and upcoming repairs, ready to share the same day.

Step three, the data. The records live in workspace projects, not inside the app. The team can edit them as a table and use them from other apps and agents. See how projects work as a database.

Step four, the agent. An AI agent with the maintenance records as knowledge can answer "which machines are due this month?" from the same records that the dashboard shows.

Step five, the automations. An automation runs the reminder. When a service date comes within seven days, it notifies the owner. When a technician marks a job done, it logs the service to history. Taskade automations connect to 100+ integrations. Triggers pull events in, and actions push data out. See how automations run.

The important moment is not the first build. It is the first change. Two weeks later, a technician says the reminder must include the parts list. In the old model, that request starts a new wait. Here, the coordinator opens the app and asks Taskade EVE in chat: "Add a parts-needed field to each machine and include it in the reminder." Taskade EVE edits the app, and the coordinator tests it with one real machine before the next reminder goes out.

That second change is where the backlog ends. The request went from a sentence to a verified change without a ticket, a vendor or a sprint. If you want to compare builders before you start, the free AI app builders guide ranks the options with their free plans.

The New Software Factory

Guillermo Rauch, CEO of Vercel, describes a business as a software factory that turns signals into fixes, and he says the measure is the latency from signal to shipped fix. In an October 2026 interview, he separated iteration speed from iteration velocity and argued for verification, not micro unit tests, as the guardrail. For the definition, the history and the metrics of the category, see our guide to the AI software factory.

Rauch gave the interview on the David Ondrej channel on October 2, 2026. His examples come from a software company, but four of his ideas apply to any business that builds its own tools.

1. A rubric for how agentic a company is. Rauch proposed three questions. When a customer reaches out, do you reply with a high-quality response? When they report a problem, do you start an investigation? When they report a concrete, fixable thing, do you fix it? Then measure the latency from signal to shipped fix. At one end, a company reviews feedback now and then. At the other end, it becomes autonomous "in a good way", which does not mean agents that run wild.

He also kept a place for judgment. Some feedback is objective, such as an exception in production or a clear improvement. Other feedback, such as "the navigation confuses me", is good but not something you can turn into a prompt. A person still decides.

2. Speed is not velocity. Vercel separates iteration speed, how fast you turn out work, from iteration velocity, speed in a direction. Rauch warned that you can land changes "into oblivion". His advice was to pick a few problems where you have an advantage and go deep on them.

3. Verification engineering. Rauch describes verification engineering as the work of setting guardrails, a "proof system", around what you build. You and the agent agree on the axioms and the trade-offs. He is skeptical of micro unit tests that give false confidence. He would rather spend effort on the edges of the system: what must be correct, what it must feel like, and what you will not trade off.

4. Know your customer. Building is easy when you are the customer, because the test is whether you like the app. Selling to others is different. Rauch likes a metric called error-free sessions: one real visitor, start to finish, with every step working.

The third row needs an honest note. Taskade does not ship a fix to your app on its own when a signal arrives. A person still asks for the change, and a person still checks it. What Taskade shortens is everything around that decision: the signal reaches the right owner in seconds, the context is in one workspace, and the change is a chat request instead of a ticket.

Rauch's interviewer made the competitive point plainly: a business that fixes problems in under 30 minutes beats one that takes two days. Rauch agreed, and compared it to the companies that adopted PCs and the internet early. The companies that hired someone else to "do the internet" fell behind. The same split is coming for the tools a business runs on.

The Factory at Small-Business Scale

Vercel published numbers for its own factory in August 2026. In Building a software factory for AI SDK, the team reports that four weeks in, the factory authored between 25 and 35% of the pull requests it merged and closed 70 to 80% of issues. Open issues fell from a peak of 1,022 in late June to 844 by early August, and open bugs fell by roughly 25%. The post also sets one rule: "A human stays in control throughout the entire process, including merging every change."

A small business has no pull requests, but it has the same loop. Here is the translation.

In an August 2026 interview with a16z speedrun, Rauch put the same idea in one line. The value is in "your ability to create the verification loops", and the goal is to "keep it up to date as fast as you can". That second phrase is the whole job of maintenance.

What Happens After the Weekend?

After the weekend, an app meets real customers, changing requirements, growing data, new people who need access, and steps that must run without anyone watching. A weekend build answers "can it work?" Month six answers "does it still work?" The second answer depends on data, permissions, automations and verification, not on the first prompt.

The phrase "in a weekend" in the Garry Tan post is true. A first version in a weekend is now normal. But a business does not run on first versions. Garry Tan named the risk himself in March 2025, when TechCrunch reported on the YC W25 batch. He pictured a startup with 95% AI-generated code and 100 million users a year or two later, and asked: "Does it fall over or not?"

Here is what changes when real use begins.

Real customers. The first customer finds the case you did not think about, such as a phone number in the name field. You learn about it from a person, not a test.

Changing requirements. A new service line needs a new field, and a new rule needs an approval step. A tool you can change in chat keeps up. A tool you must request changes from falls behind again.

Persistent data. A demo can lose its data. A CRM cannot. In Taskade, the data lives in workspace projects, outside any one app, so you can rebuild a screen without losing a record.

Permissions. More people need access, and not all of them need the same access. Workspace members get role-based access from Owner to Viewer. App visitors are different. Client sign-in works on every plan. Sign-in tells the app who the visitor is. It does not hide other people's records on its own. You match records to the login, and you test it with a second account. See App Users.

Automation. The reminder, the follow-up and the weekly summary must run when nobody is looking. An app without automations is a screen. An app with automations is a process.

Verification. Every change must be checked against the outcome. Taskade Genesis keeps saved app revisions that you can preview and restore, and it can detect app errors and attempt a targeted repair. See App Revisions & Restore and AI error recovery.

The ASCII sketch below shows the same request in both worlds.

BEFORE: the feature request path
  Ops lead sees a problem
-> writes a request to the vendor or the IT queue
-> waits for a roadmap slot (no date)
-> builds a spreadsheet workaround in the meantime
-> the workaround becomes permanent
Result: the problem is "handled", never fixed
AFTER: the build-and-verify path
  Ops lead sees a problem
-> asks Taskade EVE for the change in chat
-> tests it with a real record and a second account
-> publishes the revision, keeps the old one to restore
-> the agent and the automation use the new field
Result: a verified change the same day

Rauch's warning about slop applies here too. If anyone can one-shot an app, a one-shot app adds no value. The value comes from what you add after the first version: your data, your rules, your follow-up steps and your checks.

Vibe Coded App Maintenance: What Breaks in Month Two?

Vibe coded app maintenance is the work of keeping an AI-built app correct after real people use it. In month two, the usual failures are sign-in problems, triggers that stop, expired integration keys, used-up credits, growing data, outdated packages and edits that break another page. Most of them are quiet, so someone must look for them.

In month one, nothing has changed and the builder remembers every detail. In month two, the business changes, edge cases arrive and the builder forgets why a field exists. Two public studies show why code-level maintenance is hard.

• Security. Veracode's 2025 GenAI Code Security Report found that AI-generated code introduced security flaws in 45% of tests, across 80 coding tasks and more than 100 models. The figure is per task, not per app, but every task is a place to look.
• Code quality drift. GitClear's AI Copilot Code Quality 2025 research found that copy-pasted lines rose from 8.3% to 12.3% of changed lines from 2021 to 2024, while moved (refactored) lines fell to under 10%. More copied code means more places to fix the same bug.

Both studies describe code that someone maintains in a repository. A hosted workspace removes part of that work, but not the part about your data, your rules and your access. The ledger below lists the common failures and where the fix lives in each world.

The pattern in the ledger is simple. In a repository, most fixes need a developer and a deploy. In a workspace, most fixes need an owner and a check. That is why the owner matters more than the builder.

A Maintenance Cadence You Can Copy

A maintenance cadence is a fixed schedule of small checks that keeps an AI-built app correct: one check for each change, a short daily scan, a weekly review of open requests and a monthly review of access, cost and latency. The cadence below fits a small team and needs no developer.

Most app failures are not dramatic. A trigger stops, a key expires, a field changes meaning. A cadence turns those quiet failures into scheduled checks. Copy the table into a Taskade project and assign each row to a person.

The last step feeds the first one. What you see while you watch becomes the next report. Here is the same cadence as a checklist you can paste into a project:

• Before each change, note the live app revision.
• After each change, test with one real record.
• After each change, open the app as a second account.
• After each change, confirm the automation run in the run history.
• Each day, give every new request an owner.
• Each week, close the requests you verified.
• Each week, ask the agent three real questions and compare the answers with the records.
• Each month, review members, App Users and credit use.
• Each month, write down your feedback-to-fix latency.

Who Owns the App?

The owner of an AI-built app is the one person who answers for five areas: incidents, releases, access and data, recovery, and cost. In a small business, that is usually the person who built it. Name the owner before launch, because an app that everyone uses and nobody owns becomes the next workaround.

In a team of five, ownership means one name next to each question below. Without that name, nobody notices the failures in the ledger above.

Ownership also answers a question that Retool's 2026 Build vs. Buy report raises. Retool found that 60% of the builders it surveyed built something outside IT oversight in the past year. An app outside IT oversight is not a problem by itself. An app outside anyone's oversight is.

What It Costs to Keep It Running

Keeping an AI-built app running costs mostly time: the minutes to verify each change, the daily scan, the monthly review. The tool cost in Taskade is one plan, with Free to start, Pro at $10 per month billed annually and Business at $25 per month billed annually. The hidden cost is maintenance that nobody planned for.

Retool's 2026 Build vs. Buy report, a survey of 817 Retool customers and builders, found that 51% of builders have production software built with AI that their teams use. The same report adds a warning: "Time saved on one task can be offset by time lost to maintenance." It also notes that vibe coding at work looks different than on the weekend.

The table below lists the costs to plan for. It gives no hourly figure, because the time depends on how often your process changes.

One cost is missing from the table because a hosted workspace carries it: servers, database, deploys and package upgrades. In your own repository, those are yours too.

What Not to Maintain Yourself

Some systems carry a maintenance burden that a specialist vendor carries better: payments, payroll and tax, regulated records and security tools for your staff. Their rules change by country and by year, and each one adds what Rauch calls security debt: more attack surface to defend. Buy these, and let the vendor keep them current.

Maintain the layer around them that changes with your process: CRM views, client portals, intake forms and dashboards. Automations connect the two, because triggers pull events in from the system you bought and actions push data out to it.

The Workspace Is the Foundation

A business tool keeps running when it sits on a workspace where projects remember, agents reason, automations run and apps serve. Taskade calls this Workspace DNA: Memory, Intelligence and Execution. An app that sits alone on a server is a screen. An app on a workspace is a process the team can change.

The screen is what you see in a demo, but it is the smallest part of a business tool. The rest is the data, the reasoning and the repeat steps. If those live somewhere else, every change to the screen is a new integration project.

The loop is what makes the workspace a foundation. Memory feeds Intelligence. Intelligence triggers Execution. Execution creates new Memory. A form entry becomes a record. An agent reads the record and flags it. An automation sends the follow-up and logs it. The log becomes context for the next request. Each change starts from more context than the last one.

This is the argument of Software That Runs Itself and Agentic Workspaces, applied to the backlog. The workspace is what makes the second change cheap. Without it, every change is a rebuild. With it, a change is a sentence.

Build Around the Business

The fastest way to start is to clone a real kit for a job your team does every week, connect it to your data, and change one thing that the old tool never let you change. Three common starting points are a CRM, a client portal and an operations dashboard, each with real data, an agent and automations.

Every kit below includes automations, and cloning a kit with automations needs a paid plan. On Free, describe the same app in Taskade Genesis instead: the automations you build yourself get 10 runs a month.

Each example below uses a real kit from the Taskade app gallery. Clone it, then make it yours in chat. Browse more kits on AI Apps.

A CRM that follows your sales process

The Sales Pipeline Dashboard is a featured kit with 3 projects and 1 AI agent, and you shape its stages to how your team sells. Add a forms trigger so each new lead becomes a deal with an owner, and compare options in AI CRM builders.

A client portal that answers the Friday questions

The Client Portal is a multi-page service portal with intake, profile and dashboard sections, with 3 projects, 1 AI agent and 4 automations. Match each record to the client's login and test with a second account before you share it, then see more in client portal builders.

An operations dashboard the team checks every morning

The Inventory Management Dashboard tracks stock with alerts, supplier management and reorder workflows, with 2 projects, 1 AI agent and 5 automations. For team work instead of stock, the Neon Task Management Dashboard tracks tasks, milestones and team progress, and AI dashboard builders compares the options.

These are the same jobs that show up when you look at what people actually build. In a Taskade census of 471 top-traffic paid apps, dashboards and analytics were the largest category at 28.2% of traffic, and the average app had 5.9 connected projects and 2.3 AI agents. Read the full breakdown in What People Build With AI.

The Next Competitive Advantage

The next competitive advantage is not who has the most software. It is how fast a business turns a real operational problem into a working, verified change. Feedback-to-fix latency and iteration velocity are the numbers to watch. Every business can build now, so the edge goes to the one that fixes faster and checks its fixes.

When every business can build, building stops being the edge. The edge moves to the loop: how fast a signal reaches the person who can act, how fast that person can change the tool, and how sure they are that the change works. Here is a simple scorecard to start with.

Start small. Pick one workaround that annoys your team every week. Describe the job in Taskade Genesis, or clone a kit on a paid plan. Make one change, verify it with real data, and write down how long it took from the first complaint to the verified change. That number is your feedback-to-fix latency. Next month, make it smaller.

The Free plan includes 3 apps, 1 agent and 2 members, and it starts with no AI credits. You earn credits with referrals and invites, or buy a credit pack on any plan. Pro is $10 per month billed annually, and Business is $25 per month billed annually. Compare the plans on pricing.

Anyone can build software now. The businesses that win will be the ones that keep it running, change it every week, and know that each change works. Memory, Intelligence and Execution, in one workspace. ▲ ■ ●

Build your first tool in Taskade Genesis →

Related Reading

• Will Vibe Coding Kill SaaS? The Garry Tan vs Zoho Debate
• When Customers Build Their Own Software
• Software That Runs Itself
• What People Build With AI

Frequently Asked Questions