Developing a software that matters

First, a disclaimer. As you read the title, you’ve probably thought that this article written to create some brand image or something.

It’s not.

Because as you read through this article, there are several stories of how our development failed to bring impact. It’s a lousy way to create company brand image.

I decided to write this article when I met one of our former clients and he said that they’ve developed a similar app to the one we built last year, but no one ever uses it. The app just sits there collecting dust in the server.

I heard similar stories a lot. And if you are in IT industry, you probably do, too.

and on the other side…

December 2017, I happened to carpool with one of our app users from the airport. He did not know that I am the developer of the app, a mobile reporting platform for company personnel whose job involves going to stores in daily basis. During their store visit, they had to take pictures, make a field note, and eventually create a report in MS Excel or other programs. The procedure was just so many, took time, and exhausting.

So I decided to ask around about the app expecting an answer or two about whether the it was buggy, easy to use, or not. Little did I know that the answer would be how the app was saving him a lot of time and troubles in getting their job done.

Before using the apps, they had to sleep at around 1 AM because after store visitation, they still needed to transfer their photo, select some, input data, to be able to make a comprehensive report. By using the app, however, their job was done when their store visitation completed since the report is automatically generated and sent to the main office directly.

“by using the apps, it cut down our workload by 90%”, they said. 90% is quite a big number, I’d say.

This experience is not only good on a portfolio but also good for the team morale. Getting paid is good. But being able to make someone’s life easier is just as great a fuel.

But let’s be honest, not all ‘successful’ software development can bring impact.

The client gives a requirement, after engaging in some talk, you begin the project. After several months, you’ve developed the app according to the specs given, no bug report, it works so well, so you put it on store. Fast forward to several months later, tadaaa… no one uses it.

Sadly to say, this is a common occurrence.

After several years in the IT industry, we can now differentiate what app is going to bring impact, and which one is not. Trust me, we’ve created many from both categories equally. After analyzing several cases (many of them are our own), I could confidently give you these five tips.

But before that, again, another disclaimer.

There are sooo many good books out there talking about creating a good application. You won’t see “how to make a successful bridge” book as many as “how to make a successful app”. Maybe it’s because it’s easier to fail in developing an app than a bridge. Now, you probably need to read those books first. My tips right here are just an addition coming from several hard lessons we learned. Hopefully, you won’t fall into the same hole as we did.

So here we go.

1. Always Make a Mission Statement

“Making an application per requirement” is not a mission statement. Aside from its lack of boldness, it also sounds a lot like a school homework. “Please submit all the answers on page six by Monday”. Your mission statement should align with the business goal, and it should be tangible. “Using this app there will be 1000 new users, and it will generate 15 Billion in sales”, “Using this app, it will reduce at least 50% of workload of our end user”. It should be that simple and measurable.

Creating a mission statement helps us to measure how successful our work, and it also helps in decision making. So next time your client asks for “a feature to change a wallpaper”, you can ask yourself if it is helpful in achieving the mission statement. If it is not, then reject it.

EVEN WHEN THE CLIENT ARE WILLING TO PAY FOR IT.

The more features we make, the bigger the maintenance cost, and the riskier it is for a bug to happily pop up.

In the long run, the client will love you for not just accepting every job blindly.

2. Involve All the Stakeholder from the Beginning

We learn from failure, not from success!, — Bram Stoker, Dracula

Perhaps we should not take a lesson from someone who is afraid of a garlic, but his words are not without merit, too. Learning from failure is indeed more powerful than from success.

And here’s how I learn from one of our failures.

Once upon a time, a client approached us for a project. After initial meeting, we finalized the requirement, we drew a mockup and created a prototype. We received feedbacks and work on them. All the ABCs of project initiation. And then the development commenced.

After months of arduous process, it was now time for a demo. We set-up a meeting with the client and prospective end users. We were so confident with our work since the result is precisely the same as the prototype.

Demo day came… and it was a nightmare.

The end-users, the ones who will use this app in the field, thought that the app was useless since the situation in the field was not like that. At that time, they explained what they actually needed, and it was indeed completely different from the initial specification.

The thing in this case was not only about your apps became useless, but it also brings down the morale of your team. Scrapping months of hard work to then making something new entirely, sucks.

Some people will argue that it’s our client’s mistake. We had a requirement, and we had developed exactly based on it, the specification. So our job was done the moment we delivered the app. But let’s not point fingers here, this is not about who’s right or wrong. When your application is not helping anyone, then you both failed.

After that event, we always ask to meet with all the stakeholders for any project. From someone on top of the chain ladder, the one who makes the policy, to the end user who uses our app in the field. If it’s impossible to meet them at the same time, then we arrange different meetings. But the key point is all the stakeholders must be involved in each step. Each of them has to tell us how our application could make their life easier.

3. If you never decline client request, then you are doing it wrong

Since 2017, Algostudio has denied most (if not all) of the sub-contract works. One of the biggest reasons for that is usually because the first company who meet the client has agreed with all the requests made by the clients. However silly that is.

There are a lot of funny stories that I couldn’t tell since it’s not ethical (and there are some NDA involved). But imagine if you make an app for a submarine, and the client asked it so that the app could play puzzle bubble. Yes, as silly as it sounds, it happened.

It’s not always that silly, but there are many instances when the client request didn’t match with the initial mission statement or could produce another problem with the current specification.

Here is how we’ve been handling it.

If the client’s request is aligned with the mission statement and it’s not too tricky, then we agree to work on it. Nothing’s special here.

If it is aligned with the mission statement, but it could make complication with the main requirement, then we denied the request and try to come up with a different solution. This also happens when the demand is too tricky to implement.

To be able to do this we have to have enough technical knowledge, so we know which one is tricky and which one is feasible. We also have to have enough understanding of the client’s business process. How do we know the client’s business process? We ask, and we learn.

If the request is not aligned with the initial mission statement, then we simply deny the request, even when the client is willing to pay for it. Not because we don’t like the money (FYI, we love it, a lot) but as I said before, the more feature we make, the bigger the maintenance cost, the app become difficult to use, and the more risk of creating a bug it will be.

4. Policy from the top

We have the perfect case study for this key point. Two apps with very similar functionalities, almost the same UI, same user persona, but the results are very different. We can’t say much about the detail of the apps (again, NDA) but its goal is to prevent fraud from fake sales report.

Let’s call it the first app, and the second app.

One month after the first app was released I’ve got a news from the client that our app had made many people lose their job. At that microsecond I wondered whether the app was too complicated so the user couldn’t operate it? Or was it too easy, so the company only needed half the people they usually needed? Both didn’t make any sense. So I asked what happened. It turned out that using the apps our client could reveal a lot of fake sales done by their employees. So basically it’s a success for us (not so much to the ones who got fired, though.)

The second app had the same functionality and workflow. It also has the same user persona. After one month of the release date, the dashboard still look… pretty clean… it was not empty, but not as much as we expected. This condition remained the same for the next three months. After three months the app is abandoned.

So, what gives?

The difference is the policy.

After we developed the first app, there was a policy from the top that the only accepted report was the one submitted through the app. To make this possible, the app itself had to be robust and easier than the previous manual report. The only reason for a resistance, is because it makes any attempt at fraudulent activity harder, if not impossible, to do.

On the other hand, there wasn’t any policy to force the end-user to use the second app, so the end-user chose the old manual report, because they were used to it, and was already comfortable with the old method. OR, it would be easier to manipulate report without the app — we would never know. The point is the lack of policy will surely make people abandon the app.

Of course, to be able to enforce this policy, the app itself has to be robust, have great UX, and no condition will prevent the app from working. I’ve often got a question “What about in the area where there is no internet?”, Since internet connection is mandatory for the app to work, then the end-user could send their report manually. But case like this should be treated as an exception, and it can’t be allowed in the usual situation.

5. Great UX Is Important

Every decision we made in our life comes from within ourselves. Even when there is someone put a gun on you and demand your wallet, the gun itself only gives you “motivation” to give your wallet, but the ultimate decision is still on you.

The policy from the top is merely a motivation, just like that gun. If the app is not great, if the app is not helping users, they will still choose not to use it. With that in mind, great UX is essential. But well, I won’t talk much about UX. There are a lot of great UX book out there, go skim them.

Treat this article as a recipe

In the end, do not treat this article as a book of laws but treat it as a recipe. Depends on the client, sometimes they want their food saltier than usual, or maybe they want less salt because they have high blood pressure. Every client has their unique needs. Every project is different. Treat this article as a recipe that you could tweak as you deem necessary.

Malang, 16 of March 2018

Picture Credit: