How We Built an AI Startup in 30 Days

We built a working AI product, got it in front of real users, and ran our first paid transaction in 30 days. The product was a document intelligence tool — you upload a contract or technical spec, and it surfaces the clauses and sections most likely to matter to you based on your role. By the end of week four, we had 47 beta users, 11 paying customers, and an infra bill of $312 for the month. Here is the honest account of how that happened.

The single most important lesson: the thing that almost killed us was not the AI. It was the decisions we kept deferring because we thought the AI wasn’t good enough yet. The model was fine by day 3. Everything else took 27 more days.

Week 1: Idea Validation and Stack Selection

The idea came from a conversation with a lawyer friend who spent 40 minutes reading a vendor contract looking for the indemnification clause. She knew roughly what she was looking for; she just couldn’t find it fast enough. That’s a real, specific pain. Not “AI makes documents better” — a person who needs to find a specific type of clause in an unfamiliar document, fast.

We spent days 1 and 2 talking to 11 people across three roles: lawyers, startup ops leads, and technical project managers. We weren’t pitching. We were asking: how often do you read contracts or specs you didn’t write, and what are you actually looking for when you do? Eight out of eleven described a version of the same frustration. That was enough signal to start building.

On day 3, we chose the stack. The criteria: fastest path to a shippable UI, lowest ops burden, and good enough performance to not embarrass us in demos. We landed on:

• Next.js + TypeScript on the frontend. We know it well. The App Router handles auth middleware cleanly and it deploys to Vercel in 30 seconds.
• Supabase for the database and auth. Row-level security means we didn’t have to write authorization logic. The Postgres full-text search was useful later. Storage handled file uploads.
• OpenAI GPT-5.5 for the core extraction. Not fine-tuned, just prompted. We evaluated Claude and Gemini briefly — they’re comparable — but we already had GPT-5.5 prompt patterns that worked.
• Vercel for hosting. Zero ops.
• Stripe for payments. We set it up on day 5, which turned out to be one of the best decisions we made.

The things we explicitly cut: a custom vector database (used Supabase pgvector instead), a separate background job queue (used Supabase edge functions for async work), a proper logging/observability stack (used Vercel logs and console.error, which was insufficient but acceptable for week 1), and anything multi-tenant with complex org structures.

By end of week 1 we had a working prototype. You could upload a PDF, it would extract text and run it through a prompt that asked GPT-5.5 to identify and label the high-importance clauses for a given role. The output was rough — structured JSON rendered as an ugly unordered list — but it worked. The core value was demonstrable.

Total time in week 1: roughly 60 hours between two people. About 20 of those were on non-building work: conversations with potential users, reading contracts, writing the prompts, and arguing about scope.

Week 2: Getting to Something Users Can Actually Try

A prototype that only you can run is not useful. Week 2 was entirely about making the thing accessible to someone who isn’t you.

The biggest underestimated task: document parsing. PDFs are a disaster. We were using a simple PDF-to-text extraction library and it handled maybe 60% of real-world contracts correctly. Scanned PDFs returned garbage. Multi-column layouts came out scrambled. PDFs with forms were worse. We burned two full days on this.

The fix: we switched to a preprocessing step that used GPT-5.5’s vision capability on a page-image-per-page approach for anything that the text extractor flagged as low-confidence. Slower, more expensive, but the quality jump was significant. We also added explicit handling for the five most common document layout patterns we saw in our test set. This felt like yak-shaving at the time. It was not yak-shaving. Document parsing quality is load-bearing for a document intelligence product.

Auth was next. We used Supabase Auth with magic link email sign-in. No passwords. Setup took about 3 hours including the UI. The Supabase client libraries are well-designed and this part didn’t fight us.

By day 10, we had a UI that a non-technical person could use without guidance. Upload a PDF, select your role from a dropdown, get a structured output. It wasn’t beautiful, but it wasn’t broken. We sent it to 6 people from our earlier conversations and asked them to try it on a real document they had handy.

Three of them responded within 24 hours with actual documents and actual feedback. That was the moment we knew we had something worth continuing.

Infra cost at the end of week 2: $47. About $30 of that was OpenAI API calls from our own testing. Real user costs were negligible — we had six users and they each ran a handful of documents.

Week 3: First Real Users, Feedback, and a Pivot

We onboarded 19 more people in week 3, mostly through direct outreach to our networks. We weren’t doing any marketing. We were doing manual sales — find a person with the problem, get them to try it, watch what happens.

The most useful thing we did in week 3 was sit next to people while they used it. Not screen share with us talking — them sharing their screen and us keeping our mouth shut. Two sessions like this told us more than all the async feedback we’d collected.

What we learned:

The role dropdown was wrong. We had five roles. Users wanted to describe their goal, not their job title. “I’m looking for anything that limits my liability” is more useful than “I am a: Lawyer.” We changed the input from a dropdown to a text field with example prompts. Took 4 hours. Immediately improved the output quality because the prompt could be more specific.

People wanted to ask follow-up questions. The first output was a structured extraction. But users kept wanting to say “okay, now tell me what clause 7b actually means in plain English.” We hadn’t built a chat interface at all. This was a real gap.

We debated for about a day whether to build a chat interface or stay focused on the extraction use case. We stayed focused, but we added a single “explain this clause” action on each extracted item that sent it back to GPT-5.5 with a plain English explanation prompt. Not a full chat interface, but addressed 80% of the follow-up need. This was the right call — a full chat interface would have taken two weeks and diluted the product.

The other thing week 3 surfaced: people cared a lot about which document types we supported. Contracts, yes. But also SOWs, NDAs, employment agreements, vendor agreements. Each one had slightly different important-clause patterns. We added a document type selector alongside the goal input. The prompts became more targeted.

We also had our first real failure. One user uploaded a 200-page master services agreement. We chunked it badly, the GPT-5.5 context window handling had a bug, and she got back an empty output with no error message. She emailed us. We fixed the chunking logic within two hours and sent her a personal apology with a re-run of her document. She became a paying customer. Fast recovery matters more than zero errors.

Total new signups in week 3: 19. Total active (ran at least one document): 14.

Week 4: Hardening, Pricing, and Launch

Week 4 was the discipline week. No new features. Harden what exists, add pricing, and ship something you can tell people about publicly.

Error handling. We went through every edge case we’d hit in week 3 and added proper error states to the UI. Empty outputs now showed a message. Long documents showed a progress indicator instead of a spinner that looked like it had frozen. Parse failures returned a human-readable explanation instead of a 500. This took a full day but it changed how the product felt.

Pricing. We spent more time on this than we expected. We ended up with a simple two-tier model: a free tier with 5 document analyses per month, and a paid tier at $29/month with unlimited analyses and the document type targeting. We set this up through Stripe’s customer portal, which handles billing, upgrades, and cancellations without us writing much code. Stripe is expensive at scale but at zero users the fee is $0 and the time savings are worth it.

We made a deliberate decision to put the Stripe integration in during week 1 even though we had no users. This meant when we turned on paid plans in week 4, we didn’t have to touch any infrastructure. We just flipped a flag. If you’re building a product where payment is a realistic near-term outcome, set up Stripe early.

Performance. Average document processing time was 18 seconds for a normal contract. That was too slow. We parallelized the chunk processing (we’d been running chunks sequentially) and got it down to 9 seconds. Still not fast, but the progress indicator made it feel faster than it was.

The launch. We posted on Twitter, LinkedIn, and one relevant Slack community. Nothing elaborate. The post was honest: here’s what we built, here’s who it’s for, here’s a link to try it free. We got 23 new signups on launch day. Not viral, but real people with real need.

By end of day 30:

• 47 total beta users
• 11 paying customers at $29/month
• $319 MRR
• $312 infra cost for the month (OpenAI: $180, Supabase: $25, Vercel: $0 on the Pro plan trial, Stripe fees: $107)
• Net: +$7

That last number is a joke, obviously. But it’s not the point. The point is that the business model worked at unit level, users were returning, and we had a foundation to grow from.

What We’d Do Differently

Build the eval suite on day 1. We spent hours in weeks 2 and 3 manually checking whether prompt changes were improvements. An automated eval with a golden set of documents would have cut that time in half and made us more confident in each change.

Talk to users on day 1. We talked to 11 people before writing code, which was good. We should have talked to 30. The two in-person session-watching moments in week 3 were the most valuable research we did, and we could have done them in week 1 with a mockup.

Defer the UI polish longer. We spent time in week 2 making things look decent when the product fundamentals were still shaky. A broken thing that looks okay is still broken. The time would have been better spent on document parsing quality.

Charge from day one. We set up Stripe early, which was good. But we offered the first month free to everyone. We should have asked for a credit card immediately. People who pay are different from people who don’t, and you want to be talking to the former as early as possible.

The Transferable Part

The stack and the specific decisions don’t matter as much as the rhythm: validate fast, build the smallest useful thing, get it in front of real people, watch them use it, fix what breaks, add a paywall. Repeat.

Every week had a clear focus: week 1 was validation and prototype, week 2 was accessibility, week 3 was user feedback and adaptation, week 4 was hardening and monetization. That focus prevented the diffusion that kills most early-stage projects — the endless feature additions that prevent you from learning whether the core thing works.

The AI part was easy. GPT-5.5 with a well-structured prompt did most of the work. The hard parts were document parsing, understanding what users actually wanted, and the boring engineering that makes something feel reliable. That’s always the pattern. The model is rarely the constraint.

If you’re building something in this space, the 30-day format is real but it requires ruthless prioritization. Every feature you add is a feature you can’t test, can’t harden, and can’t learn from. Ship less. Learn faster.