Convenience Is the Product

Andy Brice volunteered to arrange the seating at his wedding. Sixty guests. He expected a fairly straightforward problem and ended up writing software to solve it.

He released PerfectTablePlan in February 2005. In his twenty-year account, published in February 2025, he said it had been profitable every year since launch.

A seating chart can be made on paper. A spreadsheet can hold the guest list. Yet there was enough work around that apparently small task to sustain a software business for two decades.

What are people buying when they pay for something they could already do themselves?

My thinking about convenience took shape while listening to James Clear discuss Atomic Habits on a podcast. One idea stayed with me: a product can be built around making something people already want easier to get. His 25 June 2020 newsletter captures it in one question: “Does it save time or energy?”

At first, I applied that question only to apps: does this make life easier for the person using it? Then I noticed that the developer building the app asks the same question when choosing authentication, payments, databases and deployment. The platform underneath makes the same choice again.

Each layer sells convenience to the one above and buys convenience from the one below.

A small task can hold a business

PerfectTablePlan saves more than the minutes needed to type sixty names. It works with preferences about who should sit together or apart, and it lets the host change the arrangement without beginning again.

The same pattern appears in activities that look unrelated. Paprika combines ingredients from several recipes into one shopping list and sorts it by aisle. forScore organises and annotates sheet music, with support for page-turning pedals so a musician can move through a score without taking a hand away from the instrument.

Readwise brings selected highlights back through an app or daily email. Leave Me Alone helps someone finish accumulated email-unsubscription work. Its co-founder reported about $10,000 in monthly revenue in early 2023, including customers who bought short access passes rather than another subscription to remember.

These products remove different kinds of work. Paprika removes preparation. forScore prevents an interruption at the precise moment it matters. Readwise carries some of the remembering. Leave Me Alone packages an occasional cleanup without insisting that it become a permanent relationship.

The visible operation can be tiny. The surrounding burden is often larger.

That is why ability is a poor test of whether a product deserves to exist. The wedding host can make a seating chart. The pianist can turn a page. The reader can search old notes. Capability tells us whether someone can do the work; convenience asks whether that work deserves their attention every time.

That made me look behind the app. A user pays to make the task easier; the developer pays other products to make delivering it easier.

The customer inside every product

Suppose someone builds a new seating application today. The customer still wants help arranging guests. Behind that simple promise, the application needs accounts, a database, emails, payments, deployment, monitoring and a way to recover when something fails.

The developer could build each part. That choice would mean learning the security details of sign-in, operating a database, maintaining an email service, handling payment failures, collecting taxes, configuring servers and watching all of it after launch.

Or the developer could become the customer.

Clerk sells authentication and user management. Resend exposes email delivery through an API. Paddle acts as merchant of record for covered sales and takes responsibility for collecting and paying the associated sales taxes. Healthchecks.io watches for missing signals from scheduled jobs.

The same pattern runs across the rest of an application. Twilio packages communication networks behind APIs. Algolia packages search infrastructure. Cloudinary packages image storage, transformation and delivery. LaunchDarkly packages controlled feature releases. Upstash packages data services and durable background workflows.

Each one turns a specialised operating problem into something another developer can buy.

This is the recursive part of convenience. A person pays an application to remove work. The application builder pays several other products to remove work from building and operating that application. Those providers pay cloud platforms to remove still more work underneath them.

Convenience did not leave the application layer. It found more customers inside the stack.

From machines to managed services

The boundary moved in stages.

When Amazon introduced EC2 in August 2006, a developer could obtain and boot a server instance in minutes and pay for the capacity used. Procuring a physical machine was no longer a requirement for every new application.

An EC2 customer still managed the operating system, database and application. Amazon RDS arrived in 2009 with automatic database patching and backups. AWS Lambda followed in 2014, running functions without asking the customer to configure or monitor server instances.

One provider. Three different boundaries. With each higher-level service, more operational work moved to the seller.

The API economy applied the same move to specialised capabilities. Twilio launched its first Voice API in 2008, turning telephone infrastructure into calls a program could make. In January 2024, co-founder Jeff Lawson reported more than $4 billion in annual revenue across the broader communications business.

Stripe made payments programmable and expanded into billing, invoicing and tax. Businesses using Stripe generated $1.9 trillion in payment volume during 2025, while its broader Revenue suite approached a $1 billion annual run rate in 2026.

Revenue does not prove that convenience alone caused either company’s success. It does establish the commercial scale of selling difficult capabilities to other builders.

The present generation brings several of those boundaries together. Vercel describes managed infrastructure for deploying, scaling and securing applications. Railway can take code, a container or a prepared template and turn it into a running service. Supabase combines a managed Postgres database with authentication, storage, realtime features and functions.

Neon narrows the database problem further. It provisions Postgres, separates compute from storage, scales resources and creates isolated database branches for development. A developer can ask for a database connection instead of first becoming a database operator.

Vercel’s marketplace now lists databases, authentication, messaging, payments, storage, flags, observability, AI models and workflow services. The list resembles an application taken apart and offered back as managed pieces.

Writing software still takes judgment. The difference is that a builder can spend more of that judgment on the part specific to the customer, while buying many of the surrounding capabilities.

When the managed service breaks

A managed service changes who gets called when something goes wrong. AWS describes this as the shared-responsibility model. AWS runs the physical infrastructure behind EC2, while the customer manages the operating system and application. Higher-level services move more work to AWS, but data, permissions and configuration remain with the customer.

Neon showed what this handoff looks like in May 2025. During two incidents totalling 5.5 hours in one AWS region, customers could not create or wake inactive databases. Neon’s postmortem traces the problem through control-plane queries, capacity pressure and IP allocation. Databases that were already running stayed online.

A Neon customer had no direct way to repair those systems. The bargain was that Neon carried this part of operations, sparing each customer from staffing for it and making them dependent on Neon doing it well.

This is part of what the customer pays for. When the problem sits below the interface, the provider’s engineers carry the pager.

AI moves the boundary again

AI is beginning to compose the managed pieces as well as help write the code between them.

v0 can generate full-stack applications, connect them to databases and other marketplace services, and deploy them on Vercel. Replit Agent can build from a conversation and present a control for publishing the result.

This makes a first working version available to more people. The size of the effect depends on the person and the task. A GitHub-controlled experiment found faster completion for one JavaScript server exercise, while METR’s early-2025 study found experienced open-source developers took longer on mature projects. METR’s February 2026 follow-up found signs of improvement with later tools but could not produce a reliable general estimate because of selection and measurement problems.

The useful claim is narrower: AI can lower parts of the construction effort. It does not settle whether the result is correct, secure, understandable, economical to run or dependable when customers arrive.

Those remaining burdens point to the next products. One service may verify what an agent built. Another may operate it, migrate it, repair it or complete a governed business workflow. The best opportunity will depend on which work remains with the customer after the demo succeeds.

Brice’s seating planner has accumulated a large codebase and extensive documentation over twenty years. Easier components would change how a similar product could be assembled today. They would not remove the years of product decisions behind a durable business.

At the top, the wedding host buys relief from arranging and rearranging sixty people. The application builder buys relief from operating every technical layer underneath that promise. Providers beneath the application make the same exchange again.

The stack keeps changing. Convenience remains the product.