Imagine this:
It’s Monday morning. A stakeholder brings you a promising product idea—clear use case, high impact, minimal complexity.
By Wednesday afternoon, they’re using a working web app with real data, live logic, and a clickable UI. This working app was implemented by just one developer.
That’s a URP: an Ultra-Rapid Prototype—and it's changing how we deliver value in software teams.
What’s a URP?
A URP is a web-based prototype built in 1–2 days, powered by LLMs and structured context engineering workflows.
It’s not a sketch. It’s not a Figma mockup.
It’s a functioning app:
Frontend UI
Backend logic
Database (if needed)
Deployed and demo-ready
You don’t build it line by line. You design the context, and the LLM builds with you.
Why URPs Work: Four Enablers
URPs are only possible because of a few fundamental shifts in how software is created.
1. Context Engineering Gives LLMs Memory and Intent
Modern LLMs like Claude Code are capable of writing real code, but only when you guide them with precision. That’s where context engineering comes in.
By structuring prompts into .md files that define:
The goal
The tech stack
The architectural pattern
UI conventions
Output formatting
Naming rules
Security constraints
...you’re not prompting. You’re programming.
Context files turn Claude from a chatbot into a silent pair programmer who understands the project before writing a line.
2. Prompt-Based Code Scaffolding Reduces Boilerplate
URPs don’t start from scratch.
They start from reusable context templates:
project.md– describes what we’re buildingcomponents.md– defines common UI patternsflows.md– outlines user journeys and API endpointsexamples.md– shows good inputs and good outputs
These templates make LLM output fast, predictable, and aligned. You’re not prompting from a blank page, you’re feeding context into a machine that knows how you like to build.
3. You Work in Hours, Not Weeks
The magic of a URP isn’t just speed, it’s feedback velocity.
In two days:
You validate a user journey
You test the logic against real data
You uncover blockers early
You show stakeholders what’s possible, not just proposed
Compare that to a typical MVP cycle:
→ Weeks of planning
→ Days of backlog grooming
→ Sprints for delivery
→ One rushed demo
→ Surprise misalignment
URPs flip that on its head.
4. One Senior Engineer Can Do the Work of a Team
Traditional prototypes often require a team: frontend, backend, maybe DevOps, and a product manager or two.
URPs don’t.
With well-engineered context, a single senior engineer can orchestrate everything:
Architect the flow
Scaffold the code
Direct Claude with precision
Review and deploy the result
The result?
Lower financial cost
Zero resourcing dependencies
Minimal opportunity cost to the broader team
It’s not just faster, it’s leaner.
Case Studies (Anonymised but Real)
Here are a few real URP outcomes from recent projects:
Incident Escalation Tool
A prototype app for frontline responders to flag and track safety incidents. Built and deployed in 36 hours. Led to a funding proposal 3 days later.Pricing Override Workflow
URP created to test a revised pricing logic in an enterprise sales platform. Stakeholders used it in a meeting before JIRA tickets were even written.Mental Health Check-In App
A lightweight tool for staff to report wellbeing. Built over a weekend. Went live in internal pilot the following week.
All three shared the same trait: speed enabled clarity. The prototype showed what words couldn’t explain.
What URPs Don’t Replace
Let’s be clear: URPs are not production-ready. They are not a shortcut to long-term system design.
URPs do not replace:
Secure authentication flows
Compliance-ready data storage
Scalable infra and CI/CD
QA and test coverage for edge cases
But they are perfect for:
Product discovery
Technical validation
Early stakeholder buy-in
"Is this even worth building?" tests
They're what you'd build if you could remove every organisational bottleneck for 48 hours.
Final Thought: Speed is a Strategy
A URP isn’t just a fast build. It’s a new way of working.
It shows your team, your org, and your clients what’s possible now, not six sprints from now.
The secret isn’t just the LLM. It’s the system you wrap around it: context engineering, prompt reuse, and a willingness to ship fast and talk sooner.
So, back to the question:
What would you build if it only took two days?
Want to see what a context stack for a URP looks like?
Reply with show-me-a-stack.md and I’ll send you the blueprint.
