The client dashboard fetches Prisma data before Stripe data because the second query needs the first result

The portal dashboard at app/portal/page.tsx runs two queries in sequence, not in parallel. First it calls getClientDashboard with the Clerk user ID, which returns the client record with active projects, milestones, the latest session, and the next upcoming booking — all from Prisma in one nested include. Then it passes client.stripeCustomerId to getClientInvoices, which calls the Stripe API to list PaymentIntents for that customer. The two queries cannot run in parallel because the Stripe query needs a customer ID that only exists after the Prisma query returns. The admin dashboard at portal/admin/page.tsx does not have this constraint — its six queries are all Prisma calls against different tables, so they run inside a single Promise.all. The client dashboard crosses two data sources where the second depends on the first. Once both queries resolve, the page derives four different views from the combined result: active projects from client.projects, the next booking from client.bookings at index zero, the latest session note via flatMap across all projects picking the first item, and the most recent three invoices sliced from the Stripe response. Four widgets, two data sources, one sequential waterfall that exists because Stripe needs a customer ID and only Prisma knows it.