Which methodology should I choose for my new project?

03 Tem 02:39

Starting with a planned approach is a good choice, especially considering a 3-4 month timeline and team experience. Trying flexible methods is worth it, but maintaining stability in the first version is crucial. Scrum, a version of Agile, is ideal here—working in sprints and delivering a minimum viable product at the end of each iteration boosts motivation and makes the process trackable. For a three-person team, 2-3 week sprints are quite suitable, keeping everyone focused and allowing for immediate integration of feedback as months progress. Initially, avoid unnecessary complexity by focusing on an MVP (Minimum Viable Product). Keep the project architecture simple, as time is limited—opting for microservices could lead to wasted time. Along with the methodology, tool choices are critical: set up task tracking with GitHub Projects and automate testing/deployment with Firebase or a self-hosted CI/CD (e.g., GitLab Runner). I think the most important thing is to have good planning from the start—avoid the "set-and-forget" mode and clarify every step. Time pressure can lead to setbacks, so discipline is key.

03 Tem 05:29

For a 3-4 month timeline with a small, experienced team, I’d lean heavily toward Scrum with two-week sprints. It gives you enough structure to avoid the "shoot first, aim later" pitfall of pure waterfall while still providing regular checkpoints to adjust scope or re-prioritize. Since you’re all seasoned devs, the sprint rituals (planning, review, retro) won’t feel like overhead—they become moments to sync on blockers before they snowball. Plus, the demo at the end of each sprint forces you to ship something tangible every fortnight, which keeps scope creep in check when deadlines loom. What often trips teams up in three-person shops is trying to shoehorn Kanban or Full-Scrum Hybrid when they only have so many hands. Skip the bells and whistles—retrospectives, burndowns, Jira tickets, whatever—keep it to the essentials: a backlog, a 30-minute daily stand-up (stand if you must), and a short planning/review. If your project is greenfield with unknowns, spend the first sprint on a thin slice of the riskiest feature; if it’s mostly known, jump into build-but-leave-room-for-polish mode. The middle ground (moderate complexity) usually hides subtle surprises—UI edge cases, API rate limits, App Store review surprises—so default to lighter weight unless you see red flags early.

03 Tem 06:03

I also managed a 3-month mobile project with a 4-person team before. Even though everyone on my team was experienced, we still got stuck in planning hell and wasted a lot of time. Then we realized in the first sprint that we weren’t used to the "suck it and see" approach, so we decided to cut the MVP down to 2 months and started gathering feedback, which made optimizing the rest a lot easier. I actually preferred the Agile Scrum version—we stuck to 2-week sprints, did demos at the end of each, and updated priorities. Since time was tight, I kept the daily stand-ups short, making sure they didn’t go over 10 minutes. About a month before the hard deadline, we cut unnecessary features to avoid scope creep and collectively decided, "Good enough." The project ended up finishing 2 weeks late, but the client was really satisfied. Your team might benefit from a similar approach, especially with a tight 3-4 month timeline.

03 Tem 06:54

Try a lightweight version of Scrum with two-week sprints. This way, you can plan effectively while continuously gathering feedback and making quick adjustments.

03 Tem 09:48

Absolutely, let me share my story because last year we actually built a project just like yours using Angular + .NET Core. We were three of us developing internal tools for a fintech startup, and we had to finish it in 4 months. At first, we thought, "Agile’s speed and flexibility are perfect for us," so we started with Scrum—sprint planning meetings, you name it. In the end, we were completely burned out because every sprint ended with the product owner saying, "But we were supposed to add this function." By the two-month mark, the stress of missing the deadline was hitting rock bottom. We didn’t go full Waterfall—we called it "Plan or die!"—but we switched to a hybrid approach: 2-week sprints, but with rigidly frozen functional definitions. We even added a risk buffer week—your team of three is actually perfect for planning buffers like that. This way, we balanced flexibility with predictability. In the end, we finished the project in 3.5 months, and the client didn’t even ask for the tiniest function change.