Skills / Software-development

Rapid Application Development (RAD)

The purpose of RAD is not to build systems faster at the expense of quality. It is to build quality systems faster by involving users continuously and catching errors before they become embedded in the code.

James Martin's Rapid Application Development (RAD) is a four-phase software development lifecycle that replaces slow Waterfall handoffs with timeboxed prototype cycles and collaborative JAD (Joint Application Development) workshops. Instead of locking in requirements upfront and delivering months later, RAD puts users in the design process from day one — catching misalignment in hours, not years. It is designed for business application development where speed-to-value and user acceptance are both critical.

By James Martin  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisRapid Application Development (RAD)

Input

“We're building an internal expense management tool for about 200 employees. Four developers on the team. We wrote a 40-page spec last time and by UAT…”

Diagnosis

RAD's core premise is this: the longer the gap between a user's need and working software in their hands, the higher the rework cost.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Ship working software in 90 days by putting users in the room while it's built

RAD organizes software delivery into four sequential but timeboxed phases. Requirements Planning brings stakeholders together to define high-level scope without locking detailed specs. User Design is the engine of RAD: iterative JAD (Joint Application Development) workshops where users and developers jointly build and critique prototypes, cycling until the design is approved — replacing written specifications with working demonstrations. Construction converts approved prototypes into production components at speed, with users remaining accessible for rapid feedback. Cutover closes the loop with data migration, integration testing, user training, and deployment. Two structural rules govern every phase: timeboxing (fixed 60–90 day development windows that force scope decisions rather than schedule slippage) and SWAT Teams — Skilled Workers with Advanced Tools — small, empowered cross-functional groups who own their delivery without committee approvals.

The problem

Waterfall projects routinely deliver systems users don't want — because users are consulted at requirements gathering and again at final acceptance, with months of silent development in between. By the time a working system is demoed, requirements have shifted and rework is catastrophically expensive. RAD was designed to eliminate this gap by making users co-designers rather than reviewers, catching misalignment during the design phase when correction costs minutes instead of months.

The solution

Apply Martin's RAD framework to compress your development cycle into disciplined 90-day timeboxes, structure your JAD sessions so users co-design instead of just sign off, and build prototype-first momentum that catches misalignment in weeks, not years.

You bring

A software project with a defined business sponsor and approximate scope
Understanding of your team size, skill levels, and available tooling
Current pain points: missed deadlines, rework from late user feedback, scope creep
Constraints: budget, timeline, and organizational readiness for iterative delivery

You get

A four-phase RAD project plan with per-phase goals, timebox lengths, and phase-gate exit criteria
A structured JAD workshop agenda ready to run with your stakeholders
A SWAT team role matrix with recommended composition and decision authorities for your project scope
A prototype review checklist that drives the User Design phase feedback loops

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your team spent six weeks writing a 40-page requirements spec for the expense tool. Developers built to the spec for four months. At UAT, finance staff flagged that the approval routing logic doesn't match how approvals actually work — the spec described the old org structure, but nobody caught the change until users touched the system. You're now three weeks into rework with the launch date slipping and the CFO asking for a status update.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Rapid Application Development (RAD)

“After two JAD sessions, your finance manager caught the approval routing gap in Week 3 — while reacting to a prototype, not reviewing a document. The developer fixed it in two days. The User Design phase closed with a checklist of five screens, all signed off. By Day 75, you deploy an expense tool that finance staff already know how to use because they co-designed it. Zero post-launch rework on the core approval workflow.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Rapid Application Development (RAD)Claude

Rapid Application Development (RAD)

RAD's core premise is this: the longer the gap between a user's need and working software in their hands, the higher the rework cost. I help you close that gap using James Martin's four-phase framework. To start — what project are you planning, and roughly how long have you been burned by requirements changing after development is underway?

We're building an internal expense management tool for about 200 employees. Four developers on the team. We wrote a 40-page spec last time and by UAT half of it was wrong because finance's approval process had changed.

That's a textbook Waterfall failure mode — and your project has strong RAD candidate characteristics. You have a defined user population, a bounded business application scope, and a team that fits a SWAT configuration. Before I draft your four-phase plan, two gating questions: Can you get 4–6 finance staff and expense submitters to attend prototype review sessions every two weeks for about 60 days? And does your business sponsor have authority to make scope decisions in those sessions, or does every change need a separate approval chain?

Finance manager and three frequent travelers could participate. Our CFO is the sponsor and she's pretty hands-on — lightweight approval chain.

Strong RAD conditions. Here's your four-phase structure in a 75-day timebox:

Phase 1 — Requirements Planning (Days 1–7): CFO + finance manager + one developer define scope boundaries in a single session. Output: a one-page scope statement and an explicit out-of-scope list. No detailed specs.

Phase 2 — User Design (Days 8–45): Three JAD workshops, two weeks apart. Your team demos a working prototype; finance staff and submitters react to it in real time. Each session closes with an approved prototype and an issue log — users are co-signing the design, not reviewing a document.

Phase 3 — Construction (Days 46–68): Developers build production components from approved prototypes. Users are on call for same-day questions — not locked out until acceptance testing.

Phase 4 — Cutover (Days 69–75): Data migration from your current process, integration testing, finance manager sign-off, user training.

Want me to generate the JAD workshop agenda for your first User Design session, or the full Phase Plan document first?

JAD workshop agenda — I've never run one and I'm worried it'll just turn into another requirements meeting.

That's the most important distinction to get right. The failure mode you're describing — JAD becoming a requirements meeting — happens when there's no prototype to react to. Martin's rule: in a JAD session, the prototype is the agenda. Users aren't describing what they want; they're approving or flagging specific screens they can see and click.

Here's the structure for your first 90-minute session:

Pre-work (3 days before): Each participant submits their top 3 friction points with the current expense process. This primes them to evaluate the prototype against real pain, not theoretical preferences.

Opening (10 min): Facilitator states the session rule explicitly: 'We're not writing requirements today. We're approving or flagging specific screens. Every item gets one of three outcomes: Approved, Change Required with a specific change logged, or Deferred.'

Prototype walkthrough (25 min): Developer demos the prototype as a user submitting a $450 travel expense with a missing receipt — no feature narration, just using it.

Structured review (35 min): Facilitator works through each screen on the checklist. CFO breaks ties on Change Required vs. Deferred calls.

Issue prioritization (15 min): Must-fix before next session vs. nice-to-have. Anything not decided goes to the Parking Lot — visible, tracked, but not in the active build.

Close (5 min): Confirm next session date and what the prototype will show that it doesn't show today.

Tell me the 4–5 main screens your prototype will cover and I'll generate the full review checklist.

Screens are: expense submission form, receipt upload, approval workflow, rejection and resubmission, finance dashboard.

I'll build the prototype review checklist for all five screens. For each one: functional coverage questions (does it do what it must?), edge-case prompts (foreign currency, missing receipt, multi-level approval), and an explicit Approved / Change Required / Deferred field your facilitator fills in real time. At the end of every JAD session you'll have a signed checklist — that's your phase gate into Construction, not a spec document no one will enforce.

Reply to Rapid Application Development (RAD)…

What the skill is doing

01Four-Phase Project Scaffolding

02JAD Workshop Design

03Timebox Planning and SWAT Team Composition

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

RARapid Application Development (RAD)typing…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

We're building an internal expense management tool for about 200 employees. Four developers on the team. We wrote a 40-page spec last time and by UAT…9:14✓✓

RAD's core premise is this: the longer the gap between a user's need and working software in their hands, the higher the rework co…9:14

I help you close that gap using James Martin's four-phase framework.9:15

To start — what project are you planning, and roughly how long have you been burned by requirements changing after development is…9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Four-Phase Project Scaffolding

Breaks your project into Martin's four phases — Requirements Planning, User Design, Construction, and Cutover — with defined inputs, outputs, and exit criteria for each. Produces a project plan that prevents phases from bleeding together and enforces the user-involvement steps that make RAD different from sequential delivery.

◦ MethodBased on Martin's four-phase RAD lifecycle from Rapid Application Development (1991), which mandates that each phase has a defined owner, a concrete deliverable, and a timebox constraint — scope is adjusted to fit the window, never the reverse.

CapabilityC-02

JAD Workshop Design

Generates a complete Joint Application Development workshop agenda: pre-session participant briefings, structured prototype review exercises, conflict-resolution checkpoints, and sign-off criteria. JAD is where RAD earns its speed — users react to working screens rather than written specifications, catching misalignments before they become embedded in production code.

◦ MethodBased on Martin's JAD workshop model in which a neutral facilitator guides users and developers through collaborative prototype evaluation cycles, replacing requirements documentation with live demonstration and structured feedback.

CapabilityC-03

Timebox Planning and SWAT Team Composition

Sizes your SWAT team and builds a timebox schedule calibrated to your project's scope and organizational context. Outputs include team role assignments, required skills, decision authorities, and a scope triage protocol for managing new requests without blowing the timebox.

◦ MethodBased on Martin's SWAT Team principle — Skilled Workers with Advanced Tools — and his 60–90 day timebox rule, which treats schedule compression as a design constraint that forces scope decisions rather than an aspirational target that gets abandoned under pressure.

CapabilityC-04

Prototype Review Facilitation

Produces a structured prototype review checklist for the User Design phase — guiding reviewers through functional coverage, edge-case discovery, and explicit approval or rejection decisions. Keeps each iteration loop short and decision-bound so workshops produce signed artifacts, not just notes.

◦ MethodRooted in Martin's core thesis that prototype-based user feedback cycles dramatically reduce rework by surfacing misalignment during User Design rather than after Construction — when the cost of correction is orders of magnitude lower.

CapabilityC-05

RAD vs. Waterfall vs. Agile Suitability Assessment

Evaluates your project against the conditions under which RAD delivers its best results: bounded business application scope, user availability for workshops, team empowerment, and organizational tolerance for evolving requirements. Produces a scored comparison with a clear methodology recommendation.

◦ MethodBased on Martin's original framing of RAD as a targeted alternative to Waterfall for projects where user involvement is feasible and time-to-value is critical — not a universal replacement, but a better fit than Waterfall for the right project profile.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

RAD Phase Plan

A structured four-phase project plan with timebox dates, phase owners, required inputs, deliverables, and exit criteria for Requirements Planning, User Design, Construction, and Cutover.

OutputD-02

JAD Workshop Agenda

A run-of-show document for a Joint Application Development session: pre-work assignments, prototype demo sequence, structured feedback exercises, issue log template, and sign-off block.

OutputD-03

SWAT Team Role Matrix

A team composition grid mapping required roles (facilitator, developer, domain expert, tooling specialist, scribe) to named skills, decision authority levels, and timebox accountability.

OutputD-04

Prototype Review Checklist

A phase-gating checklist that User Design teams run at each prototype iteration: functional coverage questions, edge-case prompts, explicit Approved / Change Required / Deferred decision fields, and carryover issue tracking.

OutputD-05

RAD Suitability Scorecard

A scored assessment comparing your project's characteristics against RAD, Waterfall, and Agile suitability criteria — with a recommendation and rationale for which SDLC approach to adopt.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

James Martin

James Martin (1933–2013) was a British IT consultant and one of the most prolific technology authors of the 20th century, credited with over 100 books on computing, software engineering, and information systems. He spent approximately three decades at IBM as a consultant and researcher before founding his own consultancy. His 1991 book codified the RAD methodology that directly influenced the iterative and agile movements that followed, and he received an honorary Doctor of Science from the University of Salford for his contributions to computing.

Status · Inspired by James Martin’s work — not yet claimed. Are you James Martin?

Primary sourceS-01

Rapid Application Development (1991)

by James Martin

Author of 100+ books on computing; 30-year IBM career; pioneer of Information Engineering and RAD; recipient of honorary computing doctorates.

Read the original ↗

Citationen.wikipedia.org

In the build queue

Be first to run it.

Rapid Application Development (RAD) is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchI'm planning a software project and want to use the RAD framework. Can you assess whether my project is a good RAD candidate and help me set up the four-phase plan with a timebox schedule?