Not all apps are created equal: a classification framework for AI-assisted development

Your team just shipped a prototype in two days using Lovable and a couple of screenshots. Next sprint, you're building a HIPAA-compliant consumer platform for 50,000 users. Same tooling, same process?

That's how projects go sideways.

We developed a four-class framework for categorizing applications before a single line of code gets written. The class determines your tools, your team structure, your infrastructure, and how much process is appropriate. Get the classification wrong and you're either over-engineering a throwaway prototype or under-engineering something your business depends on.

Here's how the four classes break down.

Class D: Prototype and small apps

Class D apps are vibe-coded. Tools like Lovable, Replit, Claude Code, or OpenAI Codex handle the heavy lifting. You don't spend much time on code review, design, or structured interaction with the AI agent.

The workflow is intentionally loose: feed requirements (often unstructured), pass errors or screenshots back through the chat window, iterate fast. A business analyst can build a Class D app. That's a feature, not a limitation.

Use when: You need a quick proof-of-concept, internal tool, or throwaway prototype where speed matters more than rigor.

Class C: AI-augmented software engineering

Class C is where AI-augmented software engineering begins in earnest.

These are low-to-medium complexity applications – standalone, possibly single-tenant – built by a software engineer using tools like GitHub Copilot, Cursor, or Codex. Unlike Class D, the process is structured around a deliberate loop:

Brainstorming — align on the problem before touching the solution
Planning — structured specs and technical design feed the AI agent
Coding — AI-assisted development with minimal handwritten code
Code review — systematic review even when AI wrote the code
Unit tests — automated coverage built into the loop
UX tests — validate the interface before shipping
Human QA — a human signs off before release

The key shift from Class D: the AI agent is a collaborator in a structured process, not a chat window you throw requirements at.

Use when: A single engineer is building a real product with defined requirements, and quality and maintainability matter.

Class B: Business and consumer applications

Class B is a meaningful step up in both complexity and consequence.

These applications serve medium-sized businesses or public consumer audiences at scale. That means security requirements, potential HIPAA or SOC 2 compliance, multi-tenancy, and infrastructure that has to hold up under real load. From a coding standpoint, the process mirrors Class C – but it runs in parallel across multiple engineers, coordinated by a tech lead and project manager.

Class B requires a team. Multiple parallel coding sessions, dedicated infrastructure beyond Vercel or Railway, and formal processes that Class C can skip.

Use when: You're building for external users, operating under compliance requirements, or the application is core to your business.

Class A: Enterprise

Class A is AI-augmented software engineering at enterprise scale.

Everything from Class B applies, but with significantly more around it: multiple teams working in parallel, strict project management, comprehensive documentation, and infrastructure exclusively on AWS or Azure. You're also adding services that lower classes don't need: infrastructure monitoring, disaster recovery, business continuity planning.

The architecture gets serious. The team gets larger. The processes get formal. AI still powers the development loop – but it operates inside a system built to support enterprise reliability and compliance standards.

Use when: You're building at organizational scale, with uptime, security, and governance requirements that demand it.

Why classification matters before you start

Picking the wrong class doesn't just waste time. It creates risk.

A Class D process applied to a Class B problem produces fragile, under-tested code running on infrastructure that can't scale. A Class A process applied to a Class D problem produces a six-week engagement for a two-day build.

Before any project kicks off, classify it. The class sets the budget, the team, the tools, and the process. Everything else follows from there.