We Built An iOS Messaging App That Raised $6.3 Million, Here’s How We Did It

After 5 months of crazy hustle this company built an app that enabled their client to close a $6.3 million seed round. Here's how they did it.

Two years ago a client came to our agency, Alty, asking us to build an iOS messaging up.

It sounded like an interesting project, but the deadline was more than tight. While most sane companies would probably have shared a polite, but firm “no”, we decided to accept the challenge.

A challenge that resulted in 5 months of crazy hustle, a complete change in our communication framework, one very bold business decision and a closed investment round of $6.3 million for our client’s app.

Here’s how the story unfolded.

 

Mission possible, beat the clock

Hiring new staff or an outsourcing partner immediately is either impossible or will cost you a not-so-tiny fortune in the United States – that’s a no-brainer.

Our client was really lacking time and needed to start the project like last week. As our agency is based in Ukraine – a hub now boasting over 90,000 developers and a steady 20% annual growth in manpower, getting the right candidates on board for a rapid start wasn’t as difficult.

We always keep some extra hands within the company to jumpstart a sudden new project immediately, which also played to our advantage. Once we gave a pre-estimate quote and mentioned that we were ready to get things cracking immediately – the client signed the contract and things started to get hot.

 

Managing communications challenges with a distributed team

We were assigned with the UX and front-development part, while the client’s onshore team did back-end development. Keeping back-end development in-house was an important requirement for raising investment as it was deemed as the core technology.

 

https://unsplash.com/@anckor
Photo Credit: Julian O’hayon

 

First stage: UX and UI

As the first stage of the project had begun, we immediately encountered a few major bumps in our collaboration and communication framework.

 

  • Lack of proper requirements specifications

    In an ideal world you receive well-written documentation explaining each and every product feature, along with the general user-flow and other details on the functions. Yet, that wasn’t our case. We merely had some basic insights shared by the client.

    What we did: Instead of wasting precious time on composing tech specifications, we setup a series of Skype calls, where our designers posed a series of probing questions to get the a full idea of the app’s functionality.

 

  • Time zone differences and hiccups in communication

    An 8-hour time difference obviously creates some communication challenges, as our designers often could not get immediate replies and clarification on urgent points.

    What we did: We mutually decided to shift the working hours for the UX team to 12 a.m. till 8-9 pm. As a result, we got 2-4 overlapping hours per day when both parties were online to address urgent queries.

 

  • Building an efficient communication frame

    Without an established communication framework your project is doomed. You’ll find yourself building unnecessary or wrong features based on the initial scares specifications or miscommunication in general.

    What we did: We broke the initial task of creating the app’s UX into more bite-sized to-do’s and scheduled regular video conferencing (each 2-3 days) to report to the client. Based on the feedback, we could immediately make changes on the past features and simultaneously develop new ones. At the same time, we didn’t want the design team to get buried in conversations. The time zone difference played to our advantage in this case as our pros could let the creative juices flow and get things done fast without any side interruptions while the client was still snoozing.

 

The golden rule here is – everyone should be able to express ideas and suggestions during the specifically allocated hours. Other than that – it’s pure work time.

 

Organizing the workflow

 

  • Managing high volume task load

    When time doesn’t wait, most teams prefer to stash their to-do lists with ongoing chores and cross-off the tasks one after another. Yet, that’s definitely not the wisest approach as it often results into project bottlenecks (e.g. when someone’s waiting for a confirmation from the client and can’t move forward without it).

    What we did: We scheduled all ongoing tasks at least one week in advance to avoid any roadblocks. This way we managed to keep continuous development and a designer could switch to another task instead of getting caught up. This approach gave us a better project overview for the client, as they could quickly review which tasks were completed and which ones were due. We discovered that scheduling tasks well in advance actually saves heaps of productive time, compared to when each task is discussed on the spot.

 

  • Optimizing communication channels

    Obviously, you’ll have a lot of information to manage and keep on a hotkey access. While emails are still the most common communication channel, it’s definitely not the most convenient one. Letters get lost, your inbox gets cluttered, and retrieving information takes lots of time.

    What we did: Our top choice is Basecamp. It’s perfect for keeping all the project messaging in one place, assign tasks with deadlines, create dedicated project threads and to-do lists within etc. All the project data is kept in one place, has a clear structure, can be easily searched and accessed by everyone on board. For sharing and managing interactive prototypes we typically use Mockup.io (or similar solutions that are more preferable by the client). We love this tool as you can send out an app with static information, which you can share and present even via your smartphone.

 

The biggest challenge we faced as part of a distributed team was the miscommunication between back-end and front-end teams.

While we were dealing with the front-end part, the client’s team was all into back-end development. Yet, as it often happens, the cross-team communication was far from being ideal in this case. Back-end folks did not consult with our team and opted for open source to build the app’s architecture and save some time.

As our team started requesting API data and test-driving it, we discovered a huge nest of problems. Mainly with the queries, which the client’s part had to send to the server to retrieve data. After requesting additional documentation we received a scarce Google doc file with less than half of the queries and a majority of outdated ones.

To avoid similar scenarios we prefer to use Swagger. The tool is perfect for storing all the documentation and instantly testing all the queries with a real database.

 

The clock was ticking

After working in the common: “Found a problem – sent an email- spent the day waiting for reply – got “no time to fix” or “wrong issue” reply” pattern for some days, our team morale was dwindling and we started to realize we weren’t going to make deadline at such a slow motion tempo.

 

We decided to go extreme

Part of our team was dispatched to the client’s side (keeping in mind the full risk of staff poaching). We signed a no-poach agreement, bought the tickets, sorted out the visa paperwork and in two weeks two of our best iOS developers and one QA were working in the Silicon Valley.

This brazen move allowed us to finish the application’s key part and build better relationships between the two teams (which had a positive long-term productivity effect after our folks were back in the office).

 

The final pre-release hustle

The release date was lingering close.

We still had plenty on our plate and the electrified tension never really left our office. Yet, it wasn’t time to lose our grip, nor the work tempo.

Once you stop controlling the processes (as everything’s already crystal clear and talked over a thousand times) and managing other chores, things will go AWOL right before the release date.

You seriously don’t want that to happen.

Hence, the best option here is to stage demos after each completed sprint and present your work during this timeframe to the client. Why?

 

  • You gain valuable feedback and can deploy immediate changes

  • Your team feels praised and accomplished by the work completed and gets a tiny morale reboot though the project is still far from complete

  • Your client gains more control and no time is wasted in vain on any wrongdoings

 

Delivering results at break-neck speed

In the meantime, the client got an update from potential investors. They promised to commit to investing if the first product release was rolled out in mid-September, exactly when Apple presents their new products.

This announcement served as a great motivator to our team, though if being 100% honest our first thought was: “This is pure madness. We are not gonna make it!” At this point, we had to put on our collective big boy’s pants and throw all of our manpower into optimizing and forecasting prior to the release date.

 

https://unsplash.com/@helloquence
Photo Credit: Helloquence

At Alty we always track and analyze our work speed using Atlassian JIRA. It’s ideal for the team to monitor tasks, create bug reports and track time. The PM can track the progress, create graphics and forecasts and share those with the client accordingly.

Ideally, you need to put aside two weeks prior to the release for testing and troubleshooting. Obviously, we did not have that time. It was one week prior to the set release date and we were still cracking the key features. Two days before the deadline and we finished all the planned functionality. While the majority of features worked perfect, we still discovered a few flaws that should have been fixed before rolling out the release.

The client decided not to postpone the release date. From a businesses perspective it’s more important to roll out even a bugged release on time, rather than not doing anything at all. Especially, considering the investment and all the marketing at stake.

Fingers crossed, we uploaded the app to App Store and waited for the verdict. Some weeks later the client sent us over a link to the latest press release. The app had just raised $6.3 million in seed funding.

Our entire team was so happy as if someone gave us that money!

 

Wrap up: lessons learned

What you can learn from our experience in being part of a distributed team on a nerve-wrenching deadline:

 

  • Plan ahead

    Plan your tasks ahead of time to avoid project bottlenecks and blocked tasks. Basecamp and JIRA are two great tools to keep everyone organized even if you are a small team/agency.

 

  • Create a comms blueprint

    An efficient communication blueprint is key. Create the routine, which works for both parties and stick to it. Schedule regular sync calls, adjust working schedules for more overlapping hours and keep time gaps for work and nothing else to stay on top of your productivity game.

 

  • Conduct weekly product demos

    Schedule weekly product demos to avoid wasting time on unnecessary functions and any other mishaps. This way you can sustain continuous project development – fix and add new features simultaneously.

 

  • Get everyone at one table

    Get everyone in one office if things get hot and you need immediate replies and instant feedback. Take the risks when needed if you feel like it can move your project forward!

 

This article has been edited.

Lolita Rogers is the Marketing Manager at Alty.software  with 4 years of experience in IT combining her technical skills and professional background to bring a higher-level perspective into her work. Currently, she shares the company’s experience and vision on hot topics from the app development world. Connect with @RogersLoli on Twitter.

In this article