Building your startup’s software product with DECODE

We get it. You’ve spent three years working on your pitch and business plan, and seed money and crowdfunding, and you are finally ready to make your software product idea into reality. 

You’ve connected with several companies, studios, and developer teams and got back wildly different offers.

How do you pick the one that will be with you through thick and thin?

This article explains how to evaluate your potential development team and outlines how we do it at DECODE, starting with making sense of cost estimates and following steps you should expect from any agency worth their salt. 

Choosing the right partner for your startup

Building a startup is not easy. We’ve built a few for other people and have also started a product of our own.

Shake is a SaaS mobile app debugging platform which saves time, frees costly devs to do some real work, and increases debugging speed.  

Today, we have hundreds of active users and a monthly recurring revenue which increases every month.

To get to that stage, we have passed through thick and thin on this project, now two years running.

It took us a year to develop the version with which we entered the market, and now over a year later we iterate and adapt Shake to the wishes of users.

Our startup experience spans multiple industries and application niches: we developed Fling, a messenger that currently passed 6 million downloads due to most advanced features we designed for real-time communication.

Google featured the iOS version of their Chromecast emoji puzzle game Emoji Party.

For Vitastiq we handled iOS and Android mobile apps working with their hardware pen, which customers use to scan their vitamin and mineral levels. 

Because of the first-hand experience, we went through with other startups and on our own, we are not just giving empty promises and tips but real knowledge on how things must be done in order to achieve success.

Our clients liked our references first, but before they chose us, we had to give them a cost estimate for our involvement—which is where you probably are right now. 

Making sense of your cost estimate

Let’s say you come up with the idea to make a software product for food ordering—something like Grubhub, Doordash, UBER EATS, etc.

The assumption is that no agency has such a solution in their pocket, it’s needed to make it from scratch.

You asked four different agencies with similar experiences and project portfolio to give you a cost estimate based on your business plan and app features. 

You got this: 

Based on the figures alone, it would seem reasonable to pick agencies 1 and 4, but don’t make your decision yet.

Ask all of the agencies to explain their estimate further. Most agencies will break down the cost into man-days, like so: 

Disclaimer: This is just a simple projection on how to evaluate man-days, please note that we did not calculate roles such as project management, business analysts, etc.   

If we presume every studio you contacted has the same know-how, most of them will take around 800 man-days to make it happen.

Most agencies have a fixed man-day price (let’s take 400 EUR/day for this calculation).

800 x 400 EUR/day = 320k EUR

This price can be three times higher in London or New York, two times higher in Berlin and maybe two times lower in India.

Labor prices vary based on geography, but the number of man-days for a project should be more or less the same.

It would look something like this:

It becomes evident that Agency 3 did not evaluate the project right or have budgeted for many contingencies. Agency 4 has shorted themselves, which could lead to budget correction halfway through the project, a nightmare in any case. 

Agency 1 and 2 are in the same ballpark, so these are your choices. 

Of course, this works if you are building an app from scratch. 

If they intend to customize or fix an existing solution, your estimate would look a lot different, but it should still be clear and inform you about possible feature limitations of a ready-to-use solution. 

The development process in a nutshell

If you’ve done your homework, sketched out all of your app screens, drafted all of the features you must include and decided what your MVP functionality is, talked to people and decided on who your partner is going to be—now it is time to get to work. 

Everything starts with product discovery. We will question everything about your app’s goal, users, how we can help them and solve their problems using what features.

Once we have all agreed on what your MVP will do and how we can measure success, we move on to building a prototype. 

Now work splits in two directions—your User eXperience designers will consider user flows and scenarios, trying to guess how people can interact with your product and giving them valid, simple and understandable options along their path.

User Interface designers will make sure your app looks amazing, with buttons the right size and color, and what kind of animations we are using. 

After all has been defined, designed and tried on clickable wireframe models, it is time to start developing. Since we use an agile approach, we will plan, code, build, test and repeat this every two weeks. We wrote an additional blog about the benefits of agile development.

Expect to be fully involved in the development process since you will have to make crucial decisions almost every week during this process.

Every prototype built is tested straight away with manual and automated tests at every stage of app development.

This part usually takes more than half of your time, depending on the complexity of your app features and the systems it uses to deliver your envisioned functionality.

Do not kid yourself that it will be done faster if you apply pressure. This is a rookie mistake that leads to errors and unforeseen expenses.

Trust your team—this is why you choose them—to be experts and guide you through a very complex process.

After months of trying things out, testing them, fixing them and trying new things, you can publish your software product.

This includes creating product descriptions on Google Play Store and Apple Store, uploading all of your assets to be approved by the Store Staff, and fixing things if your current app is not compliant with the Store rules.

Expect the approval procedure to take weeks, not days—plan for compliance issues, since Apple changes their store rules often. 

Once your app is out into the wild, your job is not done. In the post-development phase, you monitor things.

You fix bugs while adding new features according to your road map or even ones that became evident from your user reports.

Apart from preventing crashes and providing a better user experience, you should consider adding features to stay fresh and prolong the Client Lifetime Value of your app.

Expect this stage to last for at least the same time you’ve spent developing your app. 

Do not forget marketing 

If you build a perfect app and no one uses it, what have you really done?

Marketing should be a part of your roadmap as soon as you start product discovery. Talk about your app on your social channels, share sketches, discuss features, but do not be influenced by outsiders just yet. You are building your vision. Own it. There will be time for users’ comments later. 

You want to own your code and all deliverables

Our policy is that Intellectual Property Rights are transferred to you once we are done, so you own your code and all deliverables.

How to collaborate for best results

If you’ve worked and coordinated projects with multiple people and teams involved, you already know that open and straightforward communication with your team is a must-have.

No one should be afraid of speaking about potential issues or problems that happen during research and development.

Yes, your team will be self-managed—but you are in control. Change things, add new features, remove existing features any way you like without sending official requests.

We provide a framework that feels like we’re working in the same company. Everything is transparent, and you know who is doing what, when, why, and how much it costs. 

We encourage our clients to be engaged, call us frequently to make sure we are all on the same page at all times. Constantly keeping in touch helps us make the right decisions, decide on the direction or change it, fine-tune milestones on our road map to reflect a newfound situation.  

Transparency goes a long way and saves a lot of time. Tell everyone on the team what they are making and to what end—context helps everyone on the team make better decisions.

If you choose to work with us, you can count on your team to be all up in your project full-time.

No context switching allows our engineers to dive deep into challenges and come up with creative solutions to your business goals and needs.

We’ve explained every step of the development process in our Go from Idea to Mobile app guide.

Tools you will be using

To make everything run smoothly, and everyone fall into rank, we use a set of tools that help us keep track of changes, make communication clearer, allow everyone to participate and present their work. 

Task and document management

Our preference is Jira as the project management tool for tracking progress and generating reports and Confluence as a document management tool. Still, if you prefer Microsoft stack, Asana, or Trello, we can use those on your project. 

Google Docs, Google Sheets, Google Drive are used too and linked and shared through Jira.

Meetings

We prefer Google Meet but are happy to use Zoom, Microsoft Teams, or any other service that you may prefer. Book meetings often and whenever you need, since communication is the base layer for a successful project. We usually try to have daily and weekly standups.

Design

What was once done in Adobe Photoshop or Adobe Illustrator, Proto.io and Balsamiq, we now do in Figma and Sketch, bridged with Zepplin for our software developers. It helps our software developers understand what they need to implement pixel-perfect designs. 

Code repository

All our code is stored in the Git repository. We use BitBucket (part of Atlassian) as our git repository hosting service. Some prefer Github, or they even have a dedicated installation of GitLab Others like Microsoft Teams. As long as it is a working git repository where you can track your software product progress in real-time, we can use any. 

Continuous Delivery

We like to automate every process that we can, allowing us to tap a button and orchestrate the delivery of web, mobile, and backend applications to our client. Our preferred Continuous Integration (CI) and Continuous Deployment (CD) tool for mobile platforms is BitRise. On some projects, we use CircleCi and Azure DevOps, and a couple of our enterprise projects run on Jenkins configured down to details. 

We use Bitbucket pipelines to streamline delivery and publish new versions for our backend and web frontend apps. All this helps us react faster and publish new versions at a daily pace if needed. 

Our two cents on Startup fails

Most startups fail due to lack of experience, which leads to unrealistic expectations, bad budgeting and worse project management.

Do not fall into these traps; try to pick a reliable, experienced partner to help you navigate the narrow straits of software product development. 

Unrealistic expectations

Founders often push for a project to be completed in three months when faced with a timeframe that actually takes nine months.

The same things happen when you try and squeeze a project that costs 500k USD into a 100k budget. Both lead to disasters halfway through the project when you can’t find more funding or time in time for launch. 

Another unrealistic expectation is that the development stops with the launch. No. The real development, iteration and adaptation to the market starts after the 1.0 is delivered to the market.

Think of the first official version as just the beginning, then reevaluate your budget. 

Faulty budget allocation

Most founders are in a rush to develop their first version and burn up to 80% of their budget in the first couple of months, hoping to implement as many features as they consider necessary for the final product.

These assumptions are more often wrong than not, so when the product goes to market, users’ comments increase the number of iterations and features needed, often blowing the budget. 

Our experience is that you should not spend more than 40% of the budget on creating version 1.0.

You should use the remaining 40% for product iterations while the product is on the market, and users are using it. The last 20% ​​is for ancillary costs.

Budget allocation mishaps fall under choosing the right partner—one who has your best interest in mind, not the one who sees you as a cash machine. 

Poor project and product management

Project management is not easy. Even if you structure your team openly, define clear responsibilities and circulate information on time, with a dedicated Project Manager running it, the lack of implemented systems for analysis, product monitoring and growth can end your project too soon. 

Having an implemented/integrated set of tools to enable everyone in the team to make objective conclusions about the product’s behavior AFTER it has been released since some use scenarios and bugs become evident only after the launch. 

Do not beat yourself up about it—no amount of experienced coders and designers can predict how creative a user can be when pushing an app to its limits. 

It would be best if you had a way to track crashes, audience demographics, various user scenarios, and how often certain features are used.

With a feedback system in place, you can easily collect user suggestions and participate in developing new features and modules to be implemented into your app. 

Tl;dr

By now, you know what is needed to complete your mobile app development project.

Firstly, choosing the right partner based on their references and experiences. 

Share your business plan and everything you’ve prepared for the project already. Then, ask them to explain their cost estimates—using man-days. 

Most development companies should have a similar number of man-days for a specific project. It is your main comparison tool since the price of labor varies based on geography. 

Once you are positive about your partner, meet them to better see which systems they have in place (for task and document management, design, meetings, continuous development and delivery) and make sure you know how to use them. Suggest alternatives if you prefer. 

After product discovery confirms or updates your app ideas and features, you can start developing prototypes, testing them and making new builds based on rapid feedback—since you will be doing this for 60% of your time, expect to communicate often and be completely transparent. 

Once your software product is published, expect to spend at least a year doing maintenance, repairs and adding features. Your audience needs to be happy. 

Should you need more information, check out How we work to learn about the Decode process and team structure.