Posted on

What app to build in 2017? Native, Hybrid or Progressive Web Apps?

The global apps debate got another dimension as Google proposed progressive web apps as the next big thing in 2015.

However, most people building apps today still prefer native apps, for several reasons, mostly because it’s what people actually use.

We gathered three experienced developers and CTO’s to discuss the three types of apps most developers are building today. jordimirobruix, former CTO of Wuaki.tv, senior developer at Ulabox, Rubén Sospedra and founder of Javascript coder bootcamp Codeworks Alessandro Zanardi.

Friction, friction friction

A big question in the app-building discussion, is about the app install friction. In other words how many clicks there are from finding the app in the app store – to becoming an active user.

After voting on what type of app most people with build something with tomorrow, more than 40 percent of the people attending the debate chose native.

Briux believes the friction is the same in both PWA’s and native apps:

What’s the difference of the friction generated by the app store, compared with downloading a web app to your home screen?

Zanardi believes progressive web apps is much more frictionless because the device itself promotes the use of PWA’s:

There is much less friction in installing a progressive web app because the device your using is actually wanting you to install it. Compared to going to the app store, installing an app that takes up tons of space, and needs an update every two weeks.

Sospedra turns to the metrics:

The numbers tell us a story when 86 percent of the media being consumed on mobile phones are through native apps and only 10 percent of the total time spent on smartphones are used in browsers. PWA’s are still the new kid on the block, so maybe in five years we can talk again?

https://upscri.be/285782-2

The evil app store?

In one of the last question rounds, the app defenders had to reveal their answer about app stores — good or evil?

Miro says that if you get rejected it’s an evil thing and continues:

Android is pretty easy, just push and you’re in. With iOS however, to wait for someone from the other side of the world to test your app, that’s a black box for developers and nobody likes black boxes.

Codeworks CEO Zanardi points to that the app store or Apple, is the biggest preventer for making PWA’s really big:

The biggest problem PWA’s have at the moment is that Apple’s Safari doesn’t support service workers and that kills a lot of the purpose of the app. Firefox and Chrome are embracing PWA’s. As long as Apple is making tons of money from the app store we’ll have a real challenge.

What does your startup need?

Former Wuaki CTO Miro says choice of app to build all boils down to what kind of business you’re building:

If you asked me four months ago, hybrid apps were not the way because we couldn’t build what the business needed in Wuaki. But today for what I’m building, we’re looking for speed, something that’s tested and reliable and we wanted access to Canvas or WebGL, so hybrid is the way for us today.

Miro explains how the business decisions often dictates what kind of apps you end up building.

Sospedra agrees with Miro, saying that your business goals need to be clear before deciding what kind of app you’re building. He’s also adding that what kind of technology your team is comfortable with is important as well:

If you have a team that are really good at Javascript, then go for React native, but that’s my opinion.

As progressive web apps might be the bet for the future, Zanardi wanted to end the discussion with a statement:

I completely agree with these guys that if you’re building an app today to work on iOS and Android I would go native. The main problem you would have with PWA’s is with the iOS. If you’re targeting mostly Android devices you might go for a PWA. As long as Apple is blocking the spreading of PWA’s we’ll have an issue we need to solve.

There was a lot of other interesting points in the full debate, so check out the video at the top!

The post and video was produced by the itnig media team Masumi Mutsuda and Sindre Hopland.

Posted on

How Quipu kept churn rates under one percent ever since their launch

Going into its fourth year, one of the things the Quipu team and its CEO Roger Dobaño are proud of is their low churn rate.

Quipu is an online billing software that solves your daily administrative tasks. And as with any SaaS product, churn is a number they keep close track on, says Dobaño:

I’m in touch with the churn numbers daily, but we measure it monthly, like most startups.

A low churn percentage is not only validating that they’ve built a product people like, but keeping the rate down over years has also taught them a lot about how their customers think and act, according to the CEO:

For a B2B SaaS company, it’s often quite expensive to acquire new users, so we’re very proud that we’ve been able to hold churn under one percent from the start.

Support

It’s not rocket science, with more customers come more responsibilities, and that means a higher demand for service.

As you’re scaling your customer base, one of the most important things you need to do is to make sure your customer service team scales together with your customers. The easiest way to keep churn down, is to have someone that really understands the product and cares about the customers.

He continues:

Even though many of your customers never need any help with the product, it’s part of the trust relationship you build, as the customers know that there are humans to talk to at the other end of the software.

The first 12 months Quipu didn’t hire customer care people says the CEO:

For the first year of our business, I did all the customer support myself. Not only because the team was small, but so that I always knew what our customers thought about our product.

He says he’s still in touch with the customer service team, as it’s one of the best ways to know how to develop and improve the product.

He explains that the way customer service agents should attend struggling users could be an article in itself. The baseline is to listen a lot, be understanding, patient and get to the core of what kind of problem the user is facing. There’s usually always a way to fix it.

No automated unsubscribe button

It’s not about making it hard for customers to unsubscribe, according to Roger, but it’s about understanding why they want to leave.

If you want to unsubscribe, we’ll get notified when you push the button, and we’ll get in touch. Their reason for unsubscribing is often connected to a task we can help them achieve very easily, preventing them from leaving and making them happy again.

And if the customer has decided to leave anyway, you’ll at least have the data on why, if you actually talk to them. It’s also for security reasons, as people’s financial data has to be treated carefully.

When you’ve grown a significant amount of customers or users you should also consider measuring CSAT and NPS metrics.

  • Also read: How To Improve Your Customer Satisfaction Score and Net Promoter Score

Apart from great service, upselling is another way to prevent customers from choosing another product. The more ways people use your product, the lesser is the chance of the person leaving you.

With a very low churn rate, you’re actually able to reach negative churn, if you’re able to upsell enough.

Quipu is counting 13 heads these days, but growing steadily every quarter.

Track patterns

When you have a payback period of one year, which is normal in SaaS companies, you need to know that people are happy especially in the beginning to keep the retention rate high.

Apart from speaking with the customers, tracking their movements and tasks inside the product is a very good way of seeing where it goes right and wrong.

For example, in Quipu one of our services is managing invoices. After looking at the user movements, we now know that the retention rate is much higher if the user creates three or more invoices. With this info we’ve been able to retain more customers over the years.

Dobaño adds that it’s also important to use movement trackers to contact users who are struggling, even before they complain or think about leaving.

Don’t go crazy with features

It’s both upsides and downsides to talking a lot with your customers (obviously more positive sides though). One of the challenges is that people have a lot of thoughts on what kind of features you should develop next.

If you’re working B2B, you’re in touch with professionals, and they’re aware of what type of features would make their day easier.

This results in new features that both keep the retention rate high and make it easier to acquire new users.

But it is easy to take water over your head and create ten good features to please everyone, instead of making 3 perfect features. It’s a difficult balance, according to Roger:

We try to focus 60 percent of our capacity on building our existing product better, and 40 percent of our time making features for acquiring new customers.

The holy two percent

When you’re working with high growth products, it’s often essential to be raising funding from investors.

A motivation in keeping your churn low is that most investors will not bet on a SaaS startup if it has a churn rate of 2 percent or more.

So even though you’re acquiring a lot of customers early on, having churn in mind from the first minute, can be more valuable than you think.

Some last tips on the list to prevent churn you should consider is:

  • Make meaningful partnerships with complimentary services.
  • Don’t let credit cards expire.
  • Let the whole team know your churn rate and be aware of changes
Posted on

Better code structure: working with pods

Usually we organize our javascript apps either by what they are or by what they do. The first is like rails: separate directories like components, containers, reducers, etc. And the second more or less like feature/DDD: user, cart, and so on. Tho both of these options are very mainstream and solid they contain some constraints.

When you structure the code files tree by what they are you tend to keep every component of the same feature so distant that it’s very difficult to connect the pieces. Therefore you dive into some troubles like the path hell; a lot of require('../../../etc') in your code. And everything is extremely coupled to the directory structure.

In the other hand, when you are driven by what they do everything is more isolated and maintainable. But there’s a lot of duplication. And the communication between the features either is based on a weak contract or depends upon some infrastructure. Both of these options are prone to raise some bugs.

Pods it’s an evolution of the last one. You can think about pods like the microservices of the front applications. A pod is an isolated and completely independent microapp which can communicate 100% with other pods. Therefore, you get code base which is composable, extendable, reusableand extremely easy to test. Tho, the main benefit is that you completely erase the inter components side effects. Once a pod is failing you are totally sure that it’s because itself has something wrong; not an external piece.

A pod is an isolated and completely independent microapp which can communicate 100% with other pods

The unique requirement of the pods is to driven all the pods intercommunication through an event bus. If you’re already using any Flux pattern, lib or framework it’s gonna be very easy to lead this communication to the dispatcher; which is actually a single point for the events.

For a pod is not mandatory to have the logic, presentational and communication layers. Can have all of just one of them. Imagine a router pod. It has the logic and communication layer but doesn’t expose any view. Or the opposite, a form pod which only exposes a presentational layer and depends 100% on the arguments received (see React props).

Because every pod acts like and independent application we place the tests inside them. This means two things: stop duplicating the files tree, and making code coverage meaningful. When you have 100% coverage with a pod you know that it won’t fail. No side effects.

In a nutshell, by working with pods you get a secure and very flexible structure. Very easy to test and without side effects. It scales from 0 to millions without worrying about big refactors due to the fact that every pod is isolated but available to communicate with all the other pods.

In case you want to see some code here’s a Github repository with a simple pod architecture. Give it a look and check the benefits the pods can offer. If you have some doubts or proposals don’t hesitate to open an issue or comment here. This is a living pattern. We’re using the pods at Ulabox and they’re proving to be the solution to a lot of structural codebase problems. Tho, we’re willing to listen about your thoughts and concerns.

The journey is long, take some pods.