Build process
How I build.
The traditional agency model is structurally slow. Here is how I work, why it moves faster, and what each phase does.
The traditional model
If you hire a typical agency or assemble a team to build a custom application, the structure looks roughly the same regardless of project size. Discovery happens in one phase. Design happens in another. Backend and frontend get split across teams. QA is its own phase at the end. Deployment is treated as a project of its own. Each phase has its own people, its own meetings, and its own formal handoffs.
None of this means agencies are incompetent. The traditional model is built around structures that create friction: multiple people with multiple opinions working in sequential phases with formal handoffs between each one. That structure has overhead, and overhead takes time.
Why the traditional model is slow
The speed problem is not about skill. It is about how the work is organized. Traditional shops slow down because of structural issues that are baked into how they operate:
- Multiple people means multiple opinions. Every decision, from button color to database schema, goes through rounds of discussion, review, and approval. More people on a project does not mean faster delivery. It means more meetings.
- Sequential handoffs between roles. A designer finishes mockups and hands them to a developer. The developer builds it and hands it to QA. QA finds issues and sends it back. Each handoff introduces waiting time and context loss.
- Scope creep is profitable for hourly-billed shops. When an agency bills by the hour, there is little financial incentive to keep a project tight. Every "small addition" and "quick change" extends the timeline and the invoice. The meter keeps running.
- No single person owns the whole picture. The designer knows the UI. The backend developer knows the database. The project manager knows the schedule. Nobody holds the entire application in their head at once. That fragmentation creates miscommunication and rework.
- Client communication goes through layers. You talk to a project manager. The project manager translates your feedback to the designer. The designer interprets it and updates the mockup. The developer gets a third-hand version of what you originally said. Each layer loses fidelity.
How I build
One person handles every phase. Not one person managing a team: one person doing the work. The phases still exist, but they overlap and compress because there are no handoffs between them.
Phase 1
Discovery and architecture
Understand the business, define scope, map every feature, plan the data model and the AI layer that will sit inside it.
Phase 2
Build
UI, backend, database, authentication, integrations, and AI workflows built end to end. You see progress every day.
Phase 3
Launch and support
Deploy to production, hand off the source code, and stay on for post-launch fixes and adjustments.
There is no gap between phases. Discovery informs architecture in real time. Build starts the moment scope is defined. Testing happens continuously, not as a separate phase tacked on at the end. Deployment is part of the build, not a separate project.
How this works without cutting corners
Speed comes from removing structural overhead, not from skipping steps:
- AI-assisted development accelerates coding. I use Claude, GitHub Copilot, and other AI tools to write code faster, generate boilerplate, catch bugs in real time, and automate repetitive tasks. This is not a gimmick. AI-assisted development genuinely compresses what used to take days into hours. I still architect, review, and test every line, but the raw coding speed is dramatically faster. See the full tech stack →
- One person means zero communication overhead. No standups. No sprint planning meetings. No design reviews with six people in a conference room. No waiting for someone on another team to finish their piece. One developer holds the entire application in their head and makes decisions instantly.
- Modern frameworks are built for speed. Next.js, React, Tailwind CSS, and shadcn/ui are designed for rapid application development. What used to take weeks of custom CSS and bespoke UI code now takes hours with the right tools. The frameworks handle routing, server rendering, styling, and component architecture out of the box.
- No design committee. I make design decisions in real time with the client. You get screenshots and links to the live build throughout the process. If something is off, it is corrected immediately, not queued for a review meeting next Tuesday.
- Text-based communication eliminates scheduling. No calendar invites. No "let me find a time that works for everyone." You text feedback whenever you have it. I respond and implement. The conversation is continuous and asynchronous, not batched into weekly calls.
- Your project gets undivided attention. When I take on your project, it is my sole focus for the duration. I am not splitting time across four other clients. I am not context-switching between your dashboard and someone else's checkout flow. Every working hour goes into your application.
When the work is bigger
Honesty matters more than a sales pitch. Some projects genuinely need more than a single compressed engagement. Pretending otherwise wastes your time and money. Projects that typically need more time include:
- Complex enterprise systems with dozens of interconnected modules, deep role hierarchies, and extensive business logic refined over years
- Applications with many distinct screens where every screen requires unique functionality, not just different views of the same data
- Heavy data migrations from legacy systems where existing data is messy, undocumented, or stored in formats that require significant transformation
- Regulatory compliance requirements like HIPAA certification, SOC 2 audits, or specific government security standards that require formal documentation and third-party verification
If your project falls into one of these categories, I will tell you upfront during the initial conversation. There is no bait-and-switch where you find out mid-build that the scope is unrealistic.
For larger projects, the approach is phased. Build an MVP that covers the core functionality, the 20% of features that deliver 80% of the value. Launch it, get real users on it, and then iterate with additional development phases. This is how successful software companies operate: ship something real, learn from it, then expand. Read the full MVP development guide for more on this approach.
Source code ownership included.