Case 01 — Ciela

Ciela — AI-Powered LinkedIn Post Generator

The Problem

Adhiraj came to me with an idea, not a spec. He wanted a tool that generates high-conversion LinkedIn posts using AI: text via OpenAI, visuals via Midjourney. But the product itself was undefined. There was no clear feature set, no user flow, and no priorities. Only a direction.

That is a common situation with early-stage clients, and a risky one. An unclear brief plus a hard 4-week deadline is how projects die. So the real problem was never just "build a LinkedIn post generator." It was: turn a loose idea into a shippable product definition, then ship it, in four weeks.

My Approach

In this kind of project, writing code is not the first thing to do. With four weeks on the clock, the temptation is to start building immediately, but building against a vague brief means building the wrong thing fast. So the first days went into discovery sessions with Adhiraj. In those calls I asked him to walk me through who the user was, what a "high-conversion post" meant to him, and what he would demo to a potential customer on day one. His answers gave us a shared picture of the product and, just as importantly, a long list of things the first version did not need.

Once we agreed on what the MVP actually was, I turned that agreement into structure. I broke the project into three milestones, each with a fixed deadline and written acceptance criteria that Adhiraj agreed on. This protected both of us. He always knew exactly what he would receive and when, and I had a defense against scope creep: whenever a new feature idea came up mid-project (and they came up often), we simply re-opened that milestone's deadline and pricing. Most ideas quietly moved to the post-MVP list once they had a cost attached.

With the scope contained, the technology choices followed the same principle: keep it simple and resist over-engineering. Next.js full-stack meant one codebase and one deployment target on Vercel. Supabase covered auth and the database. Stripe handled payments, Resend handled email, Upstash handled rate limiting. Every piece was chosen because it was the fastest proven path to a working product, not the most impressive one. I did not want to spend any of the four weeks fighting infrastructure, and I mostly didn't have to.

Challenges

Midway through development, before the product was even published, we got an unplanned security audit.

I was heading into mandatory military service, so I had told Adhiraj early on that he would need to hire someone else for post-MVP development. One of the applicants for that role decided to pen-test the unpublished project, and he found real problems. A misconfigured Row Level Security policy in Supabase let him list the test user emails directly from the database. Worse, he could directly invoke an RPC function that upgraded a user to the pro tier, bypassing the backend business logic entirely. Free pro accounts for anyone who found it.

Uncomfortable? Yes. But the timing was ideal: a real attacker's perspective before a single real user existed. I treated it as a free audit, went through every RLS policy in the database, and closed the privilege-escalation path so the RPC could no longer be invoked with the public anon key. He had not even needed the app to exploit it; a direct call from Postman with the publishable key was enough.

Digging into that exploit exposed a second, quieter weakness in the same area: the subscription flow was not idempotent. Stripe delivers webhooks with at-least-once semantics, which means the same event can arrive twice, and a user retrying a failed checkout can generate duplicate requests on our side too. In the rushed payment implementation, nothing guaranteed that processing the same "subscription activated" event twice would have the same effect as processing it once. Under the wrong retry, a user's tier or billing state could drift out of sync with Stripe. It never bit us in testing, but the pen-test made me look at the whole payments path with suspicion, and this was what I found there.

What Was Shipped?

Four weeks after the first discovery call, I handed Adhiraj a working product, on the exact deadline we had committed to. All three milestones landed against their written acceptance criteria, with no slipped dates and no scope drift.

What he received was a complete end-to-end MVP running live on Vercel: users could sign up, generate post copy and matching visuals with AI, manage a subscription through Stripe, and receive transactional email, all behind rate limiting. Just as deliberately, he received a clean handover position. The security findings were remediated before launch, and the next developer would inherit a small, documented stack with nothing clever to untangle.

What I'd Do Differently

I would give the payment logic the time it deserved instead of treating it as one feature among many. Concretely, that means two things. Every subscription state change would live strictly on the server, so nothing that touches billing or user tier is ever reachable from the client. And every payment operation would be idempotent on both ends: idempotency keys on every mutating call to Stripe, and event-deduplication on our webhook handler so a redelivered event can never double-apply.

I would also make security review a milestone, not an accident. We got lucky that a stranger audited us before launch. Next time, a structured pass over RLS policies and every exposed function is a formal pre-launch acceptance criterion.