There is no point choosing a solution that does not fit your skills.
You cannot hire developers to build apps for you in-house if you don’t have the technical knowledge to direct them. Or outsource the development as a dev-shop will also need managing.
You may need to go to a full-service agency who can define, design, build and test your app for you. But this is expensive - see also https://www.linkedin.com/feed/update/urn:li:activity:7226511045752741888/
We recommend splitting the development tasks from the design side. Half of the job is detailing the app you need, designing the concept, market researching it and then testing the prototype.
You can probably do this in house or with the help of a small agency or freelancer. You can then outsource the build to someone that agency knows or use a no-code or low-code platform.
No-code platforms like Reptile take the cost and the risk out of the build by automating that. We can also help you find the right agency or freelancer to help you fill any missing skills gap.
You get what you pay for. Sometimes.
Are no-code platforms a shortcut? Yes and money savers. But you need to make sure the platform is right for you and the safest way to choose is still via an agency that has used the platform before and can validate if it is a good fit for you.
At Reptile we offer a free validation service because we can spot the areas that could cause you problems and advise you how to fix those. We will only recommend you commence an app build with Reptile if we don’t see any obstacles.
We also partner with agencies, especially if they know you and your business area. They bring their expertise and we handle the build – it’s a win-win.
Two words of caution:
Be aware of cheap off-shore development houses unless your agency has used them for many years and is responsible for their work. If you go direct you have no-where to go if they let you down.
Be really careful of building in-house. Specialist app developers are expensive and some job-hop at an alarming rate. Once they are on your payroll they are not incentivised to finish the job quickly and the risk of being fired is no threat in a world where there are more vacancies than developers.
There are three common ways that app projects go wrong:
1. The budget gets blown and your project becomes a money-pit
2. The timescales go out of the window
3. The project is never more than an MVP (minimal viable project) and is never fully-finished for release
Break the job down into small stages and link payment and deliverables to each stage. This is how we approach it:
1. Discovery and project scope document. Up to 20 hours of work to define the project, create integration flowcharts, some early visual concepts. Should outline the stages of the project, estimated timelines and costs for each.
2. If you walk away at this stage you have a spec document that you will need any way and can use to shop around. If you are happy with the performance of the team so far move to the next stage. We build a prototype of the app on Reptile and share it on the Preview App so that you can check it on real devices.
3. Then we build the app from that work – which is automated and takes only 20 minutes. And add integrations and pull the data, content and services which your app needs.
Things to be aware of:
A typical dev project will be vaguely open here and carefully plant app the responsibility on you for failed builds, missed deadlines and rising costs. You will be on some form of times and material payments – so if more time is needed, you pay for it.
Dev teams have a magic get out of jail card called ‘change of scope’ or ‘scope creep’ to explain why something you thought was included it a paid-for extra.
It is often actually a legitimate argument – devious, naïve or badly organised clients are masters at continually bundling new features and functions into their project as they go.
As a client you need to listen really carefully and have trust in your partner. You need to be a good client as well.
If you sit on the other side of the fence 90% of the reason projects go over time or budget is because the client keeps changing their mind, can’t make decisions or just doesn’t respond.
There are organisations we will not work with because they are too big or chaotic and we know they will draw us into their world and we will never get out.
· Ask for advice, listen and be open to it.
· Once the project begins be ready for it and act quickly.
· Keep the project team small and agile – shut the door on interfering voices who want to come in at the 11th hour and change things.
· Get stage one out and complete – and only then take comments and suggestions for changes.
Apps have to be continually updated with software requirements mandated by the Apple and Google stores. You will also need to keep changing them to incorporate new features and functions which you need.
We would recommend assigning 30% of your build budget to support and upgrades in each of Years 1 and 2. That might drop to 20% in years 3 and 4.
Your solution needs to factor this in – it cannot be a one-time build project. It is the start of an ongoing relationship.
Once you embrace this it makes getting the first app out there much easier. It is your Alpha, Beta, MVP, proof of concept app – whatever you choose to call it to recognise that it is the first pass.
Tightly defined, agile, projects are much easier for everyone to handle and are much less likely to go wrong.
We can re-build an iOS and Android app in 20 minutes and push the new release right through to the stores. Constant improvement in the market-place is the smartest way to evolve.
Start small and grow.
Join the Reptile Community
January 20, 2023
3 mins
Graham
The future of mobile apps
November 27, 2024
4 mins
Graham