How a 4-month backend-only project became the catalyst for embracing AI-assisted development.

For years, I delivered backend systems that worked flawlessly—until I had to build one that users loved. That’s when my tools, mindset, and workflow had to change completely.

If you’re a backend developer who’s ever felt paralyzed by frontend requirements, a tech leader evaluating legacy platform migrations, or simply curious about how AI is reshaping modern software development, this series is for you. What started as a simple refactoring project evolved into a complete transformation in how I approach building software.

I’ve long considered myself a “backend purist.” Give me a database schema to design, some complex business logic to implement, or a REST API to architect, and I’m in my element. I can spend hours optimizing queries, designing elegant data models, and building robust server-side architectures that can handle massive scale.

But when it comes to user interfaces? That was always a different story entirely.

This wasn’t just a skills gap—it was a mental block that had shaped my entire career. I had unconsciously optimized every architectural decision, every technology choice, and every project approach to avoid frontend development altogether. I became incredibly skilled at building the engine, but I was terrified of designing the dashboard.

The psychology behind this avoidance was complex. Frontend development felt unpredictable, subjective, and frustratingly visual. Backend code either worked or it didn’t—there were clear metrics, predictable outcomes, and logical problem-solving patterns. Frontend work seemed to exist in a gray area where “looking good” was as crucial as “working correctly,” and I had no framework for evaluating success.

Over the years, I had developed an entire arsenal of avoidance strategies:

• Choosing frameworks that provide built-in UI components
• Partnering with frontend specialists whenever possible
• Building APIs and letting others handle the presentation layer
• Gravitating toward backend-heavy roles and projects

This approach worked well for many years. I built my reputation as someone who could architect complex systems, optimize database performance, and design APIs that other developers loved to work with. But it also created a significant limitation in my ability to build complete solutions independently.

When I began building what would eventually become our document management platform, I reached for a familiar tool: Oracle Apex. Not because it was the best fit for the project requirements, but because it let me avoid the frontend challenge entirely while still delivering a complete application.

Oracle Application Express (Apex) had been my go-to solution for rapid application development for several years. It’s a low-code development platform that runs on Oracle Database, allowing developers to build web applications using primarily SQL and PL/SQL—languages I already knew intimately.

From a developer productivity standpoint, Apex offered several compelling advantages:

• Declarative Development Model: Instead of writing HTML, CSS, and JavaScript, I could define pages, regions, and items through a web-based development environment. Forms were generated automatically based on database table structures, and reports could be created with simple SQL queries.
• Built-in Security: Apex provided robust authentication and authorization frameworks out of the box. Session management, user roles, and data access controls were handled automatically by the platform.
• Database Integration: Since Apex runs directly on Oracle Database, there was no impedance mismatch between the application layer and data layer. Complex queries, stored procedures, and database triggers worked seamlessly with the application logic.
• Rapid Prototyping: I could go from database design to a working application in a matter of hours. This made it excellent for proof-of-concept development and internal tools, where time-to-market was more important than custom user experience.

Over the years, I had become genuinely skilled at Apex development. I understood its architectural patterns, had mastered its more advanced features, and could work around most of its limitations. I could build complex applications with:

• Multi-table forms with master-detail relationships
• Interactive reports with sorting, filtering, and pagination
• Charts and dashboards with real-time data
• File upload and download functionality
• Email integration and workflow automation
• RESTful web services for external integrations

The productivity gains were undeniable. What might take weeks to build with traditional web development could be accomplished in days with Apex. For internal business applications and rapid prototypes, it was incredibly effective.

• Multi-Channel Delivery: Content and functionality can be delivered to websites, mobile apps, IoT devices, and other digital touchpoints through APIs.
• Frontend Freedom: Development teams can choose the most appropriate frontend technologies for each channel without being constrained by backend limitations.
• Content Management: Headless content management systems enable content creators to focus on content creation, while developers handle the presentation logic.
• Personalization: A separated architecture enables more sophisticated personalization and A/B testing capabilities across various channels.

However, as the document management platform requirements evolved, I began to encounter Apex’s fundamental limitations more frequently:

• User Experience Constraints: While Apex applications were functional, they had a distinctive “database application” feel. The UI patterns, navigation models, and interaction paradigms were optimized for data entry and reporting rather than modern user experiences.
• Customization Ceiling: Beyond a certain point, customizing the look and feel required increasingly complex workarounds. Advanced UI patterns, such as single-page applications, real-time collaboration, or mobile-first responsive design, were possible but required fighting against the platform’s assumptions.
• Integration Complexity: While Apex could consume web services and integrate with external systems, doing so often required significant PL/SQL development and didn’t leverage modern integration patterns, such as webhooks, GraphQL, or event-driven architectures.
• Scalability Concerns: For applications with complex user interactions or high concurrency requirements, Apex’s page-based model created performance bottlenecks that were difficult to optimize.

The document management system started as a straightforward internal tool. The requirements seemed perfect for Apex:

• User authentication and authorization
• Document upload and storage
• Folder organization and hierarchy
• Search and retrieval functionality
• Basic sharing and permissions
• Integration with Google Drive
• LLM-based document summarization and workflow management

I spent four months building a comprehensive solution that addressed all these requirements. The application worked exactly as specified. Users could log in, upload documents, organize them into Google Drive folders, and have the LLM summarize and share them with colleagues according to the suggested workflow. From a functional perspective, it was a complete success.

The Apex application I built was genuinely sophisticated:

• Multi-Tenant Architecture: I implemented tenant isolation using a combination of database schemas and application-level security contexts. Each organization had its own data partition while sharing the same application code.
• Complex Data Model: The system supported hierarchical folder structures, document versioning, user groups, and fine-grained permissions—the database design comprised over 30 tables, each with appropriate indexes, constraints, and triggers.
• Google Drive Integration: I built a comprehensive integration that handled OAuth authentication, file synchronization, change detection, and conflict resolution. Users could seamlessly work with documents in both systems.
• Advanced UI Components: I pushed Apex to its limits with interactive grids, dynamic regions, and custom JavaScript to create a more modern user experience than typical Apex applications.
• Comprehensive Security: The application features role-based access control, audit trails, data encryption, and secure file handling, ensuring compliance with enterprise security requirements.

From a technical complexity standpoint, it was some of the most sophisticated Apex development I had ever completed. It demonstrated mastery of the platform and effectively solved real business problems.

But when I shared the completed application with early users—including colleagues at BuzzClan and external stakeholders—the feedback was consistent and eye-opening:

“It works perfectly, but it doesn’t feel modern.” “The functionality is great, but the interface feels dated.” “It’s very capable, but it looks like an internal database tool.” “Can we make it look more like [modern SaaS application]?”

These comments weren’t criticisms of the functionality—users acknowledged that the system worked well and met their needs. But they highlighted a gap between what was technically accomplished and what users expected from modern software experiences.

• Technology Adoption: New technologies can be adopted incrementally without requiring complete system overhauls.
• Developer Productivity: Developers can focus on building business value rather than dealing with technical constraints imposed by monolithic systems.
• Competitive Advantage: The ability to quickly implement new capabilities and adapt to market changes provides significant competitive advantages.

As I researched the document management market more thoroughly, I realized that user expectations had undergone significant evolution. Modern SaaS applications set a high bar for user experience:

• Intuitive Navigation: Users expected clean, discoverable interfaces with clear information architecture and minimal learning curves.
• Responsive Design: Applications needed to work seamlessly across desktop, tablet, and mobile devices with consistent functionality and appearance.
• Real-Time Collaboration: Features like live editing, instant notifications, and collaborative commenting have become standard expectations rather than premium features.
• Modern Visual Design: Users expect applications to look and feel contemporary, with thoughtful typography, color schemes, and interaction patterns.
• Fast Performance: Single-page application patterns with instant loading, smooth transitions, and optimistic UI updates were becoming baseline expectations.

After four months of development and receiving consistent feedback about the user experience, I reached a critical decision point. I could either:

• Double down on Apex and accept its limitations as the price of rapid development
• Hire frontend specialists to build a custom interface while keeping the Apex backend
• Tear everything down and rebuild from scratch using modern technologies

Option 1 felt like giving up on delivering the best possible solution.
Option 2 would require significant coordination overhead and might create architectural inconsistencies.
Option 3 was intimidating but offered the potential for the best outcome.

The prospect of rebuilding the entire application using modern web technologies was genuinely frightening. It meant:

• Learning New Technologies: I need to become proficient with frontend frameworks, modern CSS, JavaScript, and contemporary development workflows.
• Architectural Decisions: I need to make informed choices about technology stack, deployment strategies, and system design without the safety net of familiar tools.
• Time Investment: The rebuild would likely take longer than the original development, with uncertain timelines and outcomes.
• Quality Risk: There was no guarantee that I could deliver the same level of functionality and reliability with unfamiliar technologies.

But there was also an opportunity hidden in this challenge: the chance to break through the frontend barrier that had limited my development capabilities for years.

Even before the term “vibe coding” was coined, I was already experimenting with AI tools in my development workflow—but in a very traditional, limited way.

ChatGPT, Claude, and other large language models have become my go-to companions for backend development challenges. I would ask questions about database design patterns, debug complex SQL queries, generate boilerplate code, and explore architectural alternatives. The AI tools were helpful, but they functioned more like an intelligent search engine than a collaborative partner.

My typical AI-assisted development process looked like this:

• Problem Identification: I encountered a specific technical challenge or needed to implement a particular feature.
• Query Formulation: I would craft a prompt describing the problem, often including code snippets or error messages.
• Response Processing: The AI would provide suggestions, code examples, or explanations that I would review and evaluate.
• Copy-Paste Integration: I would copy relevant parts of the AI’s response and paste them into my development environment.
• Manual Integration: I would modify the AI-generated code to fit my specific context, fix any issues, and integrate it with existing code.
• Testing and Iteration: If the solution didn’t work perfectly, I would return to the AI with more specific questions or error messages to refine it.

This workflow was certainly more efficient than searching through documentation or Stack Overflow, but it still left all the creative and architectural thinking to me. The AI was reactive rather than proactive, responding to my questions rather than helping me think through problems systematically.

While this traditional approach to AI-assisted development was helpful, it had significant limitations:

• Context Loss: Each interaction with the AI was largely independent of the others. The AI failed to maintain context regarding my broader project, architectural decisions, or ongoing challenges.
• Fragmented Solutions: I received isolated code snippets rather than coherent, integrated solutions that considered the entire system architecture.
• Limited Creativity: The AI responded to my questions rather than suggesting alternative approaches or identifying issues I hadn’t considered.
• Integration Overhead: I spent a significant amount of time adapting AI-generated code to fit my specific context and resolving conflicts with existing code.
• No Architectural Guidance: The AI could help with implementation details, but provided limited insight into higher-level design decisions.

As AI development tools evolved rapidly throughout 2024, I experimented with various approaches to find more effective ways to leverage AI assistance:

These were excellent for exploratory questions and learning new concepts, but the copy-paste workflow created significant friction. Each conversation was isolated, and I had to manually manage context and integration.

This represented a significant improvement in workflow integration. Having AI suggestions directly in the code editor eliminated the need for copy-pasting and provided contextually aware suggestions. However, it still felt more like intelligent autocomplete than true collaboration.

This was a game-changer in my AI development journey. Unlike other tools that added AI capabilities to existing development environments, Cursor was built from the ground up around AI collaboration. It provided:

• Contextual Awareness: The AI understood my entire project structure, including file relationships, architectural patterns, and coding conventions.
• Conversational Development: I could have ongoing conversations about code changes, architectural decisions, and problem-solving approaches without losing context.
• Multi-File Operations: The AI could make coordinated changes across multiple files, understanding how modifications in one area affected other parts of the system.
• Continuous Learning: The AI learned from my preferences, coding style, and project-specific requirements throughout our collaboration.

I also explored various specialized tools like code interpreters, documentation generators, and testing assistants. Each provided value in specific contexts, but none offered the comprehensive collaboration experience I was seeking.

After months of gradual evolution in how I used AI tools, I reached a philosophical turning point. Instead of using AI as a more intelligent search engine or autocomplete tool, I wanted to explore what I now call “vibe coding”—a collaborative, iterative development style where AI functions as a thinking partner rather than just a tool.

Vibe coding, as I came to understand it, represents a fundamental shift in the human-AI collaboration model:

• Conversational Development: Rather than requesting specific code snippets, I could discuss problems, explore alternatives, and think through solutions in natural language.
• Shared Context: The AI maintained awareness of the project’s history, architectural decisions, and ongoing challenges, enabling more sophisticated and relevant suggestions.
• Iterative Refinement: Instead of one-shot code generation, we could iterate on solutions together, improving and refining approaches through multiple rounds of collaboration.
• Architectural Partnership: The AI could participate in higher-level design discussions, suggesting architectural patterns, identifying potential issues, and proposing alternatives.
• Learning Amplification: Rather than just providing answers, the AI could help me understand underlying principles and best practices, accelerating my learning of new technologies.

Embracing vibe coding required a significant mindset shift:

• From Commands to Conversations: Instead of issuing specific requests, I learned to engage in open-ended discussions about problems and solutions.
• From Solutions to Understanding: Rather than just seeking working code, I focused on building a comprehensive understanding of the underlying concepts and patterns.
• From Individual to Collaborative: I had to overcome the habit of working in isolation and learn to leverage a collaborative partner effectively.
• From Perfect to Iterative: Instead of expecting perfect solutions immediately, I embraced a process of continuous refinement and improvement.

To give myself the motivation and focus needed for this transformation, I established a concrete goal: rebuild the entire document management platform in four weeks using modern technologies with AI as my development partner.

The four-week timeline wasn’t arbitrary—it was strategically chosen to create the right balance of pressure and possibility:

• Forcing Function: A tight deadline would prevent overthinking and force rapid decision-making and learning.
• Focused Effort: Four weeks was long enough to make meaningful progress but short enough to maintain intensity and focus.
• Comparison Benchmark: It provided a clear comparison point against the four months required for the original Apex development.
• Skill Development Window: Four weeks were sufficient to develop basic competency in new technologies while working on a real project.
• Risk Management: If the experiment failed, a four-week loss was an acceptable outcome that wouldn’t significantly impact other commitments.

The rebuilt application needed to match or exceed the functionality of the original Apex version:

• User authentication and authorization
• Document upload, storage, and retrieval
• Hierarchical folder organization
• Advanced search capabilities
• Sharing and permissions management
• Google Drive integration and synchronization

• Professional, modern user interface
• Fully responsive design for all device types
• Fast performance with optimistic UI updates
• Comprehensive error handling and user feedback
• Security practices meet enterprise standards
• Maintainable, well-documented codebase

• Multi-tenant design supporting multiple organizations
• RESTful API design for future extensibility
• Database schema optimized for performance and scalability
• Deployment pipeline supporting development and production environments

Beyond rebuilding the application, I had specific learning objectives:

• Frontend Development: Overcome my frontend fears and develop genuine competency in modern web development.
• AI Collaboration: Master the art of collaborative development with AI tools, learning to leverage AI strengths while maintaining human oversight and creativity.
• Modern Architecture: Learn contemporary patterns for full-stack application development, moving beyond monolithic database-centric designs.
• Technology Integration: Develop skills in connecting multiple technologies, services, and APIs into cohesive systems.
• Development Workflow: Establish sustainable practices for rapid development that maintain quality and maintainability.

Further Reading

• Monolithic vs Microservices Architecture: Choosing the Right Approach

The decision to tear down four months of work and rebuild from scratch was both terrifying and exhilarating. It represented a commitment to growth over comfort, learning over familiarity, and partnership over isolation.

In the following article of this series, I’ll share how I learned to communicate effectively with an AI coding partner—not just by writing better prompts, but by engaging in real-time, collaborative problem-solving that felt more like pair programming than tool usage.

We’ll explore:

• The awkward early attempts at AI collaboration and how I overcame them
• The surprising breakthroughs that changed my perspective on what AI could contribute
• How I learned to describe frontend designs to someone who can’t see the screen but somehow understands the vision
• The iterative process that transformed both my code and my thinking
• The moment I realized AI wasn’t just making me faster—it was making me better

This transformation wasn’t just about technology—it was about breaking through personal limitations that had shaped my entire career. The journey from backend-only developer to confident full-stack builder, powered by AI collaboration, offers lessons that extend far beyond any specific technology or project.

The four-week challenge evolved into more than a development sprint—it became a proving ground for a new approach to building software in the era of AI.