Is there a way to see all my service costs in one place?

Not by default. Each vendor bills separately, so the options are a spreadsheet you maintain, a card statement you read carefully, or routing usage through a single gateway such as Squiid that meters every service against one prepaid balance and shows them in one dashboard.

Should I still keep the vendor dashboards?

Yes. Vendor consoles are better than any aggregator at their own service: SQL editors, build logs, DNS record checks and deliverability reports all belong there. A single view is for spend, call volume and alerts, which is what you check weekly.

What is the fastest improvement I can make today?

Write a RUNBOOK.md in the repository that lists, for each likely failure, which console answers it and which account owns that console. It takes fifteen minutes and turns a twenty minute diagnosis into a two minute one.

Why does one small app mean logging into six dashboards?

July 28, 2026 · The Squiid team · 5 min read

Short answer: because every service you added is a separate product with a separate console, and nothing in the stack was designed to give you a combined view. Each vendor builds the best dashboard for its own service. Nobody builds the dashboard for your app, so that job is yours, and by default you do it by opening six tabs.

This is easy to dismiss as a minor annoyance. It is not, because it changes how you behave. When answering a question costs six logins, you stop asking the question. People stop checking spend until the card is declined, stop checking email deliverability until a user complains, and stop checking error rates entirely.

Count them honestly

For a typical AI-coded app that is live and has real users:

Hosting console for deploys, build logs, environment variables and bandwidth.
Database console for tables, SQL, row counts, connection limits and backups.
Auth console for users, sessions and sign-in providers, unless your database bundles it.
Email console for delivery, bounces, complaints and domain records.
Model provider console for token spend and rate limits.
Monitoring or analytics console for errors and traffic.

Six, and that is before payments, SMS, object storage or a status page. Each has its own login, its own idea of what a "project" is, its own notification settings and its own billing page in a different place from its usage page.

Why it is structurally six and not one

Three reasons, and none of them are going away.

First, the unbundling was deliberate and mostly good. Specialised services are better than the all-in-one platforms they replaced. A dedicated email API has better deliverability than a hosting provider's afterthought mailer. You are paying a coordination cost for real quality.

Second, agents accelerated the unbundling. Wiring up a new service used to take an afternoon of reading docs, which was a natural brake. Now it takes one prompt, so the number of services per app went up without the coordination cost going down.

Third, nobody is incentivised to build the combined view. Every vendor wants you in their console, looking at their metrics and their upsell. A cross-vendor dashboard is a product only a neutral party can build.

What it actually costs you

Slow incidents. When users report that sign-in is broken, the cause could be the host, the database, the auth provider or the email service. Six consoles means six checks, in sequence, while people are waiting. The fix is usually two minutes; the diagnosis is twenty.

Invisible spend. Costs live in six billing pages with six cycles. Nothing tells you that this month is triple last month until the charges land. By the time you can see the number, it has already happened.

Drift. An environment variable gets changed in the hosting console and not in the local .env. A key gets rotated in one place and not in the preview environment. Every dashboard is a place state can diverge from every other place.

You cannot hand it over. Six consoles tied to your personal logins means nobody else can help, and a handover means a password reset marathon. This is the point where a side project stops being able to become anything else.

And then it is not six, it is twelve

The count doubles the moment you take staging seriously. Preview deployments need their own database, their own email sending domain so test messages never reach real users, and their own API keys so a broken branch cannot write to production data. Every console now has a production view and a staging view, and the two drift, because you fix something in production at midnight and do not mirror it.

Most small projects handle this by not having a staging environment at all, which works right up until the first destructive migration. A reasonable middle path for a one person project: production and preview only, with the preview environment pointed at a branched or seeded copy of the database and at a sandbox mode for anything that sends messages or takes money. Write down which variables differ between the two. That short list, four or five lines, prevents most of the accidents where a test run emails two thousand real users.

The incident test

Here is a useful exercise, and it takes ten minutes. Pretend a user says "I signed up an hour ago and never got the email." Write down, in order, exactly what you would check and in which console. Most people discover two things: they do not know which console owns the answer, and at least one credential is not in their password manager.

Then write that sequence into a file in the repository called RUNBOOK.md. Ask your coding agent to keep it current when it adds a service. It is the single highest value document in a small project and almost nobody has one.

Making six dashboards manageable

One identity for all of them. One email address, one password manager, no "sign in with GitHub" for some and a password for others. Future you, locked out at midnight, will be grateful.
One environment file as the source of truth. Keep .env.example in the repository with every variable name and a comment saying which service it belongs to. The values live in the host and your password manager, never in the repo.
Turn on the alerts you actually want. Budget alerts, error rate alerts and bounce rate alerts, all routed to one inbox. The default in most consoles is either nothing or everything.
Write down which console owns which question. Two columns, ten rows, in the runbook.
Review quarterly. Open all six, note the plan and the monthly cost, and cancel what nothing depends on.

What a single view can and cannot replace

This is the other half of what Squiid is for. When every service is reached through one gateway with one key, spend and call volume for all of them land in one dashboard, on one credit balance, with one set of alerts at 75, 90 and 100 percent of your budget. You get one invoice instead of six and one place to see that the app made 40,000 calls this month, of which the model API was most of the money.

It is worth being precise about what that does not do. It does not replace the database console when you need to write SQL, or the hosting console when a build fails, or the email console when you are debugging a DKIM record. Vendor consoles are better at their own service than any aggregator will be. What the single view replaces is the six logins you do just to answer "what is this costing and is anything on fire", which is the question you ask every week, rather than the deep console work you do once a month.