FAQ

 

Q: Why do you recommend building native apps?

A: Native apps run much faster than non-native apps because they are written in languages that are fully supported by the platform's ecosystems. They tend to run more smoothly, too, as they have access to exclusive APIs and components which are optimized for different screen sizes and system versions.

 

Q: What is a native app? 

A: A native mobile app is a smartphone application that is coded in a specific programming language, such as Objective C for iOS or Java for Android operating systems. Native mobile apps provide fast performance and a high degree of reliability.

 

Q: What is a web application?

A: A web application (or "web app" for short) is any computer program that performs a specific function by using a web browser as its client.

 

Q: What is a Hybrid Application?

A: A (hybrid app) is a software application that combines elements of both native apps and web applications. ... Because hybrid apps add an extra layer between the source code and the target platform, they may perform slightly slower than native or web versions of the same app.

 

Q: What is an MVP? 

A: A minimum viable product, or MVP, is a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle. In industries such as software, the MVP can help the product team receive user feedback as quickly as possible to iterate and improve the product.

 

Q: What is an SOW?

A: A statement of work (SOW) is a document routinely employed in the field of project management. It is the narrative description of a project's work requirement. It defines project-specific activities, deliverables and timelines for a vendor providing services to the client.

 

Q: Do you build apps for iOS and Android? 

A: Yes, Please go to Contact us and a representative will call you back within 24 hours.

 

Q: What is the difference between iOS and Android development?

A: The Android and iOS operating system are each programmed in different programming languages. This is exactly the biggest difference: iOS apps run on Objective-C / Swift, while Android apps run on Java.

 

Q: What type of support will I receive through the development process?

A: You will be assigned a dedicated project manager, who will be your primary point of contact throughout the development process.



Q: Will I own my source code?

A: Yes, you will set up GitHub or another code account and give us access to develop under your account. So there is true transparency on all the code writing and updates. 

 

Q: What cloud server platform do you recommend? 

A: We are certified cloud specialists on AWS: Amazon Web Services and we will guide and direct you on the best solution for your project. 

 

Q: Do you provide ongoing support, maintenance and updates?

A: Yes, we offer the option to engage us on an ad-hoc basis for support, or have monthly retainer options should you require a more consistent and reliable level of service.

Ad-hoc support can work for projects that need minimal support, as to avoid the need for fixed ongoing monthly costs. However, this can be at the expense of responsiveness, as requests are scheduled based on when our resource is available. 

Most of our clients choose to have at least a small monthly support retainer to get the best responsiveness as dedicated time is scheduled months in advance. If you have a highly technical project with us, then we would recommend opting for a monthly support retainer to cover small ad-hoc changes, improvements, updates and support.

We base our retainer pricing on the amount of development and support hours you need each month. The number of hours that you need depends on many factors such as the size of your project, or the number of new features you are likely to need each month that you’d like to be covered by your retainer arrangement. It’s important to us that you get value-for-money so we’d recommend putting together a nice-to-have list so that your allocation is used each month on value-adding improvements.

Should you have ongoing project requirements beyond the launch of the first version of your website or app, then you may want to consider taking an AGILE approach to your project and have an ongoing retainer arrangement with us that allows us to build, test and deploy larger new features every month. Under this agreement, we would have a retainer allowance which pays for enough time to develop significant new features. At the start of each month, we would agree on the work that is going to form part of the next sprint (i.e. the next 2-4 weeks) and would deliver the work at the end of that period.

 

Q: Can I make changes to my app or website after it's launched?

A: Yes, in fact, we highly recommend that you begin by launching the simplest possible version of your vision first and continue to adapt it over time. This staged approach is called launching a "minimum viable product" (MVP). 

The idea behind launching an MVP is that you’ve inevitably made assumptions, and you can’t test these assumptions until you release something to the world. By releasing a lean first version, you can test your assumptions and use this information to decide on the priorities of future requirements. It reduces engineering waste.

We have some options around making future changes to your app or website.

You can either commission us to update your app or website on a project-by-project basis, whereby we specify, quote, schedule and finally deliver a fixed set of requirements as-and-when you need them. Or, we can take an AGILE approach whereby we schedule in a certain amount of developer time each month to constantly improve things for you. Both approaches have merit, and it’s likely that you will know instinctively reading this as to which is right for you.

 

Q: Do I need to test my app or website?

A: Yes, we will need your support with testing the project, please. 

We have processes for testing and quality assurance, but the way that we think and use your app, is different to how you will. You defined the project, and you know what you want better than anyone, so you’ll probably use and interact with what we’ve built in ways that we couldn’t have predicted. 

Even if everything works 100% perfectly when we hand it over to you, you will need to check that everything works as expected to sign-off on the work with confidence that we've delivered the project to meet your specification.

Testing and achieving sign-off will require some time investment at the end of a project, and potentially at intervals across the life of the project too – So make sure that you set aside some time in your diary for when it’s needed.

 

Q: What if I want to switch development teams later, or bring development in-house?

A: We recognize that there are many scenarios where you may grow to a point where you no longer need us. For example, a start-up may not have the experience or funds to employ and put the structures in place that are necessary to run an efficient in-house development team for some time. However, as the business grows, the commercial landscape may also change, and make in-housing the development team a sensible long-term decision.

And, we’re okay with that - In fact, we plan for it.

Our code is built upon popular frameworks used by lots of the best teams in the world. For example, we use the React Framework for many of our projects, the same framework that Facebook is built upon and drives all of their products. Provided they are used correctly, these frameworks provide rules and conventions that give consistency to the work that developers create.

These benefits extend to you too: Should our offices explode, which we sincerely hope that they won’t, then skilled development teams exist in the world that can pick up from where we left off. This significantly reduces project risk for you, offering peace of mind.

We also version-control our code using an industry-standard tool called GIT. Think of it like being able to save your game as you go - at key milestones developers can save their progress and GIT will remember all the file changes that form each save-state.

GIT provides a history of who has worked on what, and when, enabling us to manage the different versions of your application and safely enabling multiple people to work on a project in parallel. Once everyone is complete, we can pull together new code and features in a process called a merge. 

These methods allow our team to work collaboratively with each other and creates a win-win scenario that reduces your business risk too.