How to Screw Up an App Project

By Abhinav Girdhar | Last Updated on May 26th, 2023 9:33 am | 4-min read

Over the last 10 years I’ve worked for dozens of clients, building dozens of professional app projects: iOS apps, Android apps, web apps and websites. Most projects went without a hitch, but other app projects went downright disastrous.

I’ve learned from successes, but I’ve learned much more from mistakes. What’s interesting is that a project-gone-bad isn’t typically caused by one big mistake, but by lots of small mistakes over a longer period of time. It’s not one bug that spells disaster, but neglecting quality control since the beginning of a project.

In this tutorial, I’d like to walk you through 3 of these slow project killers. The idea is not to help you avoid mistakes, but to help you see them in advance and respond appropriately. Mistakes are part of work, but it would be great if we could take the sting out of them!

The advice in this tutorial is suitable for both freelance developers and employed developers, for both solo devs and those working in teams, and these mistakes don’t limit themselves to just mobile app development. These mistakes are everywhere!

Avoid “Scope Creep”

You’ve started an iOS app project for a client, and you’re 3 months in. At one point the client calls you up and says: “Look, I really like that button on screen B, but can you move that to screen A?” You say: “No problemo!”, and your project scope goes down the drain…

Project scope is like watching your app project through binoculars. Some tasks are in scope, and others are outside the scope. And as a project progresses, your client or boss has more insights about the project.

Maybe they have second thoughts about a feature, or heard about a new technology that you absolutely must use in their app. Most clients also feel ownership over an app project, even when you’ve taken it out of their hands, and as a result want to “steer” the project according to their own wishes.

At this point you might ask yourself: “Is that a problem?” So, let’s look at what happens with app projects that go out of scope:

• App development projects aren’t so forgiving when it comes to moving components. You can’t just put the engine in the back, when you designed it to go in the front. And you can’t decide to rotate your new kitchen 90 degrees halfway through remodeling.
• Changes cost time and money. Extra time that’s unpaid comes out of your own pocket if you’re freelance. And if you’re employed, you might cheat your employer out of charging extra for more work. On top of that, more work puts more stress on your deadlines. At worst, you might miss the deadline.

OK, let’s play devil’s advocate here. Let’s say you’re a nice developer and you agree to do some extra work that’s out-of-scope. It doesn’t take that much time anyway – maybe 1 or 2 hours. Sounds reasonable, right?

You implement the extra feature, but at the end of the project you discover that you’ve made a mistake. The extra work you did isn’t compatible with some other feature that was already agreed on. Instead of 1 or 2 hours, you now have to spend 2 days rewriting the code!

So, how do you avoid going out-of-scope? Here’s how:

• Explain to your clients and/or employer that making changes after the design has been agreed upon cannot be done. It will delay the app project and cause extra costs for the parties involved.
• Tell your client you wish to be flexible, so requested changes will always be considered but often can’t be honored. Help your client or team to spend extra time designing the project, to avoid needing to change things later on.
• When you’re charging for your app projects, i.e. if you’re freelance or help your boss make a quote, always work with a 10%-30% margin. This margin helps you buffer against mistakes, changes, and unforseen events. And if you’ve got room in the budget, you can delight your client with a “free” extra feature.

Let’s move on to thrashing!

Avoid Thrashing Late

In the previous section we’ve already discussed what happens when an app project goes out-of-scope, and how you can avoid it. Thrashing is a related phenomenon, but the problem is that you can’t always avoid it.

Thrashing is changing things on a project. And thrashing late is downright disastrous for a project. You want to avoid thrashing late at all costs.

Seth Godin tells a story about how they dealt with thrashing in a game development project. Here’s the gist of it:

• The game project that the company developed had a hard deadline. If they missed the deadline, the project would go bust 100%.
• Everybody on the team was given a red or green sticker.
• If you wore a red sticker, you were on the critical path towards the deadline. If you didn’t or couldn’t do your work, the deadline would be missed.
• If you wore a green sticker, your job was to help the people with a red sticker to do their work (or get out of their way).
• The goal was of course to reduce the amount of red stickers, i.e. reduce the critical path, so the project would clear the deadline.

When you’re a developer working on an app project, you’re on the critical path. So, when a client or co-worker or boss comes to you and wants to increase your workload on this critical path, they’re surely jeopardizing the deadline of the project.

Unfortunately, thrashing just happens. Developers and their teams are creative people, and many app projects are creative endeavours. You meet with co-workers and bosses, and new ideas form, and suddenly you have an idea that must make it into the project.

The solution here is to thrash early. Here’s how you do that:

• Spend enough time at the start of an app project to discuss, design and listen. Help your client or your company’s client to see what the project is going to look like, and engage them in the process.
• Be very clear about the no thrashing late rule. Thrashing late is the same as sabotaging a project. This must be communicated early on, so you can help manage expectations of clients and bosses.
• A good manager helps developers do their best work. If you have a manager who hassles you to put in an extra feature, make it very clear that they are delaying the project.

You’ll hopefully recognize that every one of the disasters in this tutorial has something to do with communication and managing expectations. Inadequate communication weaves like a red thread (or tape) throughout screwed up app projects. Communicating clearly and timely is an asset to any app project, and an invaluable skill for any app developer.

Don’t Skimp on Documentation

A technical design forms the basis of a successful app development project. Documenting your code, and technical decision you made, is part of that design process.

Here’s what I consider good design work:

• Creating mockups of an app development project
• Describing in detail what the software needs to do
• Describing in detail “what happens when you click there”
• Investigating tools, technologies and platforms and documenting decisions
• Discussing what alternative tools and tech you could use, but won’t
• Describing what’s needed from your client, stakeholders, and teams at what point (such as graphics, data entry, accounts, licenses, etc.)
• Setting up a project planning, milestones, and deliverables
• Writing code comments, i.e. for functions, classes, properties, components, and especially at points where some additional explanations about your code are needed
• Investigating and deciding on what technical architecture and design patterns to use

You wouldn’t build a house without a detailed, measured blueprint, would you? You can’t just move a support wall after discovering that the plumbing prevents you from building it where you wanted to. The same goes for app projects: you need to think before acting.

I doubt that any developer will ever start work without doing some design, but what’s often needed is asking yourself if the designs are sufficient.

You can use proper functional-technical design as the foundation of an app project, something that you can go back to when decisions need to be made. Design and documentation can serve as discussion points for communication with clients and your team. And when changes are required, you can consult your designs first before hacking the project.

One of the benefits of a crystal clear functional-technical design is that the client, or your boss, can sign off on it. They understand exactly what they’re going to get when the app is finished. This means they can thrash however they want during the design phase, but not after. In my experience, this gives stakeholders the ownership over the project that they seek, without risking resource intensive changes later on.

Writing documentation isn’t the most sexy part of app development. Designing software is interesting though, and a developer who can take on a project’s design, architecture and planning is often valued better than a developer who merely codes.

Further Reading

In this tutorial, we’ve discussed some of the pitfalls of app development projects and how to avoid them.

A successful app project goes beyond a developer who codes, and a manager who manages. It’s about communication, your mindset, deliberate design, setting expectations, and keeping promises.

I think there’s a great opportunity for the developer who seeks to build great products, and wants to go further than merely writing lines of code.

Create Your App Now