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

Kristoffer · September 13, 2026 · 27 min read

I gave Opus 5 and Sol 5.6 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. This one is bigger than a normal model comparison, because it is not just model versus model. It is Claude versus OpenAI.

The results were closer than I expected. One of them shipped a finished-feeling product. The other one needed more help from me. Both shipped real bugs.

This is the answer to the question everyone keeps asking: which company's flagship model is actually better at building complete apps?

I am not testing them with a basic landing page. Both models had to build a full personal finance app with transactions, budgets, subscriptions, savings goals, a bill calendar, analytics, local data persistence, responsive design and a polished interface.

By the end, we put both apps side by side, tested every major feature, and scored them across functionality, design, instruction-following, code quality, 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. If you want the Claude-only version of this experiment, I already ran Opus 5 against Fable 5 on a productivity app.

The app we're building: CashFlow

The reference is Spendee - millions of downloads, a Mobile UX award, and write-ups in The Verge, Business Insider and The Wall Street Journal. The pitch is simple: connect your money, see where it actually goes, and get it into shape.

CashFlow is our version of that idea. It is a personal money operating system for managing your entire financial life from one dashboard.

Users should be able to log transactions, set monthly budgets per category, track every subscription they're paying for, create savings goals with milestones, see all their bills on a calendar, and get clean analytics on where their money actually goes.

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

  1. It solves a common, frustrating problem. CashFlow solves not knowing where your money goes. Instead of juggling a banking app, a spreadsheet and a subscription tracker, you manage your whole financial life from one dashboard.
  2. It keeps things simple. The core functionality is three words: track your money.
  3. It's naturally shareable. Hitting a savings goal, cancelling five forgotten subscriptions, or finishing a month under budget is the kind of thing people tell their friends about.

Setting up the head-to-head test

I started with two completely empty folders inside one parent folder called Opus 5 vs Sol 5.6: CashFlow Opus and CashFlow Sol.

Each model gets its own company's official coding agent. No excuses on either side.

I place the windows side by side. I am 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.

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 "CashFlow," a personal finance 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, bank connections, 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, currency, monthly income, top spending categories, current subscriptions, and one savings goal.
- Use those answers to personalize the initial dashboard.
- Onboarding must be skippable and repeatable from settings.

2. Money Dashboard
- Greeting and current date.
- A "Money score" calculated from budget adherence, upcoming bills handled, savings progress, and logging consistency.
- Today's spending with quick-add transaction.
- This month's budget summary per category.
- Upcoming bills in the next 7 days.
- Active subscriptions total per month.
- Savings goal progress.
- Useful empty states and realistic demo data.

3. Transactions
- List view with add, edit, delete, amount, category, account, note, and date.
- Income and expense types.
- Filters for category, account, type, and date range.
- Search.
- Transaction detail modal or panel.
- Adding or editing a transaction must update budgets, analytics, and the dashboard.

4. Budgets
- Create monthly budgets per category with target amounts, icon, and optional color.
- Show spent versus remaining with a progress bar, over-budget warning states, and a monthly rollover indicator.
- Include a detailed budget view with the transactions that count toward it.

5. Savings Goals
- Create goals with target amounts, target dates, descriptions, icons, and milestones.
- Log contributions toward a goal.
- Automatically calculate progress from contributions.
- Show active, completed, and paused goals.
- Include at least one visually strong goal-detail screen.

6. Subscriptions
- Track recurring subscriptions with name, price, billing cycle, category, next billing date, and status.
- Show total monthly and yearly cost.
- Flag unused or duplicate-looking subscriptions.
- Allow cancelling (archiving) a subscription and show how much that saves per year.

7. Bill Calendar
- Monthly calendar view showing bills and subscription charges on their due dates.
- Create, edit, move, and delete bill entries.
- Mark bills as paid.
- Provide a clear visual difference between paid, upcoming, and overdue bills.

8. Analytics
- Show spending trends for the last 7 and 30 days.
- Include spending by category, income versus expenses, budget adherence, subscription cost over time, savings growth, and the user's most expensive day or category.
- Use clean charts that work with seeded local data.
- Analytics must update when the user adds transactions, pays bills, or logs contributions.

9. Settings
- Light, dark, and system theme.
- Profile, currency, and income 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 CashFlow.

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 Sol.

They already behaved completely differently.

Opus stopped and wrote a full plan before touching a single file. It picked its stack, decided to hand-roll its own charts so no charting library could break later, decided on one central app state saved to localStorage, and named its visual identity "ink and mint" before writing a line of UI.

Sol didn't do any of that. It said it would inspect the workspace and then build the product end to end. Within seconds it was already writing package.json, main.tsx and the config files.

One model is planning. The other is sprinting. Same destination, different routes.

First build: Sol 5.6

Sol finished first, at 15 minutes and 8 seconds for the entire app. It said it verified the install, the production build and the dev server before handing it over.

The onboarding copy is a real product line: "Your finances, finally in focus." Three steps. Name, currency and monthly take-home. Then categories with a few already selected. Then subscriptions - and this is the lazy part: a plain comma-separated text box. Then a savings goal. I called mine BuildWithAI Community with a $20 target.

The dashboard greets me by name. Money score: 63 out of 100, labelled "needs focus" instead of a fake high score. Today's spending is $72.40, "comfortably below your typical daily pace." The app is interpreting the number, not just showing it.

Monthly plan with a progress bar per category. Upcoming bills, subscriptions total and savings progress on the right. A "private by design - your data stays here" badge in the corner.

Going through the sections:

Back on the dashboard, the money score drops from 63 to 62 and today's spending is $172. The whole app is wired to one state.

That is a very cool untouched first build. 15 minutes for this is remarkable.

First build: Opus 5

Opus finished at 44 minutes and 30 seconds. Almost three times longer. Then I read what it actually did.

41 source files, around 8,500 lines, one central state. Paying a bill logs the expense and reschedules the recurring copy. Deleting that expense flips the bill back to unpaid. A goal contribution logs a savings transaction. About 500 lines of hand-rolled charts - no charting dependency that can break later.

It verified the app in a headless browser with two test harnesses, 24 checks, and zero console errors. Then it listed three bugs it found and fixed before showing me anything: toasts covering the onboarding continue button, finishing onboarding from settings dumping you back on settings, and seeded demo data with nothing in the next 7 days so the dashboard looked empty.

Nobody asked it to do that. It also flagged two weaknesses of its own: analytics recomputes over about 400 transactions on every change, and there's no keyboard alternative for dragging bills on the calendar.

Onboarding is in a different league. Six steps instead of three, with a live preview of the dashboard as you fill it in. Type a name, pick the owl avatar, and the preview says "Hi, BuildWithAI" with that same owl.

The contrast on that left panel is broken. Light panel, light text. The headline is fine. The description and step list are almost invisible. Opus built a nicer layout and then failed the contrast on it.

Then it starts using the answers. Currency and income get quick-pick amounts. Pick groceries, dining out and transport, and it puts a suggested budget on each chip - $1,200, $800, $600 - calculated from the income you just entered.

Subscriptions are a grid of real services with real prices: Netflix $15.49, Spotify $11.99, iCloud $2.99, plus Notion, Adobe, ChatGPT Plus, Amazon Prime and an add-your-own field. Adding ChatGPT Plus takes the running total from 3 subscriptions at $30 to 4 at $50, live.

Savings goal has presets, a target date, and an optional "why this matters" box.

Step six summarises everything and asks whether you want 3 months of realistic demo data or a completely clean start. Sol never asked that.

I picked demo data. Money score: 83 out of 100, plus 4 versus last month, "strong - biggest lever right now: savings progress." Then it breaks the score into four parts with a plain-English explanation under each one. Sol gave me the number. Opus gave me the recipe.

Today's card has a quick-add field and category shortcuts. This month shows income, expenses, net, budget used and a sparkline. Next 7 days of charges with a checkmark to pay a bill right there. The savings goal says $439.50 a month keeps it on schedule.

I add $100 on dining out. The toast fires. Today jumps to $322. Money score drops from 83 to 81. Budget adherence falls from 32 to 30. Budget used goes from 77% to 81%. The dining out bar moves. One click.

Where things differ:

Sol optimised for speed and shipped a genuinely good app in a quarter of the time. Opus optimised for depth, tested itself, and shipped an app that explains its own numbers.

Neither one is done. AI-generated apps almost always need help with the UI.

The UI problem, and why I use Mobbin

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

Code models know which components exist. They don't always know how the best real-world products arrange those components. Without strong references you get the same 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 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 finance, budgeting and banking apps actually solve the same design problems.

Because Mobbin has an MCP, both models can use it inside their own coding agents. The model doesn't need twenty screenshots from me. It can search for relevant flows, study the patterns, and turn what it learns into a design system.

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

Connecting it should be straightforward.

In Claude Code:

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

Opus already had it connected from earlier. It ran its own check, confirmed Mobbin was added, and listed the three tools it now has: search flows, search screens and search sections.

Codex uses a different command. It hit a real Windows error: PowerShell blocked the codex.ps1 launcher because of the machine's execution policy. Sol diagnosed that itself, switched to the .cmd launcher, reran the same command, started OAuth and confirmed it was logged in.

Even connecting the same tool went differently. Opus double-checked a working setup. Sol hit a genuine environment error and fixed it without me touching anything.

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 CashFlow.

Same prompt to both models:

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

Study multiple real examples across:
- personal finance dashboards
- budgeting apps
- banking apps
- subscription trackers
- savings and goal-setting products
- bill and calendar views
- consumer analytics and progress screens
- onboarding for finance apps
- settings and theme customization

Do not copy one product screen-for-screen. Extract the strongest recurring design patterns and use them to improve CashFlow 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 CashFlow 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 CashFlow project.

Requirements:
- Preserve and test all existing functionality.
- Do not reduce the number of features.
- Make the interface feel like a premium consumer finance product rather than a generic admin dashboard.
- Create a distinctive identity that fits the name CashFlow.
- Improve onboarding, dashboard hierarchy, transactions, budgets, savings goals, subscriptions, bill calendar, 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 the most interesting stage. Each model has to research, make design judgments, preserve functionality, and refactor a fairly large project without breaking it.

Sol's redesign

Sol finished first again. It named the new visual identity "quiet current" - the same instinct Opus had when it picked "ink and mint" before writing UI.

The app now opens in light mode by default: a warm cream background. The only dark element on the first screen is the monthly cash flow hero card, a moody green-to-black gradient with a mint accent.

Flip it to dark and that's the version that turns heads. Deep, almost-black forest green with mint and sage carried through everywhere. It leans into crypto-exchange territory. It's a lot more intense than you'd expect from a personal budgeting app. Hover highlights on transaction rows are there.

Then the "one original visual system" promise falls apart. The analytics page uses four completely different chart palettes on one screen: a green spending line, green-and-orange category bars, gray-and-tan budget bars, and a purple lavender area chart. None of those share a language with each other, let alone with the mint-and-forest identity everywhere else.

Sol found one genuinely striking direction. It never applied it consistently. The light mode that greets every new user is comparatively plain, and the charts look like nobody went back to touch them.

Opus's redesign

Opus lists exactly what it changed: the dashboard now opens by telling you what's safe to spend today, transactions became one continuous ledger with sticky day headers and removable filter chips, and budgets show plain-English pace projections. It added a command palette, a mobile quick-capture button and animated chart drawings. 68 of 68 of its own functional checks passed, with a clean type check and a clean build.

It feels different immediately. Calmer. Softer. Both modes are actually labelled: Light - Warm paper, and Dark - Deep water. The dark version reads as muted deep teal, not a trading terminal.

The sidebar is now grouped into labelled sections: Overview for dashboard and analytics, Plan for budgets, savings goals, subscriptions and the bill calendar, and Track for transactions. Sol never did that.

Every category keeps the same colour everywhere it appears. Groceries is always green. Dining out is always red. Shopping is always pink. Entertainment is always purple - on the donut, on the budget icons, everywhere. That's the one visual system Sol promised and didn't deliver.

Light mode looks finished. The colours are soft enough to work in both themes.

Sol's dark mode is arguably the most striking single screen in the whole video. Opus built an actual system.

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, 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 CashFlow.

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

Test and verify:
- onboarding, skip, restart, and personalization
- transaction creation, editing, deletion, filtering, search, and persistence
- budget creation, spent-versus-remaining accuracy, over-budget states, detailed view, and persistence
- savings goal creation, contribution logging, automatic progress, statuses, and persistence
- subscription creation, editing, archiving, totals, and persistence
- bill calendar creation, editing, moving, deletion, paid and overdue states, 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.

The audit results

Sol finished first, in 24 minutes and 24 seconds. It didn't just give a bug count. It gave a full audit report: CashFlow passed and is ready for static deployment. It fixed dashboard and budget calculation inconsistencies, a bug where deleting a bill-linked payment didn't reset the linked bill or goal, stronger JSON and date import validation, safer onboarding restarts, better empty states, chart summaries, modal behaviour and mobile navigation accessibility. It replaced decorative dashboard activity with real transaction data, split an oversized production bundle, and resolved every dependency vulnerability npm could find. Its own audit tests passed. Smoke tests passed. npm audit came back with zero vulnerabilities. The production build passed with no bundle-size warnings.

Opus went another level deeper. Production build succeeds, clean type check, 415KB bundle. It found and fixed 19 defects: 12 correctness issues and 7 around console errors, responsiveness, accessibility and design-system consistency. It ran a 37-assertion verification suite with zero failures. It flagged two places where its earlier claims weren't quite accurate and corrected them. Then it documented eight things it did not fix - honest remaining limitations, like charts that can't be scrubbed with a keyboard, and the fact that it never shipped an actual automated test suite.

Sol gave me a clean pass with eight categories of fixes and a fully green test suite. Opus gave me 19 specific defects, a much larger self-written verification suite, and then volunteered eight more things it knows are still wrong. Neither model hid anything. Opus went digging a lot deeper.

Prompt 4: Turning the prototype into a real product

At this point both versions of CashFlow 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.

For a finance app specifically, that's a dealbreaker. Nobody trusts a money app that can lose their data.

So the last prompt converts the prototype into something that behaves like a real production app:

Prepare CashFlow 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 transactions, budgets, subscriptions, bills, goals, 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 financial 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, transactions, budgets, subscriptions, bills, savings goals, contributions, and relevant activity records in the database.
Connect every existing create, read, update, delete, filtering, search, 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 budget, subscription, and savings 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
Currency, income, and start-of-month preferences
Time zone
Date, time, and number format
Notification preferences
Bill 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 transactions, budgets, subscriptions, bills, goals, 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 CashFlow 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 transaction, budget, subscription, bill, goal, 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

Sol reported 25 minutes and 56 seconds. It listed its passing quality and build checks, then said flat out: this is not yet approved for public release, because the live Supabase connection and real email flows still need to be verified with an actual account.

Opus took 37 minutes and 25 seconds and said almost the same thing in different words: this is not verified for production until the live database, row-level security and email flow have actually been tested end to end.

Both models did the responsible thing. They built the production version. They did not pretend it was already proven safe.

Final app: Sol 5.6

Before I even sign up, the marketing landing page is doing real work. "See where your money is going and choose what happens next." Feature cards for your data, separated, no invented insights, and portable by design. That's proper landing-page copy.

The signup form only asks for email, password and confirm password. No name field. That name is going to have to come from somewhere else.

The account is created and it does not skip onboarding. It drops me into a three-step wizard: name, currency and monthly income; which categories matter, with an optional first subscription; then the dashboard.

Here's the first real bug. The dashboard greets me with "Good morning," and a dangling comma with nothing after it. I typed BuildWithAI two screens ago. My name didn't make it into the account. Settings: name field empty, monthly income showing zero. Currency did save. A validation message blocks the save button until I retype my name. I do that, hit save, and the greeting works. The income field stays stuck at zero no matter what I do.

Restart onboarding exists and keeps your existing data. Reset data, delete account, and export/import JSON are there.

Before adding anything I go through budgets, the bill calendar and analytics. All genuinely empty. No leftover fake data.

Then I test it:

By the end, the money score has climbed from nothing to 82.

Sol did convert the prototype into something that behaves like a real product. The onboarding, the live recalculations and the empty states are all there. But two data-integrity bugs genuinely matter for a finance app: your name and income can silently fail to save from onboarding, and the transaction form lets you create a category-and-type mismatch without any warning.

Final app: Opus 5

The signup screen is a split layout. Real marketing copy on the left: "Know exactly what is safe to spend," with feature bullets about transactions, budgets and bills updating each other, and exporting a full JSON backup or CSV. Then, in the footer of that same panel: "Copyright 2026 Company Name. All rights reserved." An actual unreplaced placeholder. Sol's equivalent footer correctly said CashFlow.

The signup form asks for my name here. The password field has a live strength meter that moves from too short to weak to good to strong. Sol's form never showed that.

The account is created and it goes straight into a proper seven-step onboarding wizard with a live preview panel. Step one is name and avatar. Step two is currency and monthly income, with a reassurance: nothing is logged as income from this figure, it only sizes suggestions. Step three is priorities. Step four is a first budget. Step five is subscriptions with a grid of real services. Step six is a savings goal. Step seven reviews everything back.

I click through steps three to six without filling them in. The review screen honestly tells me no budgets, no subscriptions, no savings goal, and an empty ledger. The wizard is better designed, but I still have to do the same setup work afterward.

Where Opus pulls ahead: my name and income actually stuck. The dashboard greets me as "Good morning, BuildWithAI." Settings shows the $10 monthly income I entered. The exact onboarding-to-account handoff that broke for Sol works here.

The dashboard is clean but genuinely empty. Safe to spend today. Money score at 55 out of 100, labelled steady, broken into budget adherence, bills handled, savings progress and logging consistency, each with a plain-English explanation for why it's low.

One odd thing: that safe-to-spend-today number changes every time I come back to the screen. I've seen four different values across a few visits.

Settings has a lot: profile, money, account, appearance with themes literally labelled Light - Warm paper and Dark - Deep water, region and format, notifications, bill reminders, accessibility, data export and import, and account deletion. Tucked into notifications is a line that should never have shipped to an end user: "Scheduled email delivery is not switched on in this deployment. See DEPLOYMENT.md for how the owner enables it." That's an internal deployment note leaking into the customer-facing settings page.

I add a $20 expense under Other and a $100 income labelled freelance. Both update immediately. Money score nudges from 55 to 57.

The date field shows 10/9/2026 for today, September 10th. Settings says this account uses a month-first date format, which would make that string October 9th. Opus's own date field contradicts its own settings.

I create a groceries budget at $500. The money score jumps to 74, now labelled strong, with budget adherence maxed at 35 out of 35. The dashboard banner flips from a nudge to add something to a calm green "nothing needs you right now."

I never get to subscriptions or the savings goal in this walkthrough. Both stay empty.

Opus's onboarding is the more thoughtfully designed of the two, and it's the one where my actual answers landed in the account. No dangling greeting. No income stuck at zero. But it ships its own rough edges: a leftover company-name placeholder on signup, an internal deployment note in settings, a self-contradicting date format, and a dashboard number that doesn't agree with itself between visits.

Sol had the messier onboarding handoff, but a cleaner footer. Neither model handed me something I'd ship completely as-is.

The scores

Five criteria, ten points each.

Sol 5.6 - 37/50

Opus 5 - 38/50

Opus 5 wins by 1 point. 38 to 37.

That is a far closer race than I expected. Both models shipped genuinely functional apps with genuinely real bugs. Sol's issues were more about data actually surviving the trip from onboarding into your account. Opus's were more about polish details slipping through its own audit.

If I'm being fully honest, this one came down to which set of bugs I personally find scarier in a finance app. Silent data loss edges out a leftover placeholder string for me. It was close enough that I wouldn't push back hard on anyone who scored it the other way.

What I'd take away from this

The best coding model isn't the one that writes the most code or finishes first. 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.

Sol 5.6 is seriously fast and seriously capable. If you want a working app in 15 minutes, it will get you there. Opus 5 is slower, more thorough, and more willing to tell you what it still got wrong.

The other lesson is the Mobbin workflow. Instead of guessing what a premium interface should look like, you give the coding agent 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, to marketing - it's all inside our community at buildwithai.io.

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