Opus 5 vs Fable 5: I Gave Both the Same Prompt to Build an App

Kristoffer · August 11, 2026 · 17 min read

I gave Opus 5 and Fable 5 the exact same prompt and asked both of them to build the exact same app.

Same features, same design references, same follow-up instructions, and the same amount of help from me. And the results were genuinely surprising. One of them built something that felt like a finished product. The other one needed a lot more hand-holding.

So this is the answer to the question everyone keeps asking: which model is actually better at building complete apps inside Claude Code?

And I'm not testing them with a basic landing page. Both models had to build a full productivity app with tasks, habits, goals, a calendar, focus sessions, analytics, local data persistence, responsive design and a polished interface.

By the end, we put both apps side by side, test every major feature, and score them across design, functionality, intelligence, speed and how much babysitting each model needed.

Every prompt I used is in this post, in full, so you can run the same test yourself.

The app we're building: DayFlow

DayFlow is a personal operating system for managing your entire day from one dashboard.

The home page shows what you need to do today, your current habits, your progress toward larger goals, your upcoming schedule and a quick view of how productive you've been. Users can create and complete tasks, drag tasks between stages, build recurring habits, track streaks, start a focus timer, create long-term goals with milestones, and plan their week through a calendar.

Why this app? Because it hits the three criteria every viral app follows:

  1. It solves a common, frustrating problem. DayFlow solves the feeling of being overwhelmed and disorganized. Instead of juggling separate apps for tasks, habits, goals, focus sessions and planning, you manage your whole day from one dashboard.
  2. It keeps things simple. The core functionality is three words: organize your day.
  3. It's naturally shareable. When someone builds a long habit streak or completes a major goal, they can share that progress. That's social proof and free organic marketing.

Setting up the head-to-head test

I started with two completely empty folders: DayFlow Opus and DayFlow Fable.

Each one gets its own terminal window and its own Claude Code session. In the first terminal I select Opus 5, in the second I select Fable 5. Then I place the windows side by side so I can watch both agents work at roughly the same time.

I'm not counting waiting time caused by me switching windows. I only care about how long each model takes from receiving the prompt to declaring the build complete.

Both folders empty, both sessions ready. Time for the first prompt.

Prompt 1: The build prompt

I made the first prompt intentionally detailed, because I didn't want this comparison to become a lottery where one model gets lucky because the instructions were vague.

This way both models know exactly which product to build, which features matter and what counts as finished - while still leaving enough creative freedom for each model to make its own architectural and design decisions.

Here's the exact prompt that went into both sessions:

Build a complete responsive web app called "DayFlow," a personal productivity operating system.

Use React, TypeScript, Vite, and Tailwind CSS unless you have a strong technical reason to choose an equivalent local-first stack. The app must run locally with a simple npm install and npm run dev. Do not require paid APIs, external databases, authentication providers, or environment variables. Use realistic seeded demo data and persist all user-created or edited data in localStorage.

The product must feel like one coherent app, not a collection of unrelated demo pages.

Required product areas:

1. Onboarding
- A polished first-run onboarding flow.
- Ask the user for their name, primary goal, preferred working hours, typical energy pattern, and the habits they want to build.
- Use those answers to personalize the initial dashboard.
- Onboarding must be skippable and repeatable from settings.

2. Today Dashboard
- Greeting and current date.
- A "Today score" calculated from completed tasks, habits, focus time, and schedule completion.
- Today's tasks with add, edit, complete, delete, priority, category, and due time.
- A compact schedule timeline for the day.
- Current habit streaks.
- Goal progress summary.
- A quick-start focus button.
- Useful empty states and realistic demo data.

3. Task System
- List and board views.
- Statuses: Backlog, Today, In Progress, and Done.
- Drag-and-drop task movement where practical.
- Filters for priority, category, status, and due date.
- Search.
- Task detail modal or panel.
- Completing or moving a task must update analytics and the dashboard.

4. Habit Tracker
- Create habits with frequency, target days, icon, and optional color.
- Mark habits complete for the current day.
- Show current streak, best streak, weekly completion grid, and completion percentage.
- Include a detailed habit view.

5. Goals
- Create long-term goals with target dates, descriptions, categories, and milestones.
- Mark milestones complete.
- Automatically calculate progress from milestones.
- Show active, completed, and paused goals.
- Include at least one visually strong goal-detail screen.

6. Planner
- Weekly calendar or planner view.
- Create, edit, move, and delete time blocks.
- Categories such as deep work, meetings, exercise, personal, and study.
- Provide a clear visual difference between scheduled blocks and tasks.

7. Focus Mode
- Functional Pomodoro-style timer with start, pause, resume, reset, and session-complete states.
- Presets for 25, 45, and 60 minutes.
- Let the user link a focus session to a task or goal.
- Record completed focus sessions in localStorage.
- Include a distraction-free focus screen.

8. Analytics
- Show productivity trends for the last 7 and 30 days.
- Include task completion, habit consistency, focus minutes, goal progress, and the user's most productive day or time.
- Use clean charts that work with seeded local data.
- Analytics must update when the user completes tasks, habits, or focus sessions.

9. Settings
- Light, dark, and system theme.
- Profile and working-hour preferences.
- Reset demo data.
- Restart onboarding.
- Export all local app data as JSON.
- Import previously exported JSON safely.

Design requirements:
- Premium consumer-product design, not a generic enterprise admin dashboard.
- Responsive on desktop, tablet, and mobile.
- Strong hierarchy, excellent spacing, thoughtful empty states, subtle motion, clear feedback, and consistent components.
- Use accessible contrast and keyboard-friendly controls.
- Avoid excessive gradients, random glassmorphism, giant text, or unnecessary visual clutter.
- Create a distinctive visual identity for DayFlow.

Engineering requirements:
- Use reusable components and clean project organization.
- No broken buttons or placeholder interactions for required features.
- Handle invalid form input and empty states.
- Avoid console errors.
- Ensure the app survives refreshes through localStorage.
- Include a README with setup instructions, architecture summary, and a checklist of implemented features.

Work autonomously. First inspect the empty project, create a concise implementation plan, then build the full app. Test the app yourself before declaring completion. Do not stop after creating a mockup or partial prototype. Continue until the required functionality is implemented and the project runs successfully.

I pasted that into Opus first, then the exact same thing into Fable. Same destination, but they can choose completely different routes to get there.

First build: Fable 5

Fable finished first, at almost 47 minutes for the entire build.

Straight away there's an onboarding flow. It asks for all the details it needs to set up the dashboard - I can either pick from the existing options or type my own. It even goes into detail about picking when your day starts and ends, and those are easy to modify. Click "Start my day" and you land on a very detailed dashboard.

The top shows a summary of everything done, plus a small motivational quote, which is a nice touch. Below that are today's tasks and today's schedule. On the right, habits and goal progress as separate blocks - good, because doing habits consistently is how you complete goals.

Going through the sections:

That's a very cool app for an untouched first build. No design pass yet, no manual UI repairs from me.

First build: Opus 5

Opus finished about 15 minutes after Fable.

From first impressions alone, I liked Opus 5's onboarding a lot more - it looks more modern, less like a template React project. Same content as Fable's, because it's the same prompt, but the design is cleaner and smoother.

The dashboard has the same concept with a different structure: the whole top section is an overview, then two columns below it. The first splits into tasks and schedule, the second holds habits, focus and goals in their own boxes. Slightly cleaner than Fable's, in my opinion.

Where things differ:

At this point I'm impressed by both, but you can already see meaningful differences in how each model interpreted the same prompt. Neither one is done, though - because there's one area where AI-generated apps almost always need help.

The UI problem, and why I use Mobbin

Even when an AI model builds all the correct features, the interface often feels generic.

That happens because code models are very good at knowing which components exist, but they don't always know how the best real-world products arrange those components. Without strong references you end up with the same predictable sidebar, the same oversized stat cards and the same random purple gradient that shows up in every AI-generated SaaS app. Which is exactly what both of these apps looked like.

Mobbin is a huge library of real interfaces and complete user flows from successful apps. Instead of telling the model to vaguely "make it look better," you let it research how polished productivity, calendar, habit and wellness apps actually solve the same design problems.

And because Mobbin has an MCP server, both Opus and Fable can use it directly inside Claude Code. The model doesn't need me to manually collect twenty screenshots and explain what matters in each one - it can search for relevant flows, study the patterns, and turn what it learns into a design system it applies to the code.

More importantly for this experiment: both models get access to the exact same design resource. So if one produces a much better redesign, it can't blame the references.

Connecting it is one command in each terminal:

claude mcp add mobbin --scope user --transport http https://api.mobbin.com/mcp

Then restart Claude Code and confirm the install:

/mcp

Select Mobbin, follow the browser authorization steps and log in to your account. Once that's done, Claude Code shows Mobbin as connected - and you don't need to repeat it for the second session, because it connects across all your Claude Code terminals.

Prompt 2: The Mobbin research and redesign prompt

I don't want either model randomly copying one screen. The goal is to use Mobbin the way an actual product designer would: study several relevant products, identify repeated patterns, and create one original visual system for DayFlow.

Same prompt to both models:

Use the Mobbin MCP to research strong, modern product interfaces relevant to DayFlow.

Study multiple real examples across:
- personal productivity dashboards
- task managers
- habit trackers
- goal-setting products
- weekly calendars and day planners
- focus or meditation timers
- consumer analytics and progress screens
- onboarding for productivity or wellness apps
- settings and theme customization

Do not copy one product screen-for-screen. Extract the strongest recurring design patterns and use them to improve DayFlow as an original product.

First, create a file called design-research.md containing:
1. The products or flows you examined.
2. The useful patterns you identified.
3. Patterns you intentionally rejected and why.
4. A complete DayFlow design system: visual direction, colors, typography, spacing scale, corner radii, shadows, icon style, motion principles, chart style, form style, empty states, mobile behavior, and accessibility rules.
5. A page-by-page redesign plan for the existing app.

Then implement the redesign across the entire DayFlow project.

Requirements:
- Preserve and test all existing functionality.
- Do not reduce the number of features.
- Make the interface feel like a premium consumer productivity product rather than a generic admin dashboard.
- Create a distinctive identity that fits the name DayFlow.
- Improve onboarding, dashboard hierarchy, task management, habit tracking, goals, planner, focus mode, analytics, settings, empty states, and mobile responsiveness.
- Use subtle motion and interaction feedback where it improves clarity.
- Avoid blindly mixing patterns from unrelated apps.
- Do not declare completion until the redesign is consistent across every major screen and the project runs without console errors.

This is probably the most interesting stage of the entire comparison. The model has to research, make design judgments, preserve functionality, and refactor a fairly large project without breaking it.

Fable's redesign

Fable finished first again, and the design is clearly different.

The onboarding animations are smoother. The dashboard has a lot of purple - it's everywhere, and honestly I didn't love it. But the separation between elements is much clearer: hovering a row in today's schedule gives you a background highlight, and every section has a white border around it for proper separation.

Then I switched to light mode, which Fable named "Warm paper" - and I liked it immediately. It's light without being bright enough to hurt your eyes, it isn't so purple anymore, and the app feels genuinely more premium. The colors are softer, so they blend with the light theme very well.

Overall: Fable doesn't have the strongest design instinct, but it used Mobbin well to get good inspiration for section separators. If it had made the dark theme as clean and premium as the light theme, I'd have ranked it a lot higher.

Opus's redesign

Pretty similar in structure, but with far less purple, so the dark mode feels more premium.

The thing Fable didn't do: Opus split the left navigation into sections, grouping pages into logical categories. That came directly out of the Mobbin research pass.

Light mode looks great too. The background carries a hint of purple, so it stays true to the app's identity without compromising the theme, where Fable went full beige. Colors are soft in both themes.

Both models handle color and section separation well, but the navigation grouping gives Opus the edge here.

Prompt 3: Making each model QA its own work

This next part is something almost nobody on YouTube teaches, and it matters a lot.

Real startups have a dedicated QA team whose only job is to go through the app before it ships. An app can look fine during testing and still break when lots of people use it at once, on different devices, on different connections.

So I asked both models to act as their own QA team. This prompt isn't allowed to add a new product direction - it only asks each model to test the requirements, identify problems, repair them, and prepare the project for deployment:

Perform a final product, functionality, responsiveness, and code-quality audit of DayFlow.

Use the original build requirements and design-research.md as the source of truth.

Test and verify:
- onboarding, skip, restart, and personalization
- task creation, editing, deletion, completion, filtering, search, board movement, and persistence
- habit creation, daily completion, streaks, weekly grid, detailed view, and persistence
- goal creation, milestone completion, automatic progress, statuses, and persistence
- planner block creation, editing, moving, deletion, categories, and persistence
- focus timer start, pause, resume, reset, presets, linked task or goal, completed-session recording, and persistence
- dashboard updates after user actions
- analytics updates from actual local activity
- light, dark, and system themes
- JSON export and safe import
- desktop, tablet, and mobile layouts
- keyboard accessibility and visible focus states
- empty states, validation, loading or transition feedback
- refresh behavior
- console errors, broken routes, broken buttons, overflow, and obvious visual inconsistencies

Fix every issue you find. Do not remove a required feature to avoid fixing it. Do not replace real interactions with placeholders.

After the audit:
1. Run the relevant build and validation commands.
2. Create audit-report.md listing what you tested, what was broken, what you fixed, and any honest remaining limitations.
3. Update the README with final setup and deployment instructions.
4. Prepare the project for deployment as a static web app, but do not require a specific hosting provider.

Do not declare completion until the production build succeeds.

This stage tests something easy to overlook: whether a model can critically inspect its own work. Some models are excellent at generating new features but terrible at admitting anything is broken. Others will actually run the app, trace the state, and repair problems before you ever see them.

The audit results

Fable finished first and reported 6 bugs - in onboarding, the focus timer, modals, import, sorting and milestones - and said it passed the rest of the tests.

Opus took about 50 minutes, roughly twice as long, and reported 24 bugs fixed.

That could mean one of two things. Either Opus's first build was worse and it had more to repair, or Opus went through its own app far more thoroughly than Fable did. Based on how the final apps behaved, I lean strongly toward the second explanation.

Prompt 4: Turning the prototype into a real product

At this point both versions of DayFlow work, but neither is ready for real users.

There's a big difference between building a prototype and publishing an actual product. Right now both apps rely on seeded placeholder data and browser storage. That's fine for testing, but it means every user's data lives only on their own device. There's no account system, so nobody can sign in securely, reach their data from another device, reset a password, or keep anything after clearing browser storage.

So the last prompt converts the prototype into something that behaves like a real production app - clean accounts, real onboarding, secure auth, cloud data, proper settings, privacy controls and every file needed to deploy:

Prepare DayFlow for real public release. The current app is a local prototype with seeded placeholder data and localStorage. Convert it into a production-ready application while preserving the existing design and functionality.

Use Supabase for authentication and persistent data unless the project already has an equally suitable production backend. Create any required database schema, migrations, policies, environment-variable templates, and setup documentation.

Complete the following work:

1. Authentication and accounts

Add secure email and password account creation.
Add login, logout, forgotten-password, and password-reset flows.
Add email verification where supported.
Keep users signed in securely between sessions.
Protect all private application routes.
Redirect unauthenticated users to the login or registration flow.
Ensure every user can access only their own data.
Add loading, success, validation, and error states to every authentication screen.

2. Replace placeholder data

Remove all seeded tasks, habits, goals, planner blocks, focus sessions, and analytics from real new-user accounts.
New accounts must begin with a clean state.
Keep demo data available only through an explicitly labeled demo mode or development-only seed script.
Do not show fake productivity statistics to real users.
Generate analytics only from the authenticated user's actual activity.

3. Move data into the production database

Replace localStorage as the primary source of truth for authenticated users.
Store profiles, preferences, tasks, habits, habit completions, goals, milestones, planner blocks, focus sessions, and relevant activity records in the database.
Connect every existing create, read, update, delete, filtering, search, completion, and progress feature to the authenticated user's data.
Preserve data correctly across refreshes, browsers, devices, and future sessions.
Add appropriate database relationships, indexes, timestamps, validation, and ownership rules.
Use row-level security or equivalent authorization so users cannot read or modify another user's information.

4. Improve onboarding

Show onboarding only after a user creates an account and has not completed it previously.
Save onboarding answers to the user's profile.
Use those answers to create a personalized but clean starting experience.
Allow users to create their first task, habit, and goal during onboarding instead of inserting fake examples.
Let users skip optional steps.
Allow onboarding to be restarted from settings without deleting existing data unless the user explicitly chooses to reset it.

5. Expand settings

Add complete settings sections for:

Profile name and profile image
Email address and password management
Working hours and preferred start of week
Time zone
Date and time format
Notification preferences
Focus timer defaults
Habit reminder preferences
Light, dark, and system themes
Accessibility preferences
Exporting the user's data
Importing supported data safely
Signing out
Deleting the account and associated data

Require clear confirmation before destructive actions such as resetting data or deleting an account.

6. Production interface states

Add polished empty states for new users who have no tasks, habits, goals, planner blocks, focus sessions, or analytics yet.
Add loading states or skeletons where database requests occur.
Add useful success and error notifications.
Prevent duplicate submissions.
Disable buttons while requests are processing.
Handle offline, failed-request, expired-session, and empty-response states gracefully.
Replace all development text, placeholder labels, fake testimonials, unfinished links, and temporary content.

7. Legal and trust pages

Create publication-ready pages for:

Privacy Policy
Terms of Service
Contact or Support
Account and Data Deletion

Use clearly marked editable placeholders only for information that must be supplied by the app owner, such as company name, support email, governing jurisdiction, and effective date. Do not invent legal or company details.

Add links to these pages in the authentication flow, settings, and website footer where appropriate.

8. Security and reliability

Never expose secret keys in client-side code.
Add a complete .env.example containing every required public environment-variable name with no real credentials.
Validate and sanitize user-controlled inputs.
Review database permissions and authentication redirects.
Remove debug logs and development-only controls from the production build.
Check for exposed personal information, insecure direct-object access, broken authorization, unsafe imports, and accidental cross-user data access.
Add reasonable limits and validation to imported JSON files.
Make account deletion remove or appropriately anonymize all related user data.

9. Files required for publication

Create or update all required project and deployment files, including:

README.md with local setup, backend setup, database setup, environment variables, development commands, production build commands, and deployment instructions
.env.example
Database schema or migration files
Optional development-only seed file
Production build configuration
Hosting configuration where required
.gitignore
Package scripts for development, build, preview, linting, and type-checking
public/favicon.ico or an equivalent favicon
Application icons in the required web sizes
manifest.webmanifest
robots.txt
sitemap.xml
Social-sharing image placeholder
Appropriate page titles, descriptions, Open Graph metadata, and social metadata
A custom 404 page
Error-boundary or fatal-error interface
Privacy Policy, Terms, Support, and Data Deletion pages
PUBLICATION_CHECKLIST.md
DEPLOYMENT.md

10. Progressive Web App readiness

Make DayFlow installable as a Progressive Web App where practical.
Add the web manifest, app name, icons, theme colors, and standalone display configuration.
Ensure the interface works correctly when opened as an installed web app.
Do not add unreliable offline behavior that could cause user data conflicts.

11. Quality checks

Test registration, verification, login, logout, password reset, protected routes, onboarding, profile editing, and account deletion.
Test every task, habit, goal, planner, focus, analytics, import, export, theme, and settings feature using authenticated accounts.
Test with at least two separate accounts and confirm that neither account can access the other account's data.
Test desktop, tablet, and mobile layouts.
Run linting, type-checking, tests where available, and the production build.
Resolve all critical errors, broken routes, console errors, and production-build failures.

12. Publication checklist

Create PUBLICATION_CHECKLIST.md separating:

Tasks completed automatically
Credentials or configuration the owner must provide
Supabase setup steps
Database migration steps
Legal details that still require review
Domain and DNS setup
Email-delivery configuration
Analytics or monitoring setup
Final security checks
Final browser and mobile tests
Exact files and folders that must be uploaded or included in deployment
Exact build-output directory that should be published

Do not claim the application is fully ready for production merely because it builds. Be honest about any remaining limitations, credentials, legal review, external configuration, or manual testing still required.

Do not stop after writing a plan. Implement the changes, create the required files, run the project checks, and confirm that the production build succeeds

Final app: Fable 5

Fable's app now opens on a proper account creation page instead of a dashboard full of demo data. Good start.

I created an account with a name, email and password. It logged me straight into the app - and some of the old demo information briefly appeared while everything loaded, and we never went through onboarding. That shouldn't happen. A brand-new user should never see placeholder data from somebody else's account.

Then a popup appeared telling me to create an account again. I clicked it, and finally got the onboarding flow. After finishing, I landed on a clean dashboard. It worked in the end, but that is not a production-quality first-run experience.

Testing the rest:

Fable did a good job converting the prototype into something much closer to a genuine product. But there are mistakes I'd want cleaned up and obvious features I'd want added before shipping to thousands of users.

Final app: Opus 5

Opus also opens on a proper login and account creation page.

I created a new account, and this time it took me directly into onboarding. No demo dashboard flashing first, no popup asking me to create another account, no confusion about what to do next. Already a much smoother experience.

Onboarding asks for my name, the habits I want to build and my main goal. The design is clean and the progress bar at the top makes it obvious how many steps remain.

Then the dashboard - completely clean, and already using my onboarding answers, because the habits I selected are on the right. I checked every other page first: tasks empty, planner empty, no fake activity in analytics. That's exactly what a new account should look like.

Testing the features:

Back on the dashboard, the Today score had updated based on what I'd just done, and the task, habit and goal information was reflected everywhere immediately.

The scores

Five criteria, ten points each.

Fable 5 - 41/50

Opus 5 - 47/50

Opus 5 wins by 6 points. And I think that's an honest result. Same prompts, better app.

What I'd take away from this

The best coding model isn't the one that writes the most code or gives the longest explanation. It's the one that understands the product, makes good decisions when the prompt leaves room for judgment, holds context across a long build, and gives you something you can actually use.

The other lesson is the Mobbin workflow. Instead of guessing what a premium interface should look like, you give Claude Code access to real product flows, let it research the patterns, and turn those patterns straight into a design system and working code. That step lifted both apps more than any other single prompt in this test.

If you want the full system - going from app idea, to a built MVP, to publishing on the App Store and Google Play, to marketing, to scaling with paid ads, and eventually exiting for $300k+ - it's all inside our community at buildwithai.io, and it's free lifetime access with any Base44 plan. My complete Claude Code setup (the CLAUDE.md, the hooks, the skills) that made this build run so smoothly is in there too.

Now go run the same four prompts yourself and see which model you'd pick.