Green and Red Flags When Building Your First App

Working with software developers for the first time can feel like diving into the deep end of a pool without knowing how to swim. Many unfamiliar terms, tools, and processes can make you feel overwhelmed. But don’t worry! This guide will help you spot the “green flags” (good signs) and “red flags” (warning signs) at different stages of the development process to make your journey smoother and more successful.Whether you’re hiring a small business or a large corporation for your app development, you are running a risk of misaligned goals, miscommunication, and, eventually, lost profit. Choosing the right team is key to success; that’s why it’s important to pay attention to some factors that can mean a good or a bad sign and save you time and costs in this endeavour.
‍

4 Development Phases and Important Indicators to Look out For

The mobile app development process generally consists of 4 development phases:

• the Pre-start Phase where the foundation for the app is laid out;
• the Development Start where the main activity begins;
• the Inspection or checking of the progress phase at a two-month mark;
• and the Evaluation phase at around 6 months after the project kick-off.

Each of them has its intricacies and pitfalls, and, as a business owner, you have to be aware of them and the signs to look for during every stage. Let’s take a look at the most common green and red flags inherent to the phases.

Phase 1: Pre-Start – Laying the Foundation

Although the pre-start phase doesn’t do a lot with the app development, it still can’t be avoided. It includes all the main things you have to agree on before the coding begins. Think of it as laying the foundation for a house. A strong foundation sets you up for success, while a shaky one can cause problems later.

Green Flags or Things to Look for Before Starting Development

• ‍Document with Initial Requirements and Scope of Work. A clear document outlining an app idea, including all the features, is like a road map for your journey. It keeps you and the team on the same page, ensuring you pursue the same business goals and share the same expectations from the very start.
• Suggested Wireframes or Figma Designs. The app usually begins with designs, including user interface design and sometimes the admin panel. Wireframes — simple sketches of app design — show you how the future app will look, while Figma designs are more detailed visual representations of the app's appearance. Early on, these visuals help the team understand what the final product will look like.
• Feature Breakdown with Rough Estimation. This document lists all the features you want in your app, along with an estimate of how much time and effort each will take. Knowing this upfront helps in planning and budgeting and gives you a roadmap to rely on.
• Infrastructure/Maintenance Costs for the App. A detailed proposal or an offer will include the main cost of app development and associated costs (server fees, maintenance, updates, or sometimes even marketing efforts). This ensures as few surprises as possible when it comes to the development cost and budget overrun.
• Defined Milestones. The key points in the project are called milestones. They represent the specific goals that are met in the development process. They help you to keep track of the project and give you a sense of progress.
• First Launch is Planned Within 2–4 Months. Receiving a plan for launching a basic version of your app (called a Minimum Viable Product or MVP) within 2-4 months is the greenest flag and a good sign that the team is focused on delivering results quickly.
• Proposals to Minimise MVP Scope. Experienced and trustworthy mobile app developers will suggest ways to narrow down the MVP to just the most important features and exclude the unnecessary functions, so you can get your app to market faster.

Red Flags or Warning Signs to Watch out For

• Proposed MVP Launch in 12 Months or More. Watch out if the app developers promise to launch the first version of your product in a year or more. It might mean the development team you’ve chosen doesn’t really understand what an MVP is all about. An MVP should be a basic version of your product with just the core features — something you can launch quickly (usually within a few months) to test with real users and gather user feedback. If the expected timeline is a year or more, there are two options: either they are trying to build something too big and complicated, or they are looking to get more money out of your pocket.
• No Feature Breakdown. If there’s no detailed list of features with estimates, this could mean that the team hasn’t fully understood the project or is poorly organised. This will inevitably lead to miscommunication and misalignment, making it so much more difficult to make sense of what is going on.

Phase 2: Start of Development – Kicking Off the Project

After you’ve agreed on the main terms and conditions and made sure everyone is aware of the plan, it’s time to start the app development process. This is when the main phase begins, and you get an opportunity to test the coding skills of the chosen app development company. During this time, it’s important to keep an eye on how things are progressing and set clear milestones or inspection times when you can check on the project's progress.

Green Flags or Signs of a Healthy Start

• ‍Developers Use Repositories. Repositories like GitHub, GitLab, etc. are basically like digital lockers where the software development team stores all the сode. Within these lockers, the code is safely backed up, ensuring that all the team members can access the latest version, track changes in code, and collaborate.
• CI/CD, Build Automation, Build Pipeline in Place. These are fancy terms for automated processes that help build and test the app quickly and efficiently. They can reduce human errors and make sure that new code doesn’t break existing features.
• ‍The Team Skillfully Uses a Task Management System. A task management system like Jira, Trello, Monday, ClickUp, etc. is an internal organisation tool that comes in handy for every type of project. Within it, clear tasks, terms of fulfilment, roles, and deadlines are set to keep track of the progress and stay on the same page. However, just having it in place is not enough; you have to see that the team updates and maintains it, resolves the fulfilled tasks, and sets the new ones.
• ‍Diagrams Are Documented. Diagrams like DB diagrams and System Diagrams help visualise complex systems and help show how different parts of the app interact with each other. They are used both within the team and every interested party.
• OpenAPI or GraphQL Usage. These tools are used for building APIs (the way of communication between the different parts of the software). If you see these tools in use, it means the team is up-to-date with industry best practices and has the necessary experience to make the parts of the app work together.

Red Flags or Things to Be Wary Of

• No Repositories Usage. If the team doesn’t use repositories, it speaks of poor code management practices. There isn’t one place where the code is stored and updated, which can lead to issues like lost code or difficulties in collaborating. For you as the business owner, it can mean more downtime spent on fixing the bugs and looking for the latest code version instead of moving according to the estimates.

Phase 3: Two Months into Development – Checking the Progress

Two months of development time is usually enough to start seeing some tangible results of the work done. Here’s what you can check:

Green Flags or What You Should See After Two Months

• First Internal Builds Available for Testing. Internal builds are early versions of the app that you can already test. This shows that development is moving along, and you can start giving feedback to improve the app.
• ‍System Is Interconnected (Mobile/Web App to Backend). Different parts of your app – like the front end and back end, are connected and communicate with each other.
• ‍A Few Fully Operational Screens with Minor Issues. Some parts or features of the mobile app are working, even if there are still minor bugs. This means that the developers are making steady progress and providing concrete results that can be used to gather feedback.
• ‍New Features Rarely Break Other Parts. If new features are added without breaking or damaging existing ones, it means the development process is stable and well-managed.
• ‍You Have Access to Repositories and Accounts. You should have access to the repositories and any necessary accounts like Google, Apple, Firebase, and AWS at all times. This ensures transparency and makes it easier for you to track the progress.
• ‍Team Tracks Performance in a Task Management System. All work is documented in a task management system, and you have access to it, making it easy for you to see what’s happening and how fast is the process moving along.

Red Flags or Signs of Trouble After Two Months

• No Visible Progress Yet. If you haven’t seen any tangible results or real progress, it might mean delays or miscommunication within the team, resulting in more downtime for you and a postponed launch date.
• ‍Progress is Shown Only from the Developer’s Machine or Recorded Videos. After a few months, you should be able to see an MVP or a version close to it. If the developers only show you progress via their own machine or videos, it could mean they’re not ready to let you see the real product yet — which could be a bad sign.
• ‍No Access to Any Sources/Accounts. Not having access to key accounts or code repositories could mean a lack of transparency, unless it was agreed upon in the contract before the development project.
• No Use of Task Management System. If the team isn’t using any task management tool, it might indicate disorganisation and lack of direction. However, if the team is using the task management system, but it stays “on the paper” without you seeing any real progress, they might as well not be using it. It is a clear red flag.

Phase 4: Six Months into Development – Evaluating the Outcomes

In most cases, especially when it comes to simpler mobile apps, the application development process during this phase is close to an end or the app might have been launched already. But in any scenario, six months in, you should have a clearer picture of how things are going. Here’s what to look for:

Green Flags or Positive Signs at the Six-Month Mark

• Customers are Happy Using Core Functionality. If real users are using your app and user engagement s through the roof, that’s a great sign that things are on the right track. After all, a good user experience is what makes an app successful.
• ‍You Are Happy with the Team and Their Progress. You already have a good grip on working with the team and checking on their work. A good working relationship leads to better results, and your satisfaction with the team is as important as the user’s satisfaction with the app.
• ‍Team Understands Domain and Business Goals. By this time, the developers should understand the business side of your project and how the app fits into your overall goals. This will ensure their proactiveness and might cut the time for project discussions since they already understand what you need.
• ‍Team Is Proactive with Business Ideas. If the team suggests new ideas and improvements, they understand your requirements and are invested in your success.
• ‍Regular Releases. Frequent updates (at least once a month) mean the team is continuously improving and adding to your app, making the user journey more convenient and straightforward.

Red Flags or Warning Signs at the Six-Month Checkpoint

• Team Doesn’t Seem to Understand Domain and Business Goals. Six months is enough time to get to know your business better. If this isn’t happening, misaligned efforts and a product that doesn’t meet your needs are a few of the things you might expect.
• ‍New Features Frequently Cause Issues. If newly released features break or damage other parts of the application, it may suggest unstable development practices. It takes time and effort to fix them, which can be spent on further development instead.
• ‍Difficult to Release New Versions. If releasing new versions is challenging, it could mean there’s a lot of technical debt or process inefficiencies. This can hold the whole work back and lead to lost profits.
• ‍No CI/CD (Build Automation) or Tests Yet. Without automated testing or build processes, the project could face long-term problems. Additionally, if the simple processes aren't automated, this can eat up your budget since it’s done manually in this case.

General Recommendations: Tips for a Successful Collaboration

• Have a Single Technically Responsible Person (CTO, Technical Lead) who will be accountable for the technical aspects and ensure smooth communication between you and the developers.
• ‍Ensure Clear Communication Between Business and Technical Sides. A good technical lead will help translate business needs into technical requirements and vice versa, keeping everyone on the same page.

Conclusion

Working with software developers for the first time can be daunting, but by keeping an eye out for these green and red flags, you can navigate the process more confidently and effectively. Remember, good communication, clear documentation, and regular progress checks are your best allies in creating a successful software product. Happy developing!

‍