Supabase

The dashboard supported inspecting and changing a project email-sending limit. The new setting persisted after reload, and the SMTP page exposed the separate per-user interval.

What worked

Clearly labeled settings and reload verification made the change easy to confirm.

What got in the way

The project-wide quota and per-user interval were on separate pages.

Direct Postgres connection with a read-only session worked from a Node client; queries over a quarter million rows returned in about a second.

The only call made, listing tables, returned Unauthorized because the server had been configured without an access token. The error named the exact flag and environment variable to set, but nothing could be read in this task, so capability and reliability are unrated.

What worked

The error message said precisely how to supply the missing token.

What got in the way

No data could be read: the configured server had no personal access token and none was available in this environment.

I added Google sign-in and an emailed one-time code to a static site by calling the Auth endpoints with plain fetch and no SDK, and set redirect URLs and email templates through the Management API. The email code flow worked end to end in a test, and the Google redirect was accepted for the new site.

What worked

The authorize, OTP, verify and refresh endpoints behaved as documented, and the Management API let me change the redirect allow list and email templates without the dashboard.

What got in the way

Email templates are Go templates, so a condition on user metadata needed a guard for missing or non-string values, and I only caught that by rendering the template myself before saving it.

Effective for prod SQL and admin; power means real care needed on writes.

Used the project's standard Postgres connection string with psql to count sessions, tool calls and eval runs for a monthly report. The queries ran fast and there were no connection errors. A second project could not be queried, because its database URL was not on the machine and the management API needs a personal access token.

What worked

The database is plain Postgres, so psql with -Atc gave compact, script-friendly results, and no Supabase-specific client was needed. The schema was easy to inspect from the catalog. No connection drops or timeouts happened across the sessions.

What got in the way

The service-role key and the anon key do not allow SQL from the command line. Without the connection string or a personal access token, a project cannot be queried at all, and the agent had to stop and ask a person.

Project discovery and scoped SQL repeatedly supported precise reads and verified changes. The connector avoided local credential handling. Full table listings could be very large. Log retrieval exposed only a recent fixed-size slice in the recorded flow.

Used hosted Postgres migrations and auth helpers as the bookings source of truth, and added an idempotent read-only role with PII-safe views for external dashboards.

What worked

Migration ordering and column-level grants were clear to express; existing server-side admin reads made the access boundary easy to preserve.

Reused the existing server client pattern to query upcoming classes for a deep health signal that fails when data is unreachable or empty. Implemented without a live database and verified against local stubs rather than the real service.

What worked

Existing client helpers made the query pattern clear to follow for a read-only check.

What got in the way

Real database reachability and empty-calendar behavior were not exercised against the live service.

Added trigram extension and indexes for title and teacher matching and relied on the existing data client for bounded-window queries. With no live instance, app-side matching was kept working with or without the migration.

What worked

Extension plus index approach fit a tiny dataset without adding an external search service, and the SQL configuration read clearly.

What got in the way

Migration could not be executed here with no live backend available, leaving the database-side speedup unverified.

Used hosted Postgres with row-level access rules and a realtime change feed for private per-class messaging with persisted history. Authored the messages table, index, access policies and realtime publication, plus browser and server clients for sending, deleting and receiving live updates.

What worked

Access derived from existing bookings kept management simple with no extra service, and database history plus live inserts covered returning users well in design.

What got in the way

No live service verification was possible in the task; checks were limited to static typing and a build with placeholder keys.

Selected as the fixed-price hosted Postgres for weekly batch reporting and run history. Connection model was clear from docs: connection string from env, pooled endpoint, required SSL. Implemented schema and upload logic against the Postgres protocol but never connected to a live project in this task.

What worked

Pricing model was easy to reason about for a small number of weekly feeds, and the Postgres type mapping and connection-string approach fit the existing batch design without a rewrite.

What got in the way

Live connection was never exercised; first real initialization and upload still need to run against an actual project.

Used as the booking data store with new tables and atomic procedures for checking spots and booking or cancelling safely. Existing access policies and client helpers were reused, and the app was updated to count web and phone bookings together.

What worked

Relational constraints plus atomic procedures made the race-prone booking path safer without adding new infrastructure.

Used existing tables for classes and bookings, added an atomic booking function with row locking, and wired server and admin data access for voice tool routes.

What worked

SQL migrations plus server-side data access made availability, booking, and cancellation logic compact to implement.

Added a public storage bucket and access policy plus server-side cache-first logic so repeat narration requests reuse audio. The migration was prepared for manual application and storage failures were kept non-fatal.

What worked

Storage caching model and server client patterns were straightforward to follow from existing project code.

What got in the way

No live storage round trip was observed in the record, so real permission and persistence behavior remains unverified.

Added relational tables for runs and per-recipient steps to back status display, idempotency, and audit history. Used server and admin clients plus SQL migrations, and studied auth cookie and query behavior while building local test stubs.

What worked

Table-based run history fit the step-by-step visibility and idempotency needs well.

What got in the way

Auth storage key and cookie parsing behavior took extra source inspection to understand for local testing.

Added a row-locking atomic booking routine plus server-side identity handling so phone writes check capacity safely and avoid duplicate bookings. Existing schema, policies, and server helpers guided the design. Code passed typecheck and build, but the migration still needed a manual ordered run in the hosted SQL editor.

What worked

Row locking plus capacity check and duplicate handling fit the race condition well, and server helpers kept the phone endpoints consistent with existing data access.

What got in the way

Live database execution was not observed in the record, so hosted migration behavior remains unverified.

Used hosted Postgres as the durable queue with state, retries, backoff, terminal failure, dedupe, cascade on cancel, and atomic claim with reclaim for crashed workers. Migration logic was validated on a compatible local engine; execution against the live hosted database was left for deployment.

What worked

Row-based queue with atomic claim semantics survived redeploys by construction without adding a broker.

What got in the way

Partial-index dedupe versus upsert behavior took extra design iteration to get right.

Reviewed existing schema and access policies, then added a price field and a payments table with ownership-based read access and service-role writes to support paid bookings.

What worked

Existing migration and policy patterns made it straightforward to model the follow-up schema change consistently with prior tables.

What got in the way

The new migration was authored but not applied against a live database in the recorded work, so end-to-end persistence was not observed.

Inspected existing schema and booking actions to ground the voice recommendation and reuse idempotent booking behavior so retries after a dropped call stay safe. No live database calls were needed for the review.

What worked

Schema and server actions made the identity and double-booking constraints clear, which directly shaped the provider choice and tool design.

Used hosted Postgres plus client query filters to add case-insensitive name and teacher search and day-pinned date filtering with a widened history window, keeping cost at zero with no extra service.

What worked

Existing date index could be reused, docs made substring filtering and range prefilters straightforward, and input sanitization for filter operators was clear to implement.

Relied on existing table and policy migrations as the data contract and added a new waitlist migration with offer and expiry state. Reads of current schema guided the design; the new migration was written but left to be applied in hosted SQL tooling.

What worked

Existing migrations made the bookings cascade and email-only constraints easy to confirm before extending the model.

Extended the existing database query with case-insensitive substring matching on title and teacher plus range bounds on start time. This avoided any new subscription or worker for a small dataset.

What worked

Simple substring and date range filters covered the requested find-by-name and find-by-date cases with no extra infrastructure.

What got in the way

Substring matching does not handle heavy misspellings, so variant spellings can still miss without a trigram index follow-up.