Building
I Spent 10 Hours Before Writing a Single Line of Code. That's Why It Worked.
I Spent 10 Hours Before Writing a Single Line of Code. That's Why It Worked.
Everyone's talking about AI coding speed. "Built an app in 30 minutes." "Shipped a feature in one prompt." "Replaced my entire dev team."
Cool stories. Most of them fall apart at the first real user.
I want to tell you a different story. One where the boring part — the 10 hours nobody posts about on X — is the reason the exciting part actually worked.
The Project
We replaced Intercom and Pipedrive at Flalingo. Not with another SaaS — with a custom CRM built from scratch.
If you've used either tool, you know the scope. Omnichannel inbox, deal pipelines, contact management, automations, reporting. These are products built by hundreds of engineers over many years.
I built the first version in about 15 days.
Before you roll your eyes — yes, there are rough edges. No, we don't have feature parity with every Intercom widget. But 36 hours after launch, the sales and support teams were already happier than they'd been with the $100K/year stack we replaced. Real users, real workflows, real relief.
The question is: how?
And the answer is not "AI is magic." The answer is that I spent 10 hours preparing context before a single line of code was generated.
The Part Nobody Posts About
Here's what the "built X in Y hours" crowd usually skips: the preparation.
In traditional enterprise software development, there's a process that exists for very good reasons. A Business Owner gathers requirements. They write an FSD — a Functional Specification Document. Then a Solution Architect translates that into a TSD — a Technical Specification Document. Only then does anyone write code.
Most AI coders skip all of this. They open Claude or Cursor, describe what they want in a paragraph, and hit enter. Then they spend days fighting with the output — because the AI had no real context for what it was building.
I did the opposite. I spent a full day writing documents before touching the terminal.
Step 1: The FSD (~4-5 Hours)
The Functional Specification Document answers one question: what should this thing do?
No code. No architecture. No databases. Just: the user clicks here, this happens. When a call comes in, this screen appears. When a deal moves to this stage, this automation fires.
For the CRM project, this was about 20 pages. Written with AI, obviously — but through multiple iterations. 10, 15 rounds of "what about this edge case?" and "no, when I said X, I meant Y."
This is critical. If you take the first output from an LLM and run with it, you've already lost. The first output is a rough sketch. The 10th iteration is the blueprint.
And here's the thing that people miss: once you're convinced by the FSD — once you genuinely believe the document describes the right product — you've finished 40-50% of the work. The rest is execution.
Step 2: The TSD (~3-4 Hours)
The Technical Specification Document translates "what" into "how."
Table names. API endpoint structures. Architecture decisions (WebSocket vs. polling, queue vs. sync). Database schemas. Authentication flows. Sample code for critical paths.
Again — written with AI, through multiple iterations. But driven by my judgment about what's right for our stack (Laravel 11, React, PostgreSQL).
The TSD is where your engineering experience matters most. The AI can suggest 5 different approaches. You need to pick the one that fits your existing codebase, your team's skills, and your operational constraints.
Step 3: The Team (~30 Minutes Setup, ~9 Hours Execution)
This is where it gets interesting.
Claude Code has a feature most people don't know about: you can create teams of AI agents. I set up:
- 1 Project Manager — orchestrates the work, breaks down the TSD into tasks
- 1 Solution Architect — writes detailed descriptions for each task based on the FSD and TSD
- 2 Developers — implement the code
- 1 QA — tests the implementations
- 1 Code Reviewer — using Codex CLI via MCP, reviews every piece of code
I used Claude's extended context window for the PM agent — it needed to hold the full FSD, TSD, and project state simultaneously.
Then I turned on --dangerously-skip-permissions, and walked away.
8.5-9 hours later, the skeleton was built. Not a prototype — a working application with full CRUD operations, pipeline management, reporting screens, automation framework.
The reporting screen surprised me the most. I hadn't given it detailed specs. But between the FSD describing what reports users need, and the TSD describing the data model, the agents figured out a beautiful, detailed reporting interface. Almost zero corrections needed.
Step 4: The Other 14 Days
Let's be honest. The AI didn't finish the project in 9 hours.
I spent another 14 days. 3-4 of those were intensive — tweaking, adding features the FSD didn't cover, integrating with our existing systems. The rest were lighter days where I worked on the CRM alongside other projects. The last 4-5 days were essentially QA — people used it, reported issues, I fixed them.
Bug fixing with AI deserves its own note. I take the feedback — often just a screenshot and a sentence — drop it into Claude Code in either plan mode or extended thinking mode depending on complexity, and let it work. What changed recently: it actually fixes things now. With Opus 4.6, when Claude says "I fixed it," it's fixed about 90% of the time. That ratio was much lower before Sonnet 4.6.
And every fix goes through Codex CLI for review. I've made this a habit for anything touching more than 2-3 files. The diff goes to Codex, Codex reviews it, I apply the feedback. It's a 2-minute habit that catches real issues.
The Math
Pipedrive at full capacity: ~$50-60K/year.
Intercom without startup discount: ~$40-50K/year.
Combined: easily $100K/year.
My CRM: 15 days of my time + AI compute costs.
Is it a fair comparison? Not entirely. These are mature products with enormous feature sets. But here's the thing: I don't need their feature sets. I need the features my team actually uses. And those, it turns out, aren't that many.
This is the SaaS Is Dead thesis in practice. You don't need to replicate the entire product. You need to solve your specific problem. And with AI-assisted development, solving your specific problem has become dramatically cheaper than renting someone else's general solution.
The Real Lesson: Context Is the Multiplier
I could have skipped the FSD. Could have skipped the TSD. Could have opened Claude Code on day one and said "build me a CRM."
The output would have been garbage. Not because the AI is stupid — because it would have had no context for what "CRM" means to Flalingo. Our specific workflows, our teacher-student matching, our support team's actual daily routine, our sales pipeline stages.
10 hours of context preparation saved weeks of rework. That's the equation nobody talks about.
This is what I mean when I say Context Engineering > Prompt Engineering. Your prompt is a sentence. Your context is a 20-page FSD, a 15-page TSD, and the institutional knowledge that tells the AI which of its 5 suggestions is actually right for your situation.
The same AI, same model, same capabilities — pointed at two different projects with two different levels of context preparation — will produce wildly different results. I've seen it in my own team. Same tools, same access, 10x difference in output quality. The difference is always context.
A Side Effect I Didn't Expect
Here's something that happened during the CRM build that I want to share.
We were integrating a telephony feature — Power Call via NetGSM. Outbound dialing, inbound routing, AI-assisted call summaries. The usual enterprise telephony complexity.
I had a 40-minute meeting with our operations lead. He explained the requirements, the current workflow, the pain points. I recorded the meeting, transcribed it with Gladia, and fed the transcript to Claude.
40 minutes of messy, meandering conversation became a structured FSD in about 30 minutes. What would normally take me 2-3 hours of writing — because I'd need to organize my thoughts, remember what was said, fill in gaps — took a fraction of the time because the raw context was already captured.
This pattern — record, transcribe, structure — is becoming my default for feature specification. Claude Code now even has an audio input feature (launched this week, still buggy, but promising). The direction is clear: capture context in whatever form it naturally occurs, let AI structure it.
What This Means for Your Team
I'm not telling you to build your own CRM. That was my specific situation and my specific calculation.
What I am telling you:
If your AI coding sessions start with a prompt, you're leaving 50% of the value on the table. Start with context. Write the FSD. Write the TSD. Make the AI understand what it's building before it builds.
If your team's AI results are inconsistent, the problem isn't the model. It's that some people prepare context and some don't. Same amplifier, different input signal, different output quality.
If you think AI coding is just "faster typing," you're thinking about it wrong. It's faster everything — but only when the "everything" includes proper specification, architecture, review, and testing. Skip those, and you get faster production of bad code.
The 10-hour rule isn't a constraint. It's the reason the next 9 hours produce something real.
I run a workshop where I teach teams exactly this: how to move from "using AI tools" to building real systems with AI. Not toy demos — production systems that serve actual users. One day, 15 people max, and you walk out with a framework for your own organization. Details here.
Hayreddin Tüzel
CTO & Co-Founder @ Flalingo