Pivot Proposals

Good developers undersell themselves, and it's structural. They spend their days inside the code, not inside the sales process. So the quote gets typed into an email, the rate is whatever felt fair last time, and nobody writes down what happens when the scope moves. The work that wins the work is the part most engineers like least.

We built Pivot Proposals because we kept hitting this ourselves. Every engagement the studio takes starts with a proposal, and writing each one by hand was eating real time. So we made the tool we wanted: describe a project in plain language, pick the stack, and it drafts a full proposal, an executive summary, a scope with the out-of-scope items spelled out, a timeline, the technical approach, a priced breakdown, and terms. You read it, refine it, and send it.

It turned out other developers wanted the same thing. It runs as a real product now, free to start with a Pro tier for the deeper analysis and unlimited proposals. The architecture is the same one we'd use for any product we ship.

Pivot Proposals is a Next.js app on Vercel, with Clerk for auth and Supabase Postgres for data. Every table sits behind row-level security and is reached through a server-side admin client, so the browser never touches the database directly. Proposals, usage, subscriptions, edit history, and clients each have their own table; a proposal's content and analysis are stored as JSON so the document can grow without a migration.

The generation is the heart of it. We drive a large language model through the Vercel AI SDK and ask for structured output validated against a schema, so a proposal always comes back with every section present and correctly shaped. The request retries with backoff if the model times out or returns something incomplete, progress streams to the browser while it works, and the finished proposal is saved on the server, so a closed tab never costs you a generation. The prompt itself is where the studio's proposal craft lives: lead with business outcomes over technical detail, tie every feature to why it matters, and always name what's out of scope. Section-level editing runs in two phases, the model plans the edit, then applies it, so a single request can update several linked sections at once.

Around that sit the unglamorous parts that make it a product: serverless PDF rendering with a headless browser, Razorpay subscriptions with idempotent webhooks and a real state machine, transactional email with a daily engagement cron, and product analytics, error monitoring, and web-vitals tracking wired in from day one.