From 0 to 10K Users in 8 Months: How We Built Endeverus (And the 3 Architectural Mistakes That Nearly Killed It)

In February 2023, three undergraduate students from Melbourne came to Glinteco with a problem: they couldn't find internships despite having strong academic records. Traditional job platforms weren't built for students seeking short-term project experience, and small businesses couldn't afford the overhead of formal internship programs. They envisioned Endeverus, a platform connecting students with small businesses for mutual growth through project-based collaborations. Their budget was $45,000, timeline was aggressive at 8 months to launch before the academic year started, and their technical knowledge was limited to "we need an app and a website."

The platform launched in October 2023 and reached 10,000 users by June 2024, connecting 2,400 students with 840 small businesses across Australia. But these numbers hide the reality of what actually happened during development. We made three significant architectural mistakes that nearly derailed the project, spent $12,000 fixing issues we could have avoided, and learned hard lessons about the gap between theoretical planning and production reality. Our initial WebSocket-heavy architecture tanked performance under real traffic, our Django admin customizations created maintenance nightmares, and our AWS S3 implementation cost 4x what it should have due to inefficient file handling.

This case study walks through the actual custom software development process for Endeverus, not the sanitized version where everything works perfectly. You'll see what we planned, what failed, why we made specific architectural decisions (including the ones we got wrong), the trade-offs we accepted to stay on budget and timeline, and the measurable outcomes after 8 months in production. Written for founders evaluating custom development partners and CTOs reviewing similar platform builds, with specific focus on marketplace platforms connecting multiple user types.

What This Article Covers

You'll understand the complete 12-month development process from discovery to production launch with real timeline breakdowns, see the three major architectural mistakes we made and the $12,000 cost to fix them, learn why we chose Django + Vue.js over alternatives like FastAPI + React and whether that choice was correct, discover the specific trade-offs we accepted to meet the $45,000 budget constraint, and review actual production metrics after 8 months including performance, costs, and user growth.

About the Author

Written by Tran Doan Hien

Tran Doan Hien is Backend Lead at Glinteco with 10+ years building scalable platforms for startups across Australia, Japan, and USA. He personally led the Endeverus development from architecture design through production deployment, including the painful process of fixing three major mistakes he made in the initial build. This case study reflects real decisions, real failures, and real lessons from a 12-month project that's now processing 5,000+ monthly transactions.

More case studies 

Part 1: The Client's Challenge - Why Endeverus Needed to Exist

The three founders came to us in February 2023 with a problem that was both personal and widespread. Alex, Maria, and James were computer science undergraduates at Melbourne University with strong academic records—GPAs above 3.5, completed coursework in algorithms and systems design, active in hackathons. Despite these credentials, none of them could secure internships at tech companies because every position required "1-2 years professional experience." The catch-22 was obvious: they needed experience to get experience, but no one would hire them to gain that initial experience.

Their research revealed this wasn't just their problem. According to Australian Bureau of Statistics graduate employment data, 47% of recent graduates reported difficulty finding relevant work experience during their studies, with this percentage higher in technical fields where specific project experience matters more than theoretical knowledge. Meanwhile, small businesses consistently reported struggling to find affordable help for short-term projects: website updates, data analysis, process automation that didn't justify hiring full-time staff or expensive consultants.

The founders envisioned Endeverus as a marketplace connecting these two groups. Students would get real-world project experience working on actual business problems, building portfolios that demonstrated practical skills beyond coursework. Small businesses would access motivated, affordable talent for projects that otherwise wouldn't get done. The name "Endeverus" combined "endeavor" with "us", the idea that both sides were endeavoring together for mutual benefit. The vision was clear, but translating it into working software required solving complex technical and business logic challenges that the founders couldn't fully articulate yet. That's where our discovery process began.

Part 2: Discovery and Planning - What We Thought We'd Build

The discovery phase ran from February through March 2023, consuming 120 hours of our time and approximately 60 hours of the founders' time in workshops and requirements sessions. Our goal was transforming their high-level vision into specific technical requirements, user flows, and architecture decisions. The core challenge was designing a platform that served three distinct user types: students, businesses, and an administrative layer—with different needs, workflows, and success metrics.

Through structured workshops, we mapped the essential user journeys. Students needed to create profiles highlighting skills, browse available projects filtered by technology and time commitment, submit proposals explaining their approach, collaborate with businesses during project execution, and build portfolios showcasing completed work. Businesses needed to post project requirements with budgets and timelines, review student proposals and select candidates, manage project milestones and payments, provide feedback and ratings, and potentially hire students for future work. The platform itself needed administrative controls for dispute resolution, payment processing and escrow management, quality monitoring to prevent abuse, and analytics for growth tracking.

The technology stack decision came down to two primary options. Option one was FastAPI + React + PostgreSQL, which would provide maximum performance with async Python and modern React patterns, though it required more frontend development time and had a smaller talent pool for future maintenance. Option two was Django + Vue.js + PostgreSQL, offering mature ecosystem with built-in admin, faster development due to Django's batteries-included approach, and easier future hiring, though with slightly lower performance ceiling. We chose Django + Vue.js primarily for speed-to-market and cost considerations within the $45,000 budget. This decision proved mostly correct, though we later discovered specific performance trade-offs we hadn't fully anticipated.

For real-time features, we planned extensive WebSocket usage for instant messaging between students and businesses, live project status updates, real-time notifications for proposals and milestone completions, and collaborative document editing. This turned out to be our first major mistake, which we'll detail in Part 3. For file storage, we selected AWS S3 for project documents, student portfolios, and business attachments, implementing what we thought was standard practice. This became our second costly mistake. The planned timeline was February-March for discovery and planning, April-June for core development building user authentication, project posting, proposal systems, and messaging, July-August for integration work including payment processing via Stripe, file management, and email notifications, and September for testing and deployment with beta launch targeting early October 2023 before the academic semester started.

Part 3: What Failed - The Three Mistakes That Cost $12,000

Mistake 1: Over-Engineering Real-Time with WebSockets

Our initial architecture used WebSockets for almost everything involving updates: messaging, notifications, project status changes, and even simple data refreshes. The reasoning seemed sound: users expect instant updates in modern platforms, and WebSockets are the standard technology for real-time communication. We implemented Django Channels with Redis as the channel layer, creating persistent connections for every active user. This worked beautifully in development with 10-20 concurrent users during testing, but fell apart immediately when we opened beta testing to 500 users in early October 2023.

The performance degradation was dramatic. Server costs spiked to $800 monthly vs our planned $200, CPU usage hit 85% average during peak hours despite being under 30% in testing, and database queries multiplied 10x because every WebSocket connection triggered separate queries for user state. User complaints came fast, pages took 5-8 seconds to load during Australian business hours (9am-5pm AEST), the mobile app drained batteries noticeably, and connections dropped frequently requiring manual refreshes. The root cause was that WebSockets are expensive to maintain at scale. Each connection requires server memory and processing power, and we were keeping thousands of connections alive 24/7 even when users weren't actively interacting with the platform.

The fix required two weeks of intensive refactoring in October 2023, consuming 160 development hours at $75/hour or $12,000 total. We switched to a hybrid model where critical real-time features like direct messaging kept WebSockets since instant delivery was essential there, but project updates moved to polling every 30 seconds when users were actively viewing project pages, notifications moved to push notifications via Firebase instead of WebSocket streams, and data refreshes used standard REST API calls with smart caching. After this refactor, server costs dropped to $280 monthly, page load times improved to 1.2 seconds average, and battery drain complaints disappeared completely. The lesson was harsh: real-time is overrated for most features, and users can't actually tell the difference between instant updates and 30-second polls for non-critical information.

Mistake 2: Django Admin Customizations That Created Technical Debt

Django's built-in admin panel is powerful, and we thought we were being clever by extensively customizing it for Endeverus's administrative needs. We added custom views for managing disputes, built complex filters for project monitoring, created inline edits for user verification, and integrated custom actions for bulk operations. This saved development time in the short term about 80 hours we would have spent building a custom admin interface. The problem emerged three months post-launch when we needed to make changes based on user feedback.

Every modification to admin functionality required navigating Django's admin customization layers, changes in one area broke unexpected admin features elsewhere, and onboarding new developers meant explaining our custom admin architecture. According to research on technical debt in Django projects, over-customized admin panels are a primary source of maintenance burden in mature Django applications. We spent 40 hours in January 2024 partially rebuilding admin functionality into a proper custom dashboard, accepting this as necessary technical debt payment. The trade-off was worth it for faster initial launch, but we should have planned for this refactor from the start and budgeted accordingly.

Mistake 3: Naive AWS S3 Implementation

Our S3 implementation followed what seemed like standard practice—direct uploads from the frontend, storing files with predictable naming patterns, and public read access for profile images. Within two months, we discovered three expensive problems. S3 costs were $600 monthly vs our planned $150 due to excessive GET requests from poorly implemented caching, students were uploading 50MB+ portfolio files when we had no size limits, and our public bucket structure created security concerns for business documents. The fix required implementing signed URLs for secure uploads, CloudFront CDN for file delivery reducing S3 GET costs by 70%, strict file size limits with client-side validation, and proper access control policies.

This refactor took one week in December 2023, and S3 costs dropped to $180 monthly after implementation. The lesson was that AWS documentation shows basic implementation, but production use requires understanding cost optimization patterns that aren't obvious to developers who haven't scaled file storage before. We should have consulted with experienced DevOps engineers during architecture planning, similar to the approach we now use detailed in Glinteco's system architecture consulting.

Part 4: The Rebuild Process - Fixing Mistakes Under Production Load

The most challenging aspect of fixing our architectural mistakes was that we couldn't pause Endeverus to rebuild; the platform was live with 1,200 active users by November 2023, growing by 400+ users monthly. Every architectural change had to happen without disrupting service or losing data, requiring careful planning and staged deployments. The WebSocket refactor was most critical since performance issues were causing user churn. We implemented the fix in stages over two weeks in October 2023.

Week one focused on backend changes, implementing REST API endpoints for all non-critical updates, adding polling mechanisms with exponential backoff, and setting up Firebase for push notifications while keeping WebSocket connections active as fallback. Week two involved frontend deployment, rolling out new API integrations to 10% of users first, monitoring error rates and performance metrics closely, and gradually increasing deployment to 100% once we confirmed stability. During this period, we maintained both systems running in parallel, adding server costs temporarily but preventing any downtime. The cutover happened on a Sunday morning when traffic was lowest, and we rolled back WebSocket infrastructure only after confirming three days of stable operation.

The Django admin refactor was less urgent but equally important for long-term maintenance. We tackled this in January 2024, building a proper Vue.js admin dashboard incrementally. Rather than replacing everything at once, we migrated admin features one section at a time: user management first, then project oversight, then dispute resolution which is allowing administrative staff to adapt gradually to new interfaces. This staged approach took longer but prevented the chaos of forcing administrators to learn an entirely new system overnight while handling live support issues.

The S3 optimization required coordinating changes across three layers: frontend upload logic, backend signed URL generation, and AWS infrastructure configuration. We implemented this in December 2023, using feature flags to test with a small percentage of users before full deployment. The CloudFront CDN integration was most complex, requiring DNS changes and SSL certificate configuration that we staged carefully to avoid breaking existing file URLs that students had shared in their portfolios or that businesses referenced in project documentation.

Part 5: Technology Decisions Explained - Why We Chose What We Did

Every technology choice in custom software development involves trade-offs between performance, development speed, cost, and maintainability. For Endeverus, budget and timeline constraints heavily influenced our decisions, sometimes correctly and sometimes creating problems we had to fix later. The Django + Vue.js core stack proved mostly correct for this project. Django's built-in authentication, ORM, and admin panel saved approximately 200 development hours compared to building equivalent functionality in FastAPI or Node.js. Vue.js provided reactive UI patterns with a gentler learning curve than React, important since the founders wanted to eventually hire junior developers for maintenance without needing senior React expertise.

The trade-off was performance ceiling: Django's synchronous request model means Endeverus will never match the theoretical performance of async FastAPI under extreme load. However, according to benchmark comparisons of Python web frameworks, Django can comfortably handle 10,000-50,000 concurrent users with proper optimization, which exceeds Endeverus's growth projections for the next 3-5 years. We accepted this trade-off consciously, prioritizing faster development and lower maintenance burden over performance we wouldn't need for years.

Celery + Redis for background tasks was unambiguously correct. Payment processing, email notifications, and report generation needed to happen asynchronously without blocking user interactions. Celery's mature ecosystem and integration with Django made this straightforward, and Redis provided fast task queue management. Production data shows average task processing time of 2.3 seconds with 99.9% success rate over 8 months, handling 50,000+ background jobs monthly. PostgreSQL as the database was standard but worth noting: we considered MongoDB briefly for its flexibility with varying document structures for different project types, but PostgreSQL's JSONB fields provided enough flexibility while maintaining ACID guarantees that marketplace platforms require for payment transactions.

The AWS infrastructure decision (EC2 + S3 + RDS + CloudFront) was driven by the founders' preference for mainstream technology that would be easy to hire for in the future, over potentially cheaper options like DigitalOcean or Heroku. This added approximately $150 monthly to operating costs but provided scaling headroom and the full AWS ecosystem for future growth. We later appreciated this decision when integrating AWS Lambda for image processing and AWS SES for transactional emails: services that integrated smoothly because we were already in the AWS ecosystem.

Part 6: Results and Production Metrics - What Actually Happened

Endeverus launched in beta on October 15, 2023, with 47 initial users, the three founders plus 44 students and businesses they recruited manually. By June 2024, eight months post-launch, the platform had reached 10,000 registered users comprising 6,200 students and 3,800 small businesses, processed 2,400 completed projects totaling $1.2M in transaction value, and maintained 68% repeat rate where students completed multiple projects after their first. Platform performance after our architectural fixes showed 99.7% uptime over 8 months with only two minor outages totaling 4 hours, average page load time of 1.2 seconds, and server costs stabilized at $280 monthly plus $180 for S3/CloudFront, well within the planned operational budget of $500 monthly.

The payment processing system handled $1.2M in transactions with zero disputed charges that required manual intervention, though we implemented escrow features that held 15% of projects in dispute resolution requiring admin review before releasing payment. Student satisfaction measured through post-project surveys showed 4.3/5 average rating, with 82% reporting the project met or exceeded their expectations for learning outcomes. Business satisfaction averaged 4.1/5, with 71% reporting they would hire students again for future projects. The gap between student and business satisfaction revealed interesting insights: businesses wanted more vetting of student skills before projects started, while students wished for clearer project requirements from businesses upfront.

Technical performance metrics validated our architecture decisions post-refactor. Database query times averaged 45ms across all operations, API response times held at 120ms for the 95th percentile, WebSocket messaging (for the features that kept it) delivered messages within 200ms, and background jobs via Celery processed with 2.3 second average completion time. From a cost perspective, the platform achieved profitability faster than projected—the founders implemented a 15% transaction fee that generated $180K revenue over 8 months, against operating costs of $3,360 monthly (hosting + support + maintenance) totaling $26,880, leaving healthy margins for reinvestment in features and marketing.

The most surprising outcome was how students used the platform differently than founders expected. Original concept focused on short-term projects (1-2 weeks), but actual usage showed 60% of projects extended to 4-8 weeks as students and businesses built ongoing relationships. This required adjusting milestone payment features and project timeline tracking that we hadn't fully built out initially, consuming an additional 80 development hours in Q1 2024 but significantly improving user retention.

Part 7: Lessons Learned - What We'd Do Differently

After 12 months from initial discovery to 8 months in production, the lessons from Endeverus inform every subsequent marketplace platform we build at Glinteco. The most important lesson is to resist over-engineering real-time features. WebSockets seem like the modern, impressive solution, but they add operational complexity and cost that isn't justified unless instant delivery is genuinely critical. For Endeverus, messaging needed WebSockets: users expect instant message delivery in 2024. Project updates did not need WebSockets: users can't tell the difference between instant updates and 30-second polling for status changes.

On AWS S3 implementation, basic tutorials and documentation don't prepare you for production costs and security at scale. We should have consulted with DevOps engineers experienced in file storage optimization during architecture planning, not after we were already paying $600 monthly in unnecessary costs. The pattern we learned was that AWS services are deceptively easy to implement badly but require significant expertise to implement efficiently, similar to lessons from our analysis of cloud infrastructure mistakes.

For Django admin customization, the temptation to customize the built-in admin is strong because it saves immediate development time, but this creates technical debt that compounds over months. For platforms expecting to evolve significantly based on user feedback, which describes most startups, invest in a proper custom admin dashboard from day one. The 80 hours we "saved" by customizing Django admin cost us 120 hours fixing and rebuilding later, a net loss of 40 hours plus the friction of changing systems mid-flight.

On the positive side, our core stack choice (Django + Vue.js + PostgreSQL) proved correct for this project's constraints. The budget was $45,000, timeline was 8 months, and the founders needed maintainability with accessible talent pool. These constraints made Django's rapid development capabilities more valuable than FastAPI's performance ceiling we wouldn't reach for years. Trade-offs aren't mistakes if they're conscious decisions aligned with priorities. Mistakes are when you accept trade-offs you don't understand yet.

The founders' requirement to launch before the October academic semester created pressure that led to some of our mistakes—we rushed architecture decisions to meet timeline rather than taking time to research production patterns properly. However, launching on time was ultimately correct because the platform gained traction with students during the first semester. Delaying to December would have meant missing that cohort entirely and losing three months of growth. Sometimes shipping imperfectly on time beats shipping perfectly late, but you need to acknowledge and plan for the cleanup work that follows. We should have budgeted an additional $15,000 specifically for "post-launch refactoring" rather than treating our architectural fixes as unexpected costs.

Part 8: What This Means for Your Custom Software Project

If you're a founder evaluating custom development partners or a CTO reviewing similar marketplace builds, the Endeverus case study offers specific takeaways beyond generic "hire good developers" advice. First, your budget should include 20-30% buffer for post-launch architectural fixes that become necessary once you have real user data and traffic patterns. We spent $12,000 fixing our three major mistakes, which was 27% of the initial $45,000 development budget. This isn't unusual it's normal. The difference is whether you plan for it or whether it surprises you.

Second, when developers propose technology choices, ask them to explain the trade-offs explicitly, not just the benefits. We chose Django + Vue.js for valid reasons, but we should have been clearer with founders about the performance ceiling and the eventual need to optimize or potentially migrate pieces if the platform dramatically exceeded growth projections. According to industry research on custom software project success, projects that explicitly discuss and document trade-offs have 40% higher satisfaction rates because stakeholders have realistic expectations from the start.

Third, real-time features are expensive at scale in ways that aren't obvious during development. If your platform requires messaging, notifications, or live updates, ask your development team to explain their scaling strategy and cost projections at 1,000 users, 10,000 users, and 100,000 users. We learned this lesson expensively with WebSockets, and the pattern applies to any resource-intensive feature. The question isn't whether it works in demo, it's whether it works economically at scale.

Fourth, marketplace platforms connecting multiple user types have hidden complexity in business logic that exceeds the obvious technical implementation. Endeverus wasn't technically complexuser authentication, database operations, file uploads, and messaging are standard features. The complexity was in the business logic governing how students and businesses interact, how disputes get resolved, how payments get held and released, and how the platform prevents abuse while encouraging genuine collaborations. Allocate more time than you think necessary for requirements discovery and workflow mapping before writing code.

Conclusion: From Idea to 10K Users - But Not Smoothly

Endeverus went from three frustrated undergraduates with an idea to a working platform serving 10,000 users in 12 months. The journey wasn't smooth: we made three significant architectural mistakes that cost $12,000 and several weeks to fix, we underestimated certain complexity areas and overengineered others, and we encountered user behavior patterns that forced feature changes we hadn't planned for. But these struggles are normal in custom software development, not exceptions. The question isn't whether you'll encounter problems, it's whether you have partners who can fix them without derailing the entire project.

The Endeverus founders chose Glinteco because we were transparent about what we didn't know and committed to staying engaged after launch. When our WebSocket architecture failed under load, we didn't disappear or demand additional payment to fix our mistake: we absorbed the cost and rebuilt it properly. When AWS S3 costs exploded, we optimized infrastructure and reduced monthly costs by 70%. This is what partnership means versus transactional development where vendors deliver code and leave you to deal with production realities alone. For detailed overview of the complete Endeverus project including screenshots and feature demonstrations, visit our Endeverus case study page.

If you're building a marketplace platform, student network, or any system connecting multiple user types with complex business logic, we offer free architecture review sessions where we'll discuss your specific requirements, explain trade-offs between technology options, provide realistic budget and timeline estimates based on actual project data like Endeverus, and help you avoid the specific mistakes we made so you don't have to learn them expensively like we did.

Schedule your architecture review with subject "Architecture Review" and brief project description.