[AUDIO LOGO]
PETER FRIESE: Welcome to "Firebase Stories," everyone.
Today, I'm here with Daniel.
Daniel is a software engineer at La Haus,
and he's focusing on their mobile apps.
[MUSIC PLAYING]
Welcome to the show, Daniel.
DANIEL RICO: Hi, Peter.
Thank you very much for inviting us.
PETER FRIESE: Yeah, good to have you on the show.
So I understand that La Haus is in the business of building
an app that makes it easier and more secure for people
to buy real estate and property in Latin America.
So maybe you can show us a little bit
how the app looks like and how it works,
and then we can talk about how you use Firebase.
DANIEL RICO: Sure.
Yeah, at La Haus, we are focused on selling real estate.
And it is pretty important for us to have a reliable app,
because the users are not buying something that is really cheap.
When you buy your home, it's one of the most hard decisions
that you do in your life for most of the people.
So it is pretty important.
They can feel that the app is trusting,
that we don't have box, or the app doesn't close itself,
or it doesn't take too much time drawing things on the screen
or logging the data.
So this is the app, and when you log
in-- when you enter the app, you can see multiple sections.
One of those is this one, where you
can search by yourself which real estate are
in which places.
And you can see the information about them,
and do some calculations to see if you can buy this one
or not or if you need to talk with a bank or something.
And you can see multiple information about this one.
And one part that is really important for the app
is the recommendations.
So we have a machine learning-- multiple machine
learning algorithms that creates some recommendations for a user
and also for a real estate.
So right now, we are seeing a real estate,
and at the end of the detail, we show some properties
that look like the real estate that they are seeing right now.
Also, they can keep track of which ones they have liked.
And for example, they can create multiple lists,
like my favorites, the used ones, or they like the beach.
And then you favorite them, and then you
can handle all of your favorite real estate.
The idea is that they can use this tool
to have the best experience buying a home.
So one important part of this is that nobody
buys a home the first day they started searching for a home.
It's a really hard thing to happen.
So the app remains on the user's phone for a long time--
one month to six months or maybe a year or two.
So we have some features that let them--
nurturing the buyer experience.
So they can search real estate on the map
and see all of the features, but they also can, say--
just having the app and wait.
And that will go in--
will start to do some recommendations for them,
also sending push recommendations and emails.
But for example, here, we have like a Netflix feed.
So users can start just using the app
and give some information to us.
And based on this, our machine learning algorithms
generates these feeds.
So this is like a natural feed, and they
can see a lot of real estates that
are related to their searches.
If they want to have some investments
or maybe they are buying a home for their mom or their family--
so we have multiple options here.
And with this, they don't have to do anything.
They just have to install the app,
and they start receiving push notifications
and these recommendations and getting this feedback.
Another important thing is that there
are a lot of misconceptions about what
you need to buy a home.
So having this on the phone is going to show the user,
hey, you can buy this, or you can't buy these other ones.
PETER FRIESE: [LAUGHING] OK.
Yeah, it sounds like it's a very complex application.
So yeah, which Firebase products do you use?
DANIEL RICO: We use multiple products.
We are using Crashlytics, A/B test, Remote Config, Google
Analytics, and the Performance Monitoring too,
and App Distribution.
These are all the products that we use.
PETER FRIESE: Cool.
Yeah, so maybe we can talk about Performance Monitoring first.
So how do you use Performance Monitoring?
DANIEL RICO: We use Firebase Performance to monitor the app
and see how it is behaving, because it's
very important for us to have a reliable app.
So we monitor how much does it take to-- some end points
to return the response or if they are failing too much.
And also, we are checking how much time
does it take a UI component to be drawn on the screen.
So for example, right here, we have a trace
that shows how much time does it take
to draw this item on the screen and which one is that item.
We show it on every screen on the app.
It's this one over here.
So how much time does it take to render this on the screen?
This is pretty important, because La Haus
is a data-driven company.
And how can you prioritize performance improvements
over the app over other features that the project
team may ask us to implement?
So you need to measure.
So we used Firebase Performance to do that.
And for example, right here, we have some peaks
that are taking too long to draw, and we [INAUDIBLE] them
over here.
So also it's really cool because you
can see which version of the app broke something.
So for example, over here-- from here to here--
it got a pretty bad change for us in this case.
So you can measure it and see how
your app is behaving over time.
PETER FRIESE: Let's take a look at the code.
So I wonder how you implemented the custom tracing.
DANIEL RICO: Got it.
So this custom tracing, it's implemented
with a pretty straightforward solution, I think.
It's like, we just have--
on Flutter, you have--
everything must extend from the StatelessWidget
or have a state.
But let's talk about the StatelessWidget.
And so we created this custom widget that just have this name
and also creates a trace before the build runs
and it's stopped.
And what's the idea behind this is
that every widget that we want to measure
is going to implement this method over here, which
is like the build, but it has another name
so we can have it there.
And then, for example, with this real estate
item that extends this one, you just
have to say the name of this and implement
the method that builds the widget in a measured way.
And then we have all of these traces.
And if you check, we have multiple widgets
that have this.
If we see how many traces do we have,
we have multiple widgets that we are checking
if they take too long or not.
Yep, with that, we were able to measure how the UI is
performing to the users.
There is a dashboard at the top that you
can have some top metrics and measure them over time.
Because you can have 200 traces, and are you
going to check it every day?
It's like, you can have some improvements over time
on some ones.
So we have important ones here and have a fast look at how
they are behaving for us.
PETER FRIESE: That's pretty cool.
So it sounds like you're a very data-driven company, which
makes a lot of sense.
And I think that leads us to the next product
that you mentioned.
So maybe let's talk about A/B testing and Remote Config,
because that's literally there to help you make informed
decisions about what your users like
and which kinds of configurations work
best for them, and what changes that you make to the product
actually result in better user engagement.
So yeah, can you tell us a little bit
about how you use A/B testing and Remote
Config in the application?
DANIEL RICO: This is a really important feature for us,
because our development pipeline is simple.
So we want to work-- to be able to work on features fast,
but sometimes, we have pretty big features,
so we have to send small chunks of code fast to the code base
without looking like release production.
We have some features that are in the middle
of the development flow and they are not
completed, so we use Remote Config to enable and disable
those features, for example.
Right here, we have IS_LOG_ENABLED variable.
So the idea with this is that we can enable
logs in production for our developers or someone
we want to show.
Because sometimes, you have some production blocks
that are pretty hard to reproduce
on staging environments or local environments,
and this has helped us to be able to check production
without exposing security things on logs,
and just show them to our developers.
So this is one part, and it is pretty cool,
because you can organize it.
So we have some A/B tests that we
run-- we are running right now and feature flags like
I was telling at the beginning.
So let's take a look at A/B testing.
How do we use A/B testing?
So as you can see, we have some drafts,
like we want to test something.
But the good thing about this is that it uses Remote Config
to be able to switch--
to change the behaviors.
For example, we want to test over here
if changing the words or the label on some screen
will help the users to complete the flow or the funnel or not.
And so we can create it pretty easy with Firebase A/B
testing dashboard and then just use it in the code,
and it is pretty straightforward.
I think that one thing that has helped us
to multiple experiments on the app
is that it's easy to create them.
You just click Enable experiment and select what you want to do.
And then on the code, it's like some lines of code
to check if the code should do one thing or another.
It has helped us a lot improve multiple parts
of the experience that are pretty
important for us and for the users,
so we can recommend them.
PETER FRIESE: Yeah, nice.
So I wonder how this looks like in code?
Is it easy for you to go in and implement a new experiment?
Is it a lot of lines of code that you have to write?
DANIEL RICO: No, this is pretty straightforward, too.
I will show you.
At the end, the Remote Config thing
is just having the instance of the Remote Config.
We have some instructions to organize the thing.
But at the end, the only thing that
gets the value from the remote instance is one line.
So you just have to call this getBool
and the name of the variable you want to get.
And if, in the inside, there is an A/B test running for that,
it will get the version of that value
that that user must to get one experience or the other.
And then it is pretty straightforward.
For example, let me check enabled.
We have some A/B tests running-- for example, this one.
So in the code, we check, oh, it's
enabled the feature or not?
And if it is enabled, we return the thing or do one or another.
Yeah, this is how we use it in the app.
We have Booleans, but we also have strings.
So for example, we are using a string on the remote side
to configure which numbers can a user use.
So let's check those values, for example, for here--
have, like, phones.
And over here, we can have some values.
So you can have a string.
So you're able to put an adjacent there.
So our team doesn't need to talk with maybe the backend team
to have an endpoint to be able to get the information.
And so this tool has helped us to move fast
without having to wait or have some lookers from other teams.
And also, this has changed over time.
So if this changes, you just have to come here
and change this value, and click Publish,
and it will be ready for our users.
PETER FRIESE: That's pretty cool.
Yeah, I love it.
Yeah, I really love how you added those little extra bits
and pieces to make it easier to use for you.
So it sounds like Firebase has helped your development
team a lot in terms of being more productive and more
efficient.
And I think you used the term faster time
to market there a bit.
Yeah, it's really cool.
DANIEL RICO: Yeah, our team is happy with this solution.
And also we are talking right now
with PMs and people that are not developers-- like software
developers-- and they can go here and check which values
are there and things like that.
So this works also for other kinds of users,
and to help to communicate better
what is happening on the app.
PETER FRIESE: Yeah, that's really cool.
So you give your PMs access to the Firebase Console?
DANIEL RICO: Yeah, we are talking with them,
because also we have the app distribution section.
And we send beta builds internally to them and to us
to check if the code that we are going to publish
is working fine or not.
PETER FRIESE: Yeah, that's pretty cool.
Yeah, great.
Well, Daniel, thanks for taking the time to meet with us
and showing us how La Haus works and how you use
Firebase to make it more efficient, more stable, more
reliable for the users and more efficient for your development
team and your product team.
DANIEL RICO: Sure, Peter.
Thanks to you for talking with La Haus
and showing this to the world.
I think that Firebase is a really great product.
And it is also free, so everyone can test it and start
using right away in the app.
PETER FRIESE: And that was another episode
of "Firebase Stories," the show where we show you
how developers like Daniel use Firebase to build
better apps one step at a time.
Thanks for tuning in, and we will see you the next time.
[AUDIO LOGO]