The discussion about modern web architecture focuses on microservices, distributed systems, and cloud-native technologies. These methods work well for large engineering teams, but they can create problems for small teams with different needs. At Orcta Technologies, we are building a delivery platform for Tarkwa, Ghana, with a small team and a limited budget. We chose specific tools: Django, PostgreSQL, Docker, and a single VPS. We decided against a service mesh and Kubernetes, opting for simplicity. This talk shares the engineering lessons we are learning while working under these constraints. We will discuss: - PostgreSQL at a small scale: why indexing and query design are critical when you cannot rely on hardware. - Deployment simplicity as a reliability strategy—how a single Docker-based VPS can work better than a fragile multi-service cloud setup for our small team. - Django's defaults as a helpful feature: how its ready-to-use design allows our small team to move quickly without creating internal tools from scratch. - Performance tradeoffs on limited hardware: what issues arise first, how to anticipate them, and how to solve them cost-effectively. - The cost of premature complexity: why keeping our architecture simple is a clear engineering choice that often boosts reliability. You will leave with practical patterns useful for any small team creating real products within real limits and a method for assessing technology choices based on your actual situation, not just what someone else has written online.

Co-running GDG UMaT, a developer community at the University of Mines and Technology in Tarkwa, Ghana, taught me early on that what works elsewhere may not work here if you ignore local realities. Every community has its own rhythm, shaped by its members' needs, limits, and time. Copying another team's plan often misses the point. In five minutes, I'll share three things no one warned me about before I started: - Listen to actions, not slogans. Listen closely, yet watch actions more than words. What someone says differs from what drives them daily. Follow where the energy flows and adjust without making a fuss. - Be a force multiplier, not a gatekeeper. This is what sets apart communities where people wait for permission from those where people build freely. - Vision needs support. A shared repository, a communication channel with unwritten norms, and a guide for new members help them take their first step. If you run a developer community, share the role, or are thinking of starting one as a student at an African university, this talk is for you.