How We Failed at Our Own App Development (And Why It Made Us A Better Agency)

If you run a service business (mobile app development, software development, whatever), here is my advice: Build your own products.

I tried it once, and it was a tough experience, but also an eye-opening one: it told me everything about why app development projects fail.

I started that project not as an app development service provider, but as a client of my own company. Soon, I realized something I didn’t know before: working with my team was not as smooth as I expected.

Development ran behind schedule, communication dropped off, and I felt increasingly frustrated because this time I was the one paying for the weeks of experimenting.

That case not only highlighted all my screwups as a service provider (I give a full list below), it also taught me a lesson: You’ll never truly understand your customers until you’ve been in their shoes.

Even if you think you do understand them and know their pain points, without building your own app, you are stuck on one side of the business. And that is a dangerous place to be.

Our first internal mobile app development: How it started

At Chili Labs, we spent years as a pure service company, providing mobile app development to local and foreign businesses. We built custom apps, delivered code, and moved on to another project.

Prior to 2018, we tried to build our own things, but, to be honest, never gave them enough love. They were more like side quests.

Then, in 2018, we started building Bookla, Crochet App, and a handful of other internal tools. That turned me from CEO of an app development agency into a client.

I thought I was prepared.

Before, I was an experienced project manager for app development and had delivered over 20 projects (back in the day, now it is much more, covering domains from lifestyle to FinTech).

My expertise included all stages of the app development lifecycle and I figured, "If not me, then who else will be efficient?"

I started the task with the best practices of app development: created the perfect plan, set up the Jira board, and split the tasks. I treated it exactly like a high-budget enterprise client.

It failed hard.

Our processes were way too big for a startup environment. I was frustrated at every step because the estimated app development timeline was delayed. We were diving into details where it wasn't necessary.

Instead of the fast market launch we stuck dealing with cost overruns and project scope creep, not to mention the extended timeline. The project took months instead of weeks and I struggled working with us.

It sounds harsh, but it’s the truth - when I stepped into the client's shoes, all the friction, delays, and "technical excuses" showed up in a completely different light. It was a massive wake-up call that forced us to rebuild processes from scratch.

At that time, I didn’t just get to understand the common mistakes when building a mobile app, I reviewed the anatomy of each failure at the granular level and shared this bitter lesson with everyone who either manages an app development project themselves, or wants to be more educated in choosing the right app development partner.

Here is what we learned from that mess.

App Development Finding #1: Talent Isn't Universal

One of the biggest mistakes we made in managing app development projects was thinking that a "good developer" is a good developer for every project. They aren’t.

Through building our own apps, we realized that people have different professional DNAs.

The solution: We started categorizing our team based on where they actually excel:

The Startup DNA: These are the people who are great at experimenting. They are fast. They are okay with building something "messy" if it means hitting a deadline or testing a hypothesis. They enjoy the pitch, they share ideas, and they don't get hung up on perfection when the goal is survival.

The Enterprise DNA: If you put a "messy but fast" developer on a banking platform or a massive enterprise system, you’re asking for a disaster. Those projects need people who are strict, obsessed with code quality, and disciplined. They don't "experiment"—they build systems that cannot fail.

Now, when either working with enterprise clients or startups, we match the team's DNA to the project. If a developer is great at coding but bad at pitching or experimenting, they aren't the best to be on a startup project. If they love building fast but write messy code, it is wise to keep them away from the banking platforms.

Pro tip: if you are a business owner trying to choose the right app development partner, ask your team about how they distribute talent and if they understand the business side of your project.

App Development Finding #2: Messy And Fast Beats Slow And Perfect

In a startup, silence is the enemy. Negative feedback is, actually, amazing at an early stage. It tells you if your idea is viable. If you wait months to make it "perfect," you're just wasting money.

In the service business, we are taught that you can’t build until you know exactly what you’re building. But in a startup, you have to build an approximate solution just to validate it.

The solution: With startups, there’s sometimes no space for estimating all the software delivery risks - you must be okay with doing it "dirty" to see if there's traction.

Pro tip: if you run a startup and a third-party team handles app development, ensure they understand you are ready for the quality tradeoffs in favor of time. Also, draw your red lines, too.

App Development Finding #3: Universal Workflow Is a Bad Idea

I spent years leaning towards process unification, where you have only one process for everything. The usual process is “Backlog → In Progress → Code review → QA → Client Review → Deploy → Done” – an app development project checklist you use to tell your client at which point you are now.

It doesn't work for startup project management.

Heavy processes like regression testing or deep system analysis are an overkill for an MVP. If you’re building a bank with millions of users, you test everything. If you’re a startup, your lifeline is shipping fast, not making sure a developer won't be "ashamed" of the code in five years.

The solution: In a startup environment, you must remember one thing: “You will rebuild it properly once you find Product-Market Fit.”

Pro tip: as a client, your responsibility in the app development project is to know the workflow of the team, to not only check up with them, but to manage the depth and duration of certain stages.

App Development Finding #4: The "Trust Me" Attitude Is Bad for Business

When I became the client, I realized where we were lagging.

As an app development agency, we often expected clients to just "trust us". We didn't communicate enough of the "why" behind what we were doing. We expected them to trust that we knew what we were doing and not involve them in our day-to-day.

We have perfectly capable project managers, designers, developers, QAs, a team of highly skilled professionals, who know what they are doing. While this may work for the large project with defined scope, it fails for the startup.

Being on the receiving end of our own old processes frustrated me a lot. And if it frustrated me, it frustrated our clients.

The solution: In startups, you need clear client developer communication, transparency, reporting and making a client a part of project governance. Because on their end, there is lost revenue as the product is not yet on the market, payroll to pay, market share lost to competitors who move faster.

Pro tip: if you are a startup owner you have the right to become the part of the project, taking part in the daily decision making and being explained how a tech detail will influence your product and project outcome.

The Key Takeaway: Managing the Project From the Client’s Perspective

We used to have internal discussions about why a project was taking so long or why a certain feature was so difficult to implement. As the "client" for our own apps, I felt that frustration firsthand. It made me realize that our communication sucked. We were missing steps. We were ignoring the business reality of our clients in favor of technical "correctness."

After being in the skin of the client, we changed our specialization. We changed how we pitch. We changed how we experiment. We stopped being a vendor and started being a business partner because we finally understood what it feels like to have your own skin in the game.

Now, we target all the concerns from the start: discussing risks, expectations, planning milestones with the respect to the client’s business needs. We know exactly which points will turn into the pain points and how to not allow this to happen.

So, my final advice? Build something.

I advise every service company, busy in app development, to build something of their own at least once a year. Not for the revenue—though that’s a nice bonus—but to stay fresh.

You need to see the user journey of your own client. You need to feel the annoyance of a delayed sprint. It will help you remove the rot in your own company, fix your broken processes, and ultimately, become a company people enjoy working with.

And if you are a business owner in search of an app development partner, ask your candidates how they manage talent, communication, and project milestones in line with your daily business needs. Asking and not asking is the fine line between the project’s success or failure.

If you have an app idea to discuss and want a clear vision of how we will address your business needs during development, contact us for a chat!