when you are a non-tech person and you have an idea for an app or platform
Creating a new app can be daunting, especially when you have no technical background.
I have met many clients in this situation over the years, and here are some tips that I’ve learnt from them that might help you:
1. Ask yourself why you are making it and why now
I had a client years ago who came to us to make a simple app to share readings in his religion. I also had another client who wanted to make apps for an animal shelter. We support charities and non-profits (as long as they are non-discriminatory), so there is some discount.
But it’s a different story to come back to us two months later and say “hey I need an update, but my app is not selling so well, can I have the update for free or 50% off”?
Obviously our clients have forgotten that they were into it for non-profit in the first place and panicked when the app became an endless expenditure.
Depending on genre, it is expectable that you will meet low sales. In fact, even if the app were designed for profit, depending on the situation and luck, it might take a year or more to gain the first paying customer. And usually, it needs a lot of marketing work — spreading the word out, improving SEO etc. If you don’t have the time or resources to grow your app after it’s launched, perhaps it’s not now.
2. Know the users and your use case
We make bespoke systems and have made several for small businesses who have tried everything out there. (p.s. it’s actually not that expensive to make one if it’s well-scoped)
One particularly unforgettable case was when the client told us his product range was in the tens. Each product will have some attributes, where each attribute has about ten values in turn. That was not too bad. 10x10, and we were testing it on datasets with like 1000 or 2000 values. However, the program crashed when he loaded his data (which were kept away from us). He had hundreds of products (after he included all the variations and parts), and some attributes had hundreds of values. That means it became 100x100 = 10000 values. We had grossly underestimated by at least 100x.
The client had given us a smaller number because he feared it would increase difficulty and therefore, costs. But it is not possible to fix the problem without a major overhaul to change the algorithms to handle computation and memory more efficiently. This is extremely detrimental to development.
Another common problem comes from applications with data or computation demands. An app that requires constant high speed data connection for staff out on the field will quickly drain both their battery and data quota.
3. Define your scope, with what you are willing to spend
It works like going to the mall as a 10 year old. You are excited and you want toys, ice-cream, the latest game for your console, everything. But you only have $20 in your pocket and you are told to buy necessities.
You need to prioritise and acknowledge that you cannot have everything. At least not if you have an upper limit to your budget.
A common protest we hear from clients will be “but [insert platform here] has this function and that function. If I don’t put it in I can’t compete!” (yes, we literally had a client who wanted to combine all the social platforms— a portal to post 160 characters with filtered images and share it to friends and groups.)
But Rome is not built in one iteration and it is very likely that all the functions were not implemented at the same time, but are a result of years of continual development, implemented as the product got user validated.
Another case was the client kept changing his mind. In April we decided that the platform would be totally user-generated content. In June he suddenly wanted a manual admin approval process. In July he still wanted a jobs portal, but by December he wanted to scrap it and have a community and portfolio portal. By the next February he looked back in horror and realised “what? I had spent all these money?”
What followed then, was that the project would have burnt out all their funds before even reaching beta. All because the scope was poorly defined, or the goalpost kept shifting, or the founders got too sick and tired and lost all the steam needed for any marketing or launch efforts.
4. Know that your application won’t make you money straightaway
This reality check seemed obvious enough, but almost 3/4 of the clients we’ve met are too distracted by the number of high profile tech CEOs to believe it. They thought that the only reason why everyone else is not one of those CEOs, is because everyone else didn’t make an app.
A completed app is not a golden ticket to whatever.
The developer is usually not the reason that an app couldn’t make it. If the developer were horrible, the founder would have moved on to another person.
The app truly dies when the founder loses patience, or loses interest because the app didn’t have 1 million downloads in a month and start making thousands in a quarter. Then they start cutting any efforts, ignoring bug reports or feature feedback (which are important in the first stages when your users are still interested) and just allowed the app to wither.
Software development requires a lot of effort (and money). Like forex trading, do not jump in and imagine immediate profits with an auto-running program. Always set a stop loss — your limits, and only adjust it if you have made a validated analysis of the circumstances.
