You don't need to read code to manage an app project. You need a written scope, a plan split into milestones, a weekly rhythm with the team, a habit of testing every delivery yourself, and control over your accounts and code. The rest is communication.
The real risk in app projects
Owners who are not technical often think their weak point is the code. In my experience coordinating web and mobile app projects, at a software company and today on the CHAQT app, the code is rarely where projects break. They break in the space between what the owner meant and what the team understood.
The good news is that this space is managed with clear writing and steady follow-up, not with programming.
1. Write the scope before you talk about price
Before you ask any developer for a quote, write one document that answers:
- Who is the app for? One or two types of users, described in plain words.
- What must they be able to do? A list of actions, such as sign up, search for an expert, book a session, pay.
- What does each screen show? Even rough sketches on paper help.
- What is not included in the first version? This line saves more money than any negotiation.
When two developers quote on the same written scope, you can compare their offers. When they quote on a conversation, you are comparing guesses.
2. Split the work into milestones you can see
A plan that says "the app will be ready in four months" gives you no control. Ask for phases that each end with something you can open and use:
- Sign-up and the main screens with sample data
- The core action of the app working end to end
- Payments, notifications and settings
- Testing, fixes and store submission
Tie payments to milestones you have tested, not to dates.
3. Set a weekly rhythm
Agree on a short weekly update, written, at the same time each week, answering three questions:
- What was finished this week?
- What is planned for next week?
- What is blocking the team, and what do they need from me?
The third question matters most. Many delays come from a developer waiting for an answer, a logo or an account that only the owner can provide.
Use one shared task board, such as Trello or Lark, so every request and every bug lives in one place instead of scattered chats.
4. Test every delivery yourself
You don't need technical skills to test. You need the scope document and patience:
- Go through each user action in the scope, step by step, on a real phone
- Try the wrong things too: empty fields, a bad connection, going back mid-way
- Write each problem with what you did, what you expected and what happened, plus a screenshot
A clear bug report gets fixed. "It doesn't work" starts a long conversation.
5. Keep control of what belongs to you
This is the step owners regret skipping. Make sure that, from day one:
- The App Store and Google Play developer accounts are in your company's name
- The code repository, the hosting and the domain are under your accounts, with the team invited
- Passwords and keys are shared through a proper tool, not chat messages
- You receive basic documentation at each milestone
If the relationship with the developer ends, you should be able to hand the project to someone else within days.
6. Turn feedback into tasks, not discussions
After launch, users will send opinions, complaints and ideas. Collect them in one place, group them, and turn each group into a clear task with a priority. On CHAQT, gathering feedback from experts and users and turning it into product improvements is a regular part of my work, and the discipline is the same for any app: one list, ranked, reviewed every week.
When to bring in a project manager
Managing developers yourself is possible, and this guide is enough for a small project. Consider a technical project manager when:
- The project has more than one developer or an outside agency
- You can't spend several hours a week on follow-up and testing
- The project is already late and nobody can tell you where it stands
- You are building a second product while running the business
A good project manager does not replace your decisions. He makes sure they are written down, built correctly and tested before they reach your users.
If that's where you are, see how I manage technical projects.