Steps To Develop An App - Mindera Edition

Countless apps are downloaded every hour, every minute, nay, every SECOND! That’s, frankly, a lot of apps.

And it's hardly surprising that so many apps are downloaded. They make our lives easier, safer, and more fun. We use them to order our favourite takeaways, keep our homes secure, watch the latest binge-worthy series (or The Office US over and over again), and so much more!

Apps are really important to us at Mindera, not only in how we use them in our personal lives. Our epic devs build them for some amazing organisations, such as the iOS and Android app they created for ColorADD.

We’re very proud of the fantastic work our Minders do. So we contacted our expert Ricardo Silva to help explain Mindera’s steps to develop an app.

The first client meeting

We arrange a kickoff meeting with the client and our team to discuss the project and come up with some kind of roadmap. From our side, the meeting may include:

• Product owner (PO) — they speak to the stakeholders to learn the ins and outs of the business;
• Frontend and Backend Developers — they see how our development expertise can deliver the vision;
• Quality Assurance Engineer (QAE) — they share their knowledge from a testing point of view;

These first meetings are really important so the team can understand the business and the project and establish a solid relationship with our new (or existing) partner. We share our opinion as partners, always looking at things from the perspective of the client, project and team. Always asking: what can we do that adds the most value to this product?

We’ll speak with our partner’s design team about what they want from the app; in these kinds of chats, we talk about the scope of the project and give suggestions as to what can work, talk about Apple/Android guidelines, and iterate on new ideas together.

After the meeting

Once we’ve finished our chat, we create tickets for the project. Our PO will write these, and the devs will look after the technical implementation (sounds pretty formal right?).

To simplify this, there are tasks within these tickets that focus on our partner’s goals. For example, the QAE will write a job from a testing perspective (how the feature will be tested) and also helps with writing the acceptance criteria.

The ticket will be ready for the Sprint if it satisfies the Definition of Done (DoD). This is when all conditions, acceptance criteria, design, analytics, business rules, etc., meet the requirements to start the implementation.

We can start the Sprint if everyone is on board with the ideas brought to the table!

In summary, we do our prep work: including planning and backlogs. We then do our unique Sprint 0 process.

The PO prioritises the backlog to then check with the team what will fit in the next Sprint.

We then do refinements with the team. Depending on the units, we could split the tickets into smaller tasks, such as FeatureFlag, Network layer, Core, UI, Analytics, UITesting, etc.

We do many unit tests

Unit testing is super significant for Mindera and app development. We need to make testable code, and we want to deliver quality to the end user. This ensures we don’t have bugs or crashes if something changes.

Another essential reason for unit testing is to avoid future problems for developers; testable code means good architecture and good code patterns.

We ALWAYS aim to improve and refine

The job of our developers isn't only to code but to give our partners the knowledge to improve and optimise the code.

Sometimes, our developers will start a project that’s already in progress. Sometimes they’ll see the wrong code, but it happens! Instead of taking one day to implement something, it might take them one week. In this scenario, we’ll have a meeting to discuss how we can fix the issues and prevent them from happening again together.

Simulator and quality assurance (QA) testing is vital

Our developers use a simulator to test the apps they build, though sometimes they can use an actual device (smartphone) to test specific requirements. Sometimes it’s different using a simulator than using a device — for example, performance issues and unexpected behaviours.

The good thing is that we’re always working with QAEs, which is super important. Even though our devs are experts in what they do, they may not be the best people to test; this is because they were the ones that implemented the code, so there could be a subconscious bias.

This is why the best partner for the developer is a QAE because these experts will see what a dev misses and then push the work back to fix any errors.

Continuous integration helps us to reduce human error

Continuous integration (CI) allows us to improve our quality and reduces human error.

We use CI as a middle environment between our devs’ devices and other devices. It should be a clean machine without any external variables. Every time we push or merge code, the CI will get the latest development branch and run it as a natural new environment.

The CI environment is a machine always working (24/7), which means it’s also suitable for continuous delivery (CD). So, after each week of work, we say to the machine that it can create the binary for the app store. Then, with just one click or by schedule, the device will do it by itself — create everything and deliver it to the app store.

We’re a software company with a difference!

Some of the key things we’ve spoken about (communication, equality of opinion, etc.) could be normal in a software development company, right? Well, apparently not!

As Ricardo noted,

“it hasn’t been the case in previous companies I’ve worked for.

In many companies, the lead developer will decide everything, and everyone else will do as they say. At Mindera, the team decides everything — even with the client products. So everyone has the power to share their thoughts and make decisions.”

Check out our Careers page for open vacancies and learn more about what it’s like being a Minder.

Are you looking to develop an app for your business? Then, check out becoming a partner too!