Leo Dion (host): Hey everybody.
Before we begin the episode today, I wanted to let you know of a few things.
One, I'm still open to new opportunities, so if you or your
company needs someone to come in.
And help with any swift development, bright digit is available.
Reach out to me, Leo, at bright digit.com.
Or you can go to our, the website, bright digit.com to get more details.
Let's set up a time to talk and see how I can help you or your team with
whatever project they're working on.
Secondly, I'll be speaking at Swift Craft.
This will be, from may 21st to 24th.
You can check that out on the website swiftcraft.uk . And I will be speaking
on Advancing in Swift by Learning How to Count so I'll go over some stuff
about the history of numbers and mathematics and how it's related to the
evolution and complexities of Swift.
I would love to see you there if you're gonna be in the uK, in Kent.
Come check it out.
And then I have been doing a live stream, every Tuesday and Thursday at
9:00 AM Eastern Time and I'm hoping to continue to do that as well.
I've been doing stuff with bushel and, with a new app that I'm working
on that, will be revealing soon.
So if you are interested in learning what is coming down the
line, you can definitely want to check out my live stream.
It's on my YouTube channel, youTube dot.
Com slash break digit.
It's also on LinkedIn and on Twitter as well.
If you like what you see with Bushel in those live streams, and want to
test some of these features out.
I'm still looking for beta testers for Bushell, and I'd love for you
to join and, get an exciting look at what you can do in Bushel.
So definitely check that out at get bushel.ap
And lastly, we still have our Patreon, so if you want to get early access
to episodes like this or you want to, get access to upcoming articles
and drafts and a little of the feedback I've been getting from folks.
Super helpful.
go to paytreon.com/brightdigit.com
That's about it.
So thank you again for joining me for this episode, and I
hope you enjoy the rest of it.
Bye.
Welcome to another episode at Empower Apps.
I'm your host, Leo Dion.
Today I'm joined by Mullin Sundberg and Kai Dobrosky of
what's the name of your company?
I probably
Malin Sundberg (guest): Triple G studios.
Leo Dion (host): Triple Glaze Studios.
I've known you guys for quite a few years, so, makers of Orbit and Mercury.
Thank you so much for both of you joining me today.
Malin Sundberg (guest): Yeah.
Thank you so much for having us
Leo Dion (host): We've had Malin on, we haven't had Kai.
So Kai, I'll let you take it away by introducing yourself.
Kai Dombrowski (guest): All right.
I mean, Marlin and my introductions are usually pretty similar because
we're working together, we're running our company together.
We work
Malin Sundberg (guest): We're also a couple.
It's probably,
Kai Dombrowski (guest): we're coupled together.
We work on most of our projects together.
There are some few ones every now and then where it's only one of us.
But yeah, overall we're both software developers, designers, copywriters,
whatever you might need to build apps.
And we live in Vancouver, Canada.
Malin Sundberg (guest): Yeah.
Leo Dion (host): Awesome.
What's, what is
Kai Dombrowski (guest): Sorry, man.
It now.
Leo Dion (host): What did you wanna say?
Go ahead.
Malin Sundberg (guest): no.
I was just I was just gonna say guys originally from
Germany, I'm from Sweden.
That's like the main difference, I guess, in our story, pastor.
Kai Dombrowski (guest): Yeah, that's how you can tell us apart.
Leo Dion (host): Got it.
Okay.
Thanks.
I was confused for a second who I was talking to, so, yeah, that helps.
What's the, I, I don't, I'm not quite familiar with what
the balance on your team is.
Like, who's more of the designer and who's more of
the developer, if anything?
I.
Malin Sundberg (guest): Yeah.
It's very mixed, like day by day I think.
It seems logical that we would like divide it a bit more specifically.
Like one do, one does development, one does design, but that never
really felt natural to us.
I think we both are just very enthusiastic about both areas.
So we tend to both do development and design.
But I would say we have like certain, I think within our own apps there are
certain features that one of us might be more enthusiastic about and the
other one is not as enthusiastic about.
Then it tends to sort of be a natural split that like one of
us focuses on that feature or one of us focuses on the other.
So it's a bit more feature based.
I would say that like there are some differences with
like the type of design tasks.
I think Kai is like really good with user experience and like making
sure that everything is just like.
Very clear for the user.
It's great.
I tend to be like, can't we just like add a little bit more glass layers,
make it a bit more transparent, and then it just becomes illegible now and
then, and Guy has the guy's like a good balance, like pushing me back like, you
know what, it would be great if people could see the text in our app as well.
I'm like, yeah, that, that makes of the sense.
Kai Dombrowski (guest): But it's often, we're kind of switching
roles between the designer and the critic, which is pretty good, right?
When, whenever I design a feature, Marlin is immediately gonna, you know,
shred it to pieces and talk about all the things that suck and vice versa.
If Marlin designs something then I'll be the first one that actually sees it.
So I think it, it works pretty well, and we're kind of, because I think
we do have a lot of overlapping skills, but different priorities
within those, sometimes it, it works out really well that we're kind of
just both kind of pulling it from our ends and landing on something in
the middle that, that works really
Malin Sundberg (guest): Yeah.
And we're also, we are also pretty like, competitive amongst each other.
And it sounds like something maybe you shouldn't do, but we found
that to be a really fun way of
Kai Dombrowski (guest): We should do more of that.
Malin Sundberg (guest): Yeah.
So like sometimes if we wanna like build something new and we are like
in that brainstorming phase, we start out like creating a Figma document and
we might have like a swim lane each, and then we're like iterating on it
and like trying to come up with like we, we work sort of individually first
trying to come up with the best and then we show it to each other and then
we talk about it and steal from each other's sort of concept and then we end
up coming to like a good conclusion.
Yeah.
It's a very fun way of collaborating.
Leo Dion (host): Do you wanna explain that a little bit more in detail?
What exactly that fit First Figma document is for and
how it helps you guys?
Malin Sundberg (guest): Yeah.
I think because we are both sort of developing and designing,
we tend to not get to like.
A final design before we start implementing it, before we
start in SwiftUI or UI Kit.
Because, but it's more for us to sort of be able to like, come up with sort
of flows or initial ideas rather than having to like do it all in code.
I gotta say SwiftUI has made us do a lot more of that directly in code.
But before we were as full in on SwiftUI we did use that a lot more.
Or
Kai Dombrowski (guest): You mean before it came
. Malin Sundberg (guest): Or if we do like something web related and we
wanna like iterate on our website, we would do use that approach.
But it's often for like a higher del sorry, a lower fidelity sort
of version of what we wanna build.
Kai Dombrowski (guest): Yeah.
And something quick when it's like, what is the best way of let's
say entering a new trip in, in Mercury, then we might have like one
insane on top mine and the bottom.
And we just both kind of think here's kind of what we think the
flow should look like, roughly.
And then we look at each other.
So it's like, oh, this is a good idea that Marlon had.
I'll take that on my next situation and Marlon steal something from me.
And then we kind of just keep stealing from each other until we're
like, Hey, we're actually landed on something that, that we'd like.
Now.
But it's not that we always go that route.
It really depends on, sometimes it is a good way when we both have very
different ideas of where to even start with a feature or with a flow,
because then it's like, Hey, let's actually put this somewhere, so,
so we can see what it feels like.
Or when we feel like we have no idea, because then the competitive
side kind of kicks in because if you have no idea, but you're competing
for like, whose design is more fun or more interesting to look at or
whatever our goal is then you kind of have to come up with something.
So I think it's a good trick to trick our brains into doing something when we
don't necessarily have a direct idea.
Because sometimes we build a flow and it's like, this is clearly how
it's gonna be and we both agree and we just go building it, you know,
start building it immediately.
Leo Dion (host): What are some other tasks you think developers
don't think of that you've implemented as part of your process?
Malin Sundberg (guest): That's a good question.
I think, I don't know if other people don't do it, but I feel like there's
a lot of things that take way more time than you initially expect related
to like working on your own app.
I would say is probably the, I don't wanna say marketing, I think
marketing is sort of like a big beast on its own, but like all the things
that goes on related to you, like showing people what your app can do.
So it can be things like screenshots on the app store or if you wanna
put a press kit together, or if you wanna make like a cool, like video.
I think we, Kai and I, we've been talking for a while now that it would
be really fun for our troop forecast feature in Mercury to show like someone
looking at their phone in Vancouver and it's raining above them and then
the next shot is them in the sun and like showing the app that way.
And we're like having those ideas and then we're like, we have
made some very simpler, like much simpler videos than that.
And we know we think back of that and like realize how much
longer those type of things take than coming up with that idea.
Like we have a lot of sort of fun, quirky ideas like that.
But realizing that like.
That means that you're gonna take that time away from like building
the app and doing all of that.
It's always hard to, like, I don't know how to quantify one thing like that.
It's, so we try to see it more like, do we wanna make this video
because it's fun and we feel like we will learn things from it,
then we end up usually doing it.
But we sort of try to balance it that way.
But we wanna we've been really trying sort of stretching to like, create a
bit more things around the app itself.
Like the especially like press kit when we're ready to launch something
that's been sort of a bigger focus.
Kai Dombrowski (guest): Another thing we do, which is a little bit more
development focused and it's not super unique, but we try to get prototypes
into, builds for ourselves very quickly.
So whenever we have an idea of something we wanna build, like
let's talk about trip forecast more.
When we built that initially we just built like a super hacky implementation.
It wouldn't actually work for any users, it would just kind of do the bare basics
of like showing you the forecast for a second location in your timeline.
It was like a hard coded date, but we got it into the build really quickly
and started living on it ourselves and realizing all the things that
work well, and all the things that really sucked and then just kept
iterating until we felt like it no longer annoyed us when we used it.
And I think that's an approach we use for a lot of software
development to get it.
Into our own hands.
You know, you always have like interesting ideas and then you can
spend a lot of time designing them.
And you polish them all in Figma and then you implement it and then
you use it for the first time.
You're like, this kind of sucks and you wasted all this time.
So we always try to get it onto our phones as soon as possible and then we
just take off all the parts that annoy us until it's ready to be shipped.
Leo Dion (host): That's a, that's an interesting idea.
'cause when I was in college, I was introduced to the
idea of paper prototyping.
Are you familiar with that?
And like, you seem to be much more like, let's get it on the
actual phone and like actually try it on the actual hardware.
What is the bare minimum in your how can you get it to the prototype
to be as prototype as possible without spending like three hours
trying to integrate it with core data or like doing networking stuff?
You know what I
Kai Dombrowski (guest): The thing is I do like paper prototypes in theory,
but it's at some point I think it's also where just mobile development
is now with Swift UI and a lot of the kind of APIs we have, and maybe
people are more artsy crafted on me, but it's taking me longer to build
a paper prototype than whipping up a couple of views in Swift ui.
Right?
It's just where our prototype p comes into our code is
just, we don't build it.
We are trying to be very strict on let's not build anything
that's not handle any edge cases.
Let's not just get the bare thing to somehow work enough that
we can have it on our phones.
And then it's also, you know, paper's great, but.
Your phone is not paper.
Your flows are not, you know, there's a lot of things that paper
doesn't, you know, paper doesn't make you realize that what if you
have a trip from Vancouver to Sydney and Sydney's in a different time
zone that actually crosses the date boundary and all of a sudden all
your views are getting mangled.
Like, there's a lot of value getting out of a hacky prototype because you start
to, even if you don't think about them you start to discover a lot of the edge
cases that you then realize you have to handle once you actually build it out.
Because your phone all of a sudden, you know, all the all
your charts are misaligned.
You're like, why is that happening?
That is not something that is necessarily something that you
would find out that the point of the prototype wasn't to find those
edge cases, but having something that's actually real code makes
you come across a lot of those edge cases that you can then add to your
list of things we need to handle.
Malin Sundberg (guest): Yeah.
Kai Dombrowski (guest): a lot of extra value.
Get out of it when it's real code, even though it's tacky code and not code.
You're planning on shipping, but
Leo Dion (host): Yeah.
Malin Sundberg (guest): Yeah.
Kai Dombrowski (guest): lines of code.
Malin Sundberg (guest): And I think in terms of like knowing how much to
add there, I think it's important.
Like for us, it's important to have something that is like.
Not finished, but like it's feature, it's enough there
for us to be able to use it.
Like we would be using the feature, like we don't want it to be something that
we just look at for a second and then we put down if we add it directly in the
app and we can sort of live on it and get a feel for it, then I think we'll
quickly know if it's something that we're like passionate about and every
time if we open up every time and we are like thinking of those edge cases and
that triggers that, then I think that's a really good way for us to like figure
out if it's a feature worth building.
And that, so I feel like it has to be sort of a little bit there for us
to actually be able to evaluate that.
And I think that depends a lot on the type of feature.
So I think for example with the.
Let's say when we started building Mercury in the first place, an important
thing for us was just to figure out if, like, the way we're plotting the
chart like the colors were clear enough and if that looked good enough and if
that was the right way we wanted to go.
Then we focused a lot on the ui like quickly prototyping that ui, but we
didn't really care about the data.
But something like trip forecast the important thing was to check.
Does it look, so the way the app works, it's a little bit
hard to explain in audio form.
But basically if you have a trip coming up, you first see like the
days in the location where you're at.
So let's say you have a couple of days when you're gonna be in
Vancouver and then in two days you're leaving to California.
Then you can basically see two shards next to each other, one
showing the sort of temperatures for the first two days in Vancouver.
And then you sort of shoot, see them almost like shoot up because
you go into a much warmer place so you can see sort of the delta
and see how different it is.
So for that, it was very important to get like.
A good sort of piece of set, like a set of data in there for us to
be able to see like, how is this gonna look in those extreme cases?
And so that was important in the prototype phase rather than like
focusing too much on the ui.
We could use pieces we had already and then check how it looks with
that data and the plotting there.
Leo Dion (host): What let's goes to our next question.
What's the difference between an app and a product in your opinion?
Malin Sundberg (guest): Sorry.
That was a weird noise.
I think it's, I don't know if it is a big difference.
Like I looked at this question beforehand and I I feel like
there is sort of, I guess product can just be broader.
But also it sort of encompasses a bit more than.
Then like the development side like I mentioned earlier, there's
like those additional things that you might not consider part of app
development, like putting press kit together, putting the app store
page together like telling people that you've been building something.
Those things for me feel a bit more sort of product focused.
But then I think a product can also just be bigger.
It might be that you have like different platforms and those type of things.
What do you think, Kay.
Kai Dombrowski (guest): Yeah.
I mean, I think most apps are products, but not not all products are apps,
or most products are not apps.
Right.
So I also would struggle to define if, like, if we're trying to break
it down, what kind of app would be an app, but not a product,
I think that becomes very thin.
Right?
Malin Sundberg (guest): It sounds like a robot or not.
Episode Justa.
Kai Dombrowski (guest): Yeah, but I do agree.
If you're thinking of like product work, to me it, it's not just from a
language perspective, if you're saying you work on a product, I would also
think of there it to have a higher priority in what you're doing, right?
It's not just a thing you build, but it's like you, you have
like a product roadmap and you have you know, you're trying to
find your your target audience.
It feels like there's a lot of product work that is not development
that goes into an app and which is also often very important, right?
You can have the best app, but if you're not focusing on, on, or, you know, if
you have the best product in or the best app in the world, but no one knows
about it, that doesn't help anyone.
So there's a lot of product.
Work on an app that helps you actually make it a sustainable
endeavor and satisfying endeavor.
'cause it's kind of nice when you build something that you enjoy using to then
see other people also getting use of it.
I think that's a very nice part of software development.
Malin Sundberg (guest): yeah.
But I think it can be very sort of, it can become really broad,
like building a product in itself.
I think it depends a lot on sort of the surrounding situation.
If it is like a company, a bigger company where you have a lot of
people attached to it, and I think there's probably gonna be more
focus on those extra things or
Kai Dombrowski (guest): And then there's also, like if you look at
orbit, for example, our time tracking invoicing app I think that's a lot
more because the product is really the apps across all platforms, right?
So the product of Orbit is you having able, you being able to
use it on your watch, on your phone, on your iPad, on your Mac.
Those are all individual, like those are four different apps, but they're
all from one product because you wouldn't, you know, if you're time
tracking, if you're a lawyer and you're time tracking and you had a client's
place, it's kind of nice to just use the watch and start a thing without
it being, you know, looking like you're getting distracted too much.
So, so there it's like four apps that form one product.
So I think it's just different ways of looking at apps.
Leo Dion (host): What has changed as far as making a
product when it comes to orbit?
Because Orbit's your first main product, right?
Malin Sundberg (guest): Yeah.
It was the first one that we sort of built together once we started setting,
like once we started our triple list our company I, it was a while ago at
this point that we started with it, but I think we were definitely taking
more of a, I guess more of a product, a like traditional product approach.
We thought that this would be, was gonna be the one, like a thing that
we work on that we like them focus a lot on those surrounding things.
Kai Dombrowski (guest): Yeah.
For Orbit we had like, orbit was very different because we were.
I don't know, I wanna say force, but we, life events kind of made
us start orbit and not have a lot of other income at the time.
So we deliberately decided, all right, let's make this a thing that
we can actually sell something that we can make, you know, make enough
money off to, to pay for rent.
So we had like goals of like how many customers we want to have.
We built features that were for people we thought would then in
return, give us money for it.
But it was, we kind of built it, we built for ourselves.
There was like, that was kind of what it started as.
But from then on, we spent, I would say most of the time building features
that were not actually for us.
Which was hard.
Mercury came from a very different perspective.
That was the we were.
Orbit was really challenging and to kind of grow and we tried
to figure out a lot of things.
So Mercury was really the project of like, Hey, let's get back
to having fun building apps and not worry too much about it.
Like if it's fine, if no one cares about it, let's just build
something that we want to have.
There were we used a lot of, we, we were both big Weather app fans.
Some of our favorite weather apps were shut down.
Like we, we were, we liked Weather Line a lot, for example, that was going away.
And so we thought, all right, let's just build like our own new
favorite weather app and not really care about if anyone else you know,
wants to give us money for it it would be nice, but it wasn't a goal.
So that, that was a very different mindset.
We put it on the app store and people.
Ended up liking a lot more than we expected.
Which is nice, but it was not the goal.
We did not think, Hey, we need to have, you know, 600 subscribers on,
you know, by the end of September.
Otherwise, you, we have to figure out a better product market fit.
It's, you know, it's a weather
Malin Sundberg (guest): Yeah.
Kai Dombrowski (guest): people like, if people care about the
weather, they might like the way that we show the weather.
Leo Dion (host): Right.
Malin Sundberg (guest): Yeah.
And I think it was just like a lot of a, it was a very different
situation to be in where we could just build on it and focus on like
having fun and building something that we think is just looking great.
It's a big focus on Mercury, that it should be like a delightful app
that you like, feel like, that you're like, when you look at it and the
weather reflected based on colors.
Like it's just something that makes you a little bit happier.
And that was something that I wanted to, like experiment with, like having
that part of the design in there.
And it's something that, it was very much like us just like
focusing on those delights.
But Orbit was very much coming from a yeah, feature development in more of
a, like, fitting to users perspective.
Yeah.
Kai Dombrowski (guest): Yeah.
And for Mercury, we still had a lot of features that were like this.
We had a lot of ideas where we thought this would make a
lot of sense in a weather app.
No one's ever done that.
So we had, like, we did have a roadmap.
It wasn't that we're like, let's release it and not maintain it kind of thing.
We wanted to release it because it was summer that Irish 16 came
out, so it was a weather kit came out, swift charts came out.
So it was a lot of things that also, you know, we thought, hey, this is a
good opportunity to play with weather kit and play with thrift charts and we
wanted, we always have that, you know, when we're having have a thing we like.
If you work for yourself and you're, you have a lot of flexibility, setting some
kind of deadline is usually a good idea.
'cause otherwise you just keep working on things and you never ship.
So our deadline was, we wanna ship alongside I 16, which kind of, you
know, reduce the scope when you hear about new APIs in early June.
And, you know, you're gonna ship and those APIs and that
particular year, were also a little bit flaky in the beginning.
But it
Leo Dion (host): way it is with version one,
Malin Sundberg (guest): Yeah.
Kai Dombrowski (guest): Yeah.
But that of course compresses the scope.
So we're like, all right what can we actually have shippable by September
or whenever new iOS you know, you don't, it's also, it's an interesting
deadline because you know roughly when it will happen, but Apple's not
gonna give you the exact deadline.
I still remember the one year where Tim Cook was on stage at
a keynote saying, and what was it, Iris 14, it's shipping today.
Malin Sundberg (guest): Yeah, no.
I think tomorrow, like in 24 hours there was like scrambling.
Kai Dombrowski (guest): I was like, yeah, that usually
reviews take 24 hours.
What are they doing?
Yeah.
That was stressful.
Malin Sundberg (guest): So I think since that day we always assumed that like.
It'll be shipped the day after the event, whenever that event.
So whenever that event in September is announced, we think, okay,
we gotta be ready on that day.
Yeah.
Kai Dombrowski (guest): And worst case scenario, we have an extra week
to, you know, to get things ready.
So it's not too bad to be done too early.
Leo Dion (host): What was I gonna say?
Do you, so do you believe in like releasing stuff early,
as early as possible and getting into people's hands?
Or are you like, we gotta have it perfect before we put it out?
Or how do you balance that?
You know what I mean?
Kai Dombrowski (guest): Yep.
Do you wanna answer first on then.
Malin Sundberg (guest): I feel, I would say that we are more,
we want to be quite polished.
We there might be cer like I mentioned, if we know we have the
Kai Dombrowski (guest): I was gonna say the opposite.
Malin Sundberg (guest): I know, I knew would say that.
Kai Dombrowski (guest): polished.
Yes.
But we are also very impatient.
Malin Sundberg (guest): Yes.
But I would say what we do is to rather sort of narrow the scope.
Okay.
So I think it's different.
It depends on what, where we are at.
So try to com I want to have, if I release a new app or if I release a
new feature within the app, I want to, I wanna be proud of it on release day.
So I wanted to be polished enough so that I can feel like I'm proud of it.
And I would say that my, my level of pro, like me reaching for being
proud is like, it can, it's quite a lot of work to get to that point.
Like I'm pretty picky in that way.
So I would say it's pretty polished.
But one thing we don't do, which I'm quite happy with, is that we
don't hold features to sort of bundle them for a bigger update.
So if we wanna release a new, for example, we recently released like.
A new widget.
And we wanted to get that widget out there.
The widget was done and it felt polished and it was working nicely.
In the past I would probably have thought that made sense to like,
not just release a widget, maybe wait and bundle that with like
some other features that we're planning on building and the next
two months and sort of hold it.
But since since building orbit and having ongoing subscribers to like
people paying for a subscription, I feel more inclined to rather like release
the new features as we have them as like smaller updates so that people
actually can get the benefit of it as soon as they're ready because I don't
really wanna hold them back just to make like a bigger splash type of thing.
Kai Dombrowski (guest): Yeah.
And they're kind of almost conflicting incentives, right?
Because if you are from the marketing side of things and the
promotion and the PR and those kind of things, you have this.
Big 3.0 update, right?
Where you have a hundred new features and you have your marketing videos
and you have like a press release, you know that, that is a lot easier to
tell people in the press and tell Apple and, you know, get, try to make as much
noise as possible, but at the same time, that means you probably held a whole
bunch of really cool features for weeks or months to do all of that, right?
Because otherwise, how do you make a big bundle of it out of it?
And the other side is like, you have people that pay you money every month
and you decided to withhold interesting improvements from those people so
you can make it a bigger splash.
So I feel like we are definitely we are aware that we would, it would
probably be smarter sometimes to hold things and make them a bigger
release that we feel it's also, you know, just mentally it's, we feel
more comfortable talking about a big update than trying to tell press, Hey,
we made this really small, you know, improvement that just feels not as.
Easy to talk about than if you're saying, Hey, you know,
we reinvented weather apps.
That's an easier sell.
Leo Dion (host): How about as far as like test flight?
Do you do any test flight testing and like, are you like more willing to like.
Like, one thought I've had is like getting, doing a feature bundle,
but like releasing those features as soon as they're ready on test flight.
And then once testing is completed, then release that big version.
You know what I
Malin Sundberg (guest): We have definitely done like some
bigger test flights when we were working on features that we just
felt had so many edge cases.
So the, again, the trip forecast feature, it has so much time zone
calculation involved in it, so we just really felt like it was hard for
Kai Dombrowski (guest): as a background, the trip forecast feature is has.
50% more lines of code than the rest of the app, like the base
app, just as a weather app.
And then it's like, yeah the trip forecast is by far the biggest
chunk of code in the entire app.
Which is kind of, yeah it's sort of surprising, right?
Because it feels like it's an accessory to, to weather, but there's so
much that you have to think about.
And have to handle when you're building that compared to just
showing the weather at one location, because all of a sudden you have
one timeline that might span, you know, we show 10 day forecast.
So you could theoretically be in a completely different time zone
every single day of the week, and you have to somehow handle that.
And then what happens if the data takes over takes some places,
like in Australia where they have half an hour time zones, right?
What happens if the day just ticked over in Adelaide?
But while you're in Vancouver, it's not, you know, it's,
it hasn't ticked over yet.
How do you handle all that?
So there's a lot of, or you go for day trip.
What does that mean?
When does a day trip start?
When does a day trip end?
There's so much weird code that we to handle all of that and make it feel.
There's still one edge case that bothers me, but for the most part
it just does the right thing.
Once, once you put in all your trips and you're just, you know, traveling places,
it just does the right thing in all.
But one, one scenario that I have to figure out at some point soon.
Leo Dion (host): so, are you guys ready for this weekend?
'cause you know what this weekend is, right?
Kai Dombrowski (guest): Oh,
Malin Sundberg (guest): they let, are we changing?
Are we changing time?
Leo Dion (host): Did you test that?
Kai Dombrowski (guest): yep.
We did test that.
Leo Dion (host): Okay good.
All right.
Kai Dombrowski (guest): is looking kind of funny in the timeline when it's
like, it shows the same time twice,
Leo Dion (host): right, right.
2:00 AM or whatever.
Yeah.
Malin Sundberg (guest): Or in this scenario.
We're skipping an hour, right?
Yep.
Leo Dion (host): yes,
Kai Dombrowski (guest): Yeah, we're going forward.
Malin Sundberg (guest): Yeah.
Yeah.
But yeah, so to answer your question, I think in that scenario
it was just this huge feature.
Like we could not like justify for ourself to travel between
like five different time zones in a week to test this.
So we, we had like we had quite a bigger test flight group there,
that we could have people in those different time zones and
Kai Dombrowski (guest): And it, it's great.
We have a friend of ours is a commercial airline pilot, and
he's flying around all the time.
So he was an excellent Tesla user because he's probably of all the people
we know, the one that travels the
Leo Dion (host): Yeah.
Kai Dombrowski (guest): he ran into a whole bunch of edge cases that
we would've maybe found eventually.
But having someone that uses the fe a new feature you built
excessively is just gonna help you a lot especially when it com.
If it's, if it requires physical movement between time zones,
it's just a lot harder to test.
And even in a simulator, right?
You can do the best you can, but it's just no, once you're actually
on a, especially on a plane, right?
You are, you're usually in some kind of airplane mode.
You don't have location access.
Then once you come down, then phone realizes, and there's a
lot of things that are happening once, once you land again.
So that was a really good that we had someone that could test it.
So excessively
Leo Dion (host): how do you deal with paywalls?
Like what are you, like this is the thing this is the thing that
you have to pay for and this is the thing you don't like?
Yeah.
Malin Sundberg (guest): Yeah, it's a really good question and I think we
spent a lot of time on this before release in the first version, just
because something like Mercury has ongoing API calls and if we are giving
out like the main app for free, we're using those API calls and that's cost
that's is an actual like, cost for us.
So we struggled and we weren't sure how to strike that balance of like
providing enough things for free so people get used out of the app
to then like cover those costs.
In the end, what we wanted to do was to actually like, make it possible
for people to like experience the app and actually see what the app is
about and get the benefit, see how.
It would be useful in their daily lives.
And we felt like either we could add like, sample data for that or
we could actually provide real data.
And we felt like rather than adding sample data, it's not
really as relevant if you are if it's something you wanna try.
Otherwise, if we just add sample data, you would look at it for like a minute
and see and evaluate and then maybe you don't see the value of it in the same
way as if you would actually see how it is outside and how the temperature
and how the colors are changing
Kai Dombrowski (guest): even worse, you open the app and you're like,
this is not the right weather.
This app sucks.
Malin Sundberg (guest): Yeah.
Leo Dion (host): doesn't even work.
Malin Sundberg (guest): Yeah.
Kai Dombrowski (guest): Yeah.
Yeah.
So we ended up landing on charging for everything.
Like if you need a subscription for everything that makes
automated API calls.
So for us that is
Leo Dion (host): total sense.
Yeah.
Kai Dombrowski (guest): like the widget, right?
The widget, worst case scenario let's say it is we, our, we refreshing
the data more frequently when we know there's a high chance of
rain because that is more variable or when it is currently raining,
because then we wanna show you like a minute by minute rain forecast.
So the worst case scenario is you live in a place where it rains for 24 hours.
We make an API call as frequently as every 15 minutes on a bunch
of, you know, different factors.
But that might even happen while you're asleep where you
don't actually care about it.
But we need that data to be there by the time you wake up, right?
Because a lot of people, first thing they do is in the morning, they wake up,
they check their phone for the weather because that they have to get ready for
work or they wanna go somewhere, right?
So we obviously have to be, have to have that up to date.
So that's the worst case scenario, right?
Hitting the API every 15 minutes-ish for 24 hours.
That's not gonna happen if you just use the main app as a person, right?
You're not gonna, I mean, unless you're a super passionate Mercury
user and you open the app every
Malin Sundberg (guest): Yeah.
Yeah.
Because every time you open the app, we still fetch the data.
We still show accurate, like UpToDate data.
It's just for those sort of accessory accessory things that happen
automatically in the background, like with the widgets and Yeah.
Kai Dombrowski (guest): And then it's
Leo Dion (host): any, do you do any like server side caching at all?
So that way like bigger cities, you don't have to keep mul pulling it
the same data over and over again.
Kai Dombrowski (guest): It's really hard to do that if you still wanna maintain
a minute by minute rain forecast because that is such a narrow, you know, it
can literally rain on one side of the building and be dry on the other.
I'm not saying that APIs are necessarily all capable of doing
that kind of accuracy, but it's still like a hundred meters.
Wouldn't make a big difference or a hundred yards.
So I, we don't think, I mean, maybe if, you know, I.
If we grow to like Apple Scale, then it probably makes sense, but
at our scale, there's not enough people within a hundred yard radius
that it wouldn't make sense to.
So we just had to figure out a business model or like charge a price where
we can make sure that we can make those API calls for those users.
And if in the future we can ever optimize that that's, we consider that
a bonus, but not as, we didn't want any of that to be part of the calculation
of how much we have to charge.
And also weather kit is surprisingly, we're using a whole bunch of different
weather service providers depending on like different regions you're in.
And we're combining it in some places where the weather
data is not as fully featured.
For example, in Europe weather kit doesn't have minute
per minute rain forecast.
So we're pulling in data from open weather to show the minute
per minute rain forecast.
So, but of all the ones we're using weather kit is really affordable.
It's a really good, aPI it's not necessarily the highest accuracy
everywhere in the world, but from a developer friendliness it and
affordability to to get something off the ground it's really quite impressive.
Malin Sundberg (guest): Yeah.
And also I wanted to say that I think another thing to consider when we
decided to like make the main app free and actually show accurate data is
that we think there, there are many people who just wanna try it out.
And then we have noticed that like word of mouth is
actually one of the like big.
Sort of driver of new people trying it out and new downloads.
So I think there's also some value in actually like showcasing what the app
will look like at its best because you will get people who might not feel like
they can justify paying for a third party web app and that's totally fine.
And then, but then they might recommend it to someone or they know that they
have a trip coming up, so they'll try the trip to like, they will out knock it
for a period to try the trip forecast.
Or they have someone who wanna like try the trip feature.
And I feel like it sort of helps for that word of mouth as well if people
can actually get real value out of the free version of the app too.
Kai Dombrowski (guest): That's it for the widgets.
We do show demo data, but we put a big demo label on there to hopefully make
it obvious that this is not real data.
Yeah.
Because we still want people to see what it would look like, so you know
what you're paying for, but at the same time, it's getting too expensive.
We would make real a p code.
Leo Dion (host): That makes sense.
That makes sense.
Is there, so besides the weather APIs and besides weather kit and anything
Apple related, is there any other third party APIs that you've used?
Kai Dombrowski (guest): We're, I mean, apart from the other weather
services we are using only one extra.
Weather API, which is just to get averages.
So we're showing in the app if you hit the button how many sunshine hours
do you get a location over the years.
So the average for each month of the year and average rain
precipitation and average temperature.
But other than that, I don't think we're using anything.
Malin Sundberg (guest): No, not for Mercury, for orbit.
We do have the ongoing server, but
Kai Dombrowski (guest): Yeah.
That's our on backend.
Malin Sundberg (guest): yeah.
Or
Leo Dion (host): What, as you're building this app, how do you
decide what feature to build next?
Where do those ideas come from and how do you how do you like, I
don't know, filter out the ideas that you really wanna do, but you
probably aren't gonna help the business, if you know what I mean?
Malin Sundberg (guest): It, I think it's, we have had a very different
approach with Orbit versus Mercury.
The Mercury approach is very much us thinking of like different ways
of using a web app that we would be like excited to use it for.
So that's what Trip Forecast came from.
The way we are gonna add push notifications, but we wanna add
push notifications in a very, in a quite a different way from what
like Apple's weather app does.
And I think a core thing is that when we add a feature, we wanna
add, we wanna have a sec, like a new sort of spin on it or something
that just has a, something that's a bit more interesting that way.
I dunno really how to, I'm not sure if I describe it right.
Kay.
And
Kai Dombrowski (guest): No.
I mean, the most requested feature we get is to add weather radar.
but we just don't know, like there are apps that have
really good weather radars.
We don't immediately have a good idea of how can we make this any better.
So I think people that, for who?
The weather radar is the core thing.
They should probably use an app that's made by developers that
really care about weather radars.
It's just not a thing we're particularly passionate about.
We might add it in the future, but at as of right now, we don't have a good
idea of how can we make it better than some of the other apps that are out
Malin Sundberg (guest): Yeah.
Kai Dombrowski (guest): So rather than trying to like build something
that we don't care super much about, that we don't, wouldn't use
ourselves, that we don't even know, we wouldn't even be able to evaluate.
Did we do an excellent job?
Like, you know what do we look?
I looked at like Apples and I was like, huh, that looks kind of fun.
They use like sprites for like, the wind stuff.
And then we talked to a friend who's really into weather maps and
it's like, no, apples is useless for, like, all those reasons we're
like, we would've not known that.
We would've spent all this time on building a particle engine
maybe to make it look pretty.
But then there were like, you know, so I think we are trying to.
Do things that we can evaluate ourselves as, whether we
succeeded in what we set out
Malin Sundberg (guest): Yeah.
Yeah.
Kai Dombrowski (guest): for that, being able to build things that we want to
use and we cannot wait to have them built so we can use them ourselves.
I think that is from Mercury to focus.
Malin Sundberg (guest): I think that's just a good way for us to build.
Like to build features that are then like fun features to use.
Because if we are excited to build them, I think it'll be enjoyable to use them
and people will get value out of them.
I think something like weather Raiders that are like very much
like a user requested feature and not a ca mal and requested feature,
it's probably something we might still get to, but we really wanna
put that sort of special spin on it and have something that's like, we
don't wanna just check a checkbox and add it because people ask for it.
We wanna think about like, how can this be like special for Mercury?
Kai Dombrowski (guest): But it's also the feedback loop is super tight, right?
And we build something that we wanna use ourselves.
We try it on our app.
Like that kind of brings us back to the prototyping thing, right?
We have it on our phone and we're like.
It does sucks.
And then we make a change and we're like, cool.
That sucks.
Slightly less.
It's still not right there.
And we just keep going until we're like, cool.
Now we're actually happy with it.
With something like the radar, we would be like, I guess that's fine.
We wouldn't really, and then we would have to send it to people that then
give us feedback and we're like, yeah, that, I guess that makes sense,
but I wouldn't even know how to necessarily classify feedback when,
you know, people have conflicting ideas of how, whether radar should work.
While at the moment we're kind of in a situation, if someone tells us
they want it this way, but we really want, think it's better the other way.
We feel like we have a strong opinion on why we're doing it the
way we're doing it and we can just keep going and we're not, you know.
Getting ourselves bogged down by trying to figure out what person, whose values
in this particular feature we don't understand might be the best to give
us feedback and who should we follow?
Like there are some products for that, right?
People often talk about like getting a lot of user feedback and then iterating
on a product, but which we definitely do more on, on the orbit side because
there's so many more use cases.
But on a weather app, we just feel like there are so many options and
the cost of trying all the ones on the app store is so low, right?
You can just download a hundred weather apps if you want and
find one that works best for you.
So if we keep focusing on the things that make the app better for us and like
things that we feel like are interesting or clever or just fun to use, there are
probably enough people with that share our values that there's enough that.
People, you know, also get, get enjoyment out of using what we built.
Leo Dion (host): Yep.
Yeah, I think it's a really, because it's like so hard to get
feedback, I've found anyways.
Getting feedback from people and just reaching out, like just I.
It's not as high of a priority for other people as it is
for those who make the app.
So it's like, like, which is an obvious statement, but you know,
it's something you gotta think about.
So I like your idea about like just focusing on what you wanna do and what
you like to do and what you feel is like part of the big picture of the app.
I think that makes a lot of sense.
Kai Dombrowski (guest): But it's also, it's, Hey, I know
that doesn't always work.
Right?
It really depends on what you're working on.
If you work on some, like Mercury was a thing that came from that, right?
We build it for ourselves.
That was the main objective was something we enjoy using and just, and
the fact that other people enjoy it.
Solidified that, that kind of decision making process in building,
in building Mercury for that, that would've never worked for Orbit.
Because for Orbit we use it in one very particular way, but
we have so many people that, that have legitimate reasons.
Like we have a lot of people that lawyers that use Orbit and
they need to round the time.
They track to the, they round up to six minutes.
So they have like nice decimals on their invoices and they round
up because they're lawyers.
And lawyers always round up.
We will never round up, right?
If we work on client projects, why would we round up?
That's not time we spent on the project.
We just used the exact thing.
A friend of ours runs down he, he wants the nice decimal numbers
on the invoice, but he does not wanna overcharge, so he runs down.
Like those are things like, it makes sense that people have different.
Different priorities on those, how they invoice.
Right.
That makes sense.
I wouldn't say, Hey, all the lawyers in the world should invoice
exactly the way we do it, because that's the way we like to do it.
No, that makes no sense.
Right.
For orbit, we totally have features in there that we barely use.
We still, but they were still features we understood.
Right.
We're not building tax accounting systems for you know, for
foreigners living in Japan.
Like that was one request we actually had.
But that's like, I, how would you even get into that?
Right.
You now have to learn Japanese because all the tax documents in Japanese,
the chances of things changing there are so high and we would
not be able to keep up with that.
So we are just staying away from the things we know.
We have no, no business to be in and we would not be able to maintain,
but we are still building things.
If there's, if people have legitimate reasons that they need
a feature, we're still trying to
Malin Sundberg (guest): And if there's this, if there's this one feature, like
the rounding that sort of unlocks it to be used by like all those people
in the law like in different law firms, then that's, that makes sense.
And it's like a broader request that a lot of people will get benefit of.
So it made a lot of sense to add that.
And we understand that like everyone isn't working in a way that we work in.
So they would use Orbit in a different way, but, and I think
if those features weren't there, they just couldn't use it.
But I think something like Mercury, if there's one feature that's not
there or one feature that works different from what people are used
to, that's not necessarily a problem.
That might just be that they are using a weather app in a different
way from what we do and they are like happy to try something else.
So it's
Kai Dombrowski (guest): And you can also use.
And you can use multiple, right?
There's no problem.
You're not gonna use five different time tracking, invoicing apps.
That's just gonna, I mean, you could, but that becomes
really confusing real quick.
But I pay for four or five weather apps just of, you know, other indie
developers that I appreciate and that I wanna support, and that, you know,
they work on interesting things.
So I'm happy to like, switch over to something else and have a look there.
And, you know, that's there, there's not a lot of, you're not gonna have
an incomplete picture of the weather if you're splitting your weather app
time between like two or three apps.
That's totally, I think people can do.
Leo Dion (host): Before we close out, I have one more question.
Kai Dombrowski (guest): Make it a good one.
Leo Dion (host): those aspiring indie developers or perhaps just someone
who has a really great idea, what should somebody think about before
they go ahead and build that app?
Malin Sundberg (guest): That's a tough question because it's so, it is.
I think it depends so much on the idea or the specific thing they wanna build.
But I do think like generally what we really like is to have something like
I mentioned, like with the prototypes.
Like have something that you yourself can use quickly.
Because then that will sort of, it's so sort of two purposes.
It helps you to evaluate the idea and evaluate if that's what you
wanna continue building and where you wanna take that app or the product.
But the other thing is just.
It really serves as a motivation.
And I think many of us had that the first time we
started programming as well.
Once you program something like once you even just like program, I think
we talked to someone else about this recently, even if you just like
program your first for loop and you see something being print like an
iterator being printed on the screen in front of you and you wrote that,
like, that was such a exciting part of like learning development that you
you made like a computer do something.
And I think having a product in mind and like already having a prototype and
like sort of seeing your idea come to life can just be a very cool motivator.
If it's something you, that you might not have, like you might not
be able to spend like all your time.
Like you might, you probably didn't like quit your job to go full in on this.
It might be something that you only do in the weekends
or on the in the afternoons.
And I think having that initial sort of prototype serves as a
motivator of like going back to it and continuing iterating on it.
And continuing building it.
Kai Dombrowski (guest): I would also say try to find someone
that's, that you can trust.
Being brutally honest with you, we kind of have to build in, right?
If I design something, Marlin might.
You know, completely trash it.
Because sometimes that happens, right?
You work on something, you're like, I think this is fine.
And you don't realize the things that are not good until you either step away
for a while or you get someone else and you see them using it for the first time
and you immediately get this feeling in love of like, oh no, this is you.
I now see why this is not good.
And if you have someone, and it's, that's kind of bringing us back
to the, getting feedback is hard.
I think it's a good trait in people.
Most people want to tell you the things that are good.
You know, if you show them something, it's like, look, I
put a lot of work and a lot of sweat and tears into this product.
What do you think most people's instinct is not to say, here
are all the things that suck.
Right?
Most people want to tell you, Hey, good job and I really love this.
But I think if there is a lot of value in having someone in your life, ideally
someone that will continuously, that you continuously trust with those kind of
Malin Sundberg (guest): Yeah.
You don't just ask the question once and then that answer the relationship.
Yeah.
Kai Dombrowski (guest): But if you have someone that, that you can show things
and they will tell you, I like the functionality, but you, I really need
some work, or, this is kind of annoying.
And even if you're not immediately saying, all right, I implement
everything this person says, but just having someone that kind of pushes
you out of the kind of tunnel vision of you build something back into
like, all right, let me step back and see does this actually make sense?
Is this actually beautiful?
Does this look as good as is?
Does this look the best it could be?
You know, we had some when we built Mercury in the beginning in the early
days, we had a friend that constantly complained about the performance.
And we're like, yeah, but you know, it's a new API might get better.
We didn't wanna spend time on it initially because we're
like, surely it's gonna be fixed by the time I 16 ships.
And then we just got used to it and didn't think about it
anymore, and we shipped it and.
Then this person kept nagging us and we're like, you know,
you're actually totally right.
This is we just accepted it at some point because we kept, you know,
it was just part of our cycle and at some point you got used to it.
So we finally then, like, I, I think it's a year ago now, but after
shipping it, we finally tackled the performance issues and the app is
so much better as a result of that.
It, I don't think you get a lot of people that say, I
downloaded this app before because the performance is better.
But there were just so many things that just now, every time you open
it, everything is immediately there.
Before that, we would always show like a placeholder.
It's, it was,
Malin Sundberg (guest): it just feels a lot snappier as a result of that.
Even if it's something that people don't notice that it is
there because they wouldn't, they would notice the absence of it,
Kai Dombrowski (guest): Yeah.
And that was super valuable feedback and being persistently honest about that,
it's still not good, just helped us.
Not that we didn't, couldn't have realized it ourselves,
but having someone that, that keeps telling you, that
Malin Sundberg (guest): It sort of holds you accountable to it as well.
Like you, you really gotta do this.
Yeah.
Kai Dombrowski (guest): Yeah.
Helps you to, you know, get off your tunnel vision of, you know,
we all do that sometimes, right?
When there's, when we use a New Swift, your API and somehow the
scrolling is, you know, drops frames.
You're like, I guess it's an Apple thing.
What are you gonna do?
Maybe it's getting better in the future, but if you have someone that
nacks you about it, you're like, all right, maybe I can actually improve
my, the performance here somewhere.
What do I do in this role?
Leo Dion (host): That's what I hate is like those blind spots where it's
like you get used to something, doing something and you don't, you just
get, you know, it rolls right off you, but then you get a new user to
use an app and then they notice those things and you're like, oh yeah.
I didn't notice that.
That was really crappy.
I should probably fix that.
Yeah, I totally get it.
Kai Dombrowski (guest): And it's also, we if there's like a meetup,
like a developer meetup in the area, it's also, if you don't already have
someone like that, I think meetups is.
It is a really good spot to find a whole bunch of people that are
really passionate about, you know, IS development, apple platform development
or mobile development in general.
To find those kind of people.
And also, you know, if you get them to, if you watch them use your app
for the first time, and even if they don't tell you, you can see, you know,
if they're, like, if you just read the face, like an impression someone
has when they like, something doesn't work quite right, you're like, oh,
yeah, that actually makes sense.
And being
Malin Sundberg (guest): Yep.
Kai Dombrowski (guest): also then to be able to take that feedback
is, I think, also important.
Because if you tell someone, Hey, stop being so mean to my app, they probably
won't keep being honest with you, but if you're, you know, if you're sitting
there crying because they, they said the text is too small, I think that makes
it harder to give you honest feedback.
But if you're showing appreciation, I think people will.
Try to be honest and give you useful feedback in the future too.
Malin Sundberg (guest): Yeah.
Leo Dion (host): Kai and Malin, thank you so much for
joining me for this episode.
This has been fantastic.
Oh, before we close out, I'll let you go ahead and plug your
social handles and URLs and such.
Malin Sundberg (guest): Yeah.
Kai Dombrowski (guest): We are really bad at introducing ourselves or plugging
our own stuff, so it ends weird.
It started with a struggled introduction and we'll end with a struggling plug.
Somalian you the
Malin Sundberg (guest): Oh yeah.
Thank you.
I think this is okay.
This is a hard time to share your social media handles.
This is gonna be, do you have another 10 minutes?
Yeah.
Yes.
But yeah, if you search for most places, I'm Malin Sundberg you
can just search for my first and last name after one another.
Apart from, I think you would find, I think I have both accounts on Mastodon
as well, but my main one you can find me at is just Malin at Mastodon Social.
And in most other places it's Malin Sundberg just my full name.
And yeah, if you wanna also check out our apps Mercury weather on
the App Store is probably the easiest way of finding that.
And Orbit is a little bit trickier because we wanna have
a cool name, but it's a little bit hard just searching orbit.
So if you're interested, go for Orbit ti search for Orbit time
tracking, or go to time and orbit.com directly to our website.
Kai Dombrowski (guest): And I made it a little bit harder.
I have completely different, not completely, but mostly
different names on all the things.
So er, Kai on Twitter that was a name I picked when I
was really into basketball.
Ka broski on threads and I think just Kai
Malin Sundberg (guest): Really?
Yeah.
Three different ones.
Kai Dombrowski (guest): I think so.
I think I, I made it as hard as possible.
Yeah.
I think Kai at Masteron Social on Masteron.
Leo Dion (host): So we'll put links to those in the show notes.
Thank you so much Kai and Malin.
It was great to see you again.
Malin Sundberg (guest): Yeah.
Likewise.
Thank you so much for having us.
Yeah.
Leo Dion (host): People can find me on X at Leo Dion Mastodon at Leo Dion
at C am My company is Bright Digit.
You can go there for the latest articles and podcast episodes and
videos and all that fun stuff.
Thank you so much for joining me and I look forward to talking to you again.
Bye everybody.
Kai Dombrowski (guest): Bye.
You're better at this.