Bang, boom.
All righty.
Bruce, I sent you a little reaction to the prep
that you gave yesterday.
And so let's just dive in with whatever you've got in mind
and see where we go.
Awesome.
I replied with a link, but I'll paste it here
in the chat as well.
If you want to bring it up, or I can maybe talk through it
or present it where it is at.
And Lucian and Janata and I have gone really deep in on this,
and the others are not as into it.
So it'll be a good recap to kind of show where we're stuck.
Yeah, sure.
Yeah, feel free to open that up.
And I'm especially curious to hear this kind of from
a framing perspective of sort of like, why is this happening
now, and what, you know what I mean?
Like, what's the win?
Yeah, that's good.
So yeah, so we've got the frame doc.
We have a little monster map task grid,
which we've called it a task grid in our team.
And the process is, I mean, so just to step out,
like generally, I feel like the process is working.
It'd be interesting if anyone has other feedback.
But from my standpoint, I feel like we're really
being consistent between projects.
We've changed our Notion template.
So there's like, we have the breadboard, Figma,
BigJam file there.
You have the task grid link out.
And then we just have our framed doc,
what we used to call shaped doc, which was like problem,
solution, out.
It was a different set of things.
Now we just have the problem outcome, what we're not doing,
and then an appetite.
So this is kind of four sections.
So that feels pretty standardized.
We had some cases where we accidentally left a bullet in
or put a very unclear bullet in the frame doc.
And we've used our framing doc when
we're working with clients kind of as our contract.
So that becomes the thing we default back to.
So that's caused us to be extremely precise
and kind of treat it like using the words
to be kind of a lot sharper to either include something
or to exclude something very clearly
and not have vague bullets in there as much as possible.
So in other projects, it's working great.
I feel like, I think overall, we're implementing it.
We're doing it.
I feel like we're implementing each piece.
This one was interesting because it's our project.
So we can kind of dictate how we want to work on it.
And part of the reason why we've kind of procrastinated on it
is because it's just been, we've just
done other things that were more interesting or more
useful at the time.
But we keep kind of like kicking the can down the road.
So eventually, we're just like, we got to eventually talk
about this piece.
And so this is interesting because it was too big
and we couldn't quite wrap our heads around it.
We just kept, it was just this kind of blob out there
of things we didn't really know what to do with it.
So we had started a project, Lucha and I,
and Gennady did a three hour or so deep dive shaping session
where we like pulled all the pieces out
and started to pull the whole thing apart.
So we have a FigJam file there.
And I can, if you want, I can walk through some of it
as I talk, or I can let you, if you have questions, jump in.
Yeah, I'll just ask, because I pulled up the notion
and I see here, yeah, so I see all these issues,
like there's like performance issues,
there's different domains,
like you've got unnecessary redirects,
like, and I get how these things are bad.
The thing I'm curious about is like,
just for me to wrap my head around
what this project is really about,
like these things are kind of,
these things were probably all true for how long?
Like for like a year plus?
Oh, they've been true, yeah.
You mean like-
How long have these problems been kind of existing
as problems?
At least two, a year and a half, two years, maybe?
Yeah.
The two domain thing has been around since we started.
And it was like, instead of building on top of the app,
we just kind of built next to the app
on a totally different tech stack.
And so it's just caused issues.
So what, did something change where like,
we can't live with this anymore?
Or did the criticality change?
Is there something you're trying to do now
that you can't do because of this?
Or, you know what I mean?
Is it like, actually we finished everything else
and now we just have an opening
and we don't have anything else that's kind of more?
or important to do, therefore we're going to finally do this
because we have the capacity for it.
Like what's, what, what changed in terms of, in terms of the
context that you're like finally doing something about this now.
I think as we're like, um, so we were, it was very much like
an enterprise sale, so we were, we would go and set everything
up manually for people.
It was very, like, it didn't, the main thing didn't matter.
Like some of the redirects that didn't matter too much.
It's that we're trying to like streamline onboarding
or simplifying the workflow.
The underlying stuff is really around, like, it's confusing.
We have the two domains.
Technically, that's not a problem, but, um, the, uh, it's as we're
trying to like, think of like, how do we do a streamlined
onboarding process for a new client?
Now we have, it's just, we have this sort of underlying big problem.
It's like, well, we have two homes next to each other.
So we're trying to figure out how to like get someone a nice,
you know, tour of the house, except there's two houses next to each other.
And so it's already confusing, like, well, clients, you know,
admins and stuff don't know.
Am I supposed to be in this house for this thing or this other house
over here for this other thing?
Um, and so we can keep like putting hacks in, but to me, I feel like
there's a fundamental piece there, uh, needing to move to maybe one, one thing.
Um, um, did, how did it happen that, um, uh, streamlining
your onboarding became a topic?
Did something change with the number of clients you have or the way that
you're servicing clients or the mix of things you're doing?
It, so it was more of an issue, more of an issue where we, uh, we kind
of had this enterprise thing and then we started, we were going to
restructure it to have like an, basically we have a white labeled
version of tribe, and now we were thinking of having a non-white
labeled version, so something that would just be a tribe social group
that would be a massively reduced price.
So instead of, you know, 30,000 for the year, it's like 3000 for the year.
Um, so you, if you didn't want the white label piece, um, we were going to
make a much more streamlined version that coincidentally, since the, because
it's taken so long to talk about this has like shifted to not be quite as
big of a thing, um, but still, even if we have enterprise clients, it's
confusing to train their teams on where everything is and jumping between
these two platforms is still complicated.
Um, so it's, it's just, uh, it's difficult for new users to get, to
feel like they're in control of it.
And that's really important that our clients, the teams like who are
supporting the app feel like they're in control of it because, um, that
makes them successful and, you know, it means that they keep on with the platform.
do I understand, right.
That there is a kind of a concern that if you don't, is it, does this, does
this concern you that like, if we don't do this project and we don't change
this, um, that like this, this, this confusion, this onboarding, that this
is like kind of like a bad experience thing that, that somehow hurts us.
Um, yeah, I think it, uh, I think the thing that we felt, so maybe it's
like to zoom out, like the, the, the blocker that we identified when
Lucha and I talked was like, um, and, and this, we, um, we feel like we're
being held back right now on creativity because there's this, it's kind of
like we're building between these two houses.
We don't know where we're going.
to put a new feature.
Um, so it feels like it's a blocker, not so much this kind of going down a
rabbit hole in the smaller new users.
I mean, we definitely want the new users, but maybe a more important thing would
be, um, like if we feel stuck with the, with users, uh, with, um, like putting
a new feature in, like we have a, a go live, uh, a meeting because, uh, Google
meets type experience, which we have kind of working in the app.
It's not great.
But if we wanted to go and improve it, it's like, do we really want to spend a
lot of time working on this, this other platform or do we want to build it
back in the core part of the app?
Um, so one win that we had out of this, which I could, um, better
illustrated in the task grid in monster.
Um, cause you can see how we sort of chopped up the project.
Um, I don't know if you want to go that deep yet, but, um, we essentially
did this first square here where we figured out we could like, we actually
one big clarity moment of clarity that the shaping process brought out was.
We felt very constrained by these, like one set of clients that what
we called like legacy or V1, and then we had these new.
clients that are what we're calling like V2, they're actually two different types of apps.
And we kind of are all built on top of each other right now.
And so one way that we, we kind of found this very small thing that we could like split
the code in like a V1, V2 inside the, you know, app.js script file.
So we could actually split the experience to two different sides of the app.
And so it let us like build in the JavaScript app, one of those two versions without, because
we couldn't change stuff for the V2 clients without breaking stuff for V1.
And we couldn't fix things for V1 without V2.
And so there was a huge moment of clarity.
And Lucha and I, or we've already implemented this.
So that part's done.
And I really feel like we've got some value from the project.
Because now we've suddenly felt like, okay, if we did want to add a feature, we could
put it over here.
Like we now have a place for it without running the risk of breaking.
Yep.
Okay, good.
I'm, okay, good.
So I, so I'm caught up.
So, so what this, this is actually about, so there, there are, there are some things
from the customer side, but really what's driving this is like, there's things we want
to do.
And we feel held back from doing the new things we want to do because of the gnarliness of
how the V1 and the V2 were kind of tangled together.
So if we can kind of clean this up so that we have like this better thing to build on
top of, it's, it's not so much that like, we're going to get an outcome specifically
from this work.
It's more like, we're going to be able to unblock this other work that we want to do,
which is like the new features and stuff like that.
Is that right?
That's good.
Yeah.
I don't know if Lucian or Jonathan has any other feedback I didn't include, but this
is sort of the summary of three hours of conversation.
And there is a, if you go to the, back to Notion, there's like a fig jam board.
If you go, yeah, this, this one, a thread board.
So we, this is very all over the place, but this is sort of the raw, now it's just kind
of has the framed piece we started.
And I think I shared it with your Hey email, but I can, if it's email, but you can keep
going in your, I don't want to take you away from your teal draw.
So, but if you kind of scroll to the right, we, we, we we summarized exactly like you
said here, step one, set up for fixing stuff and then step two, fix stuff.
So we just said, there's this piece we need to like figure out how to like, and that's
where you can see like the 1.0 was this like more of a streaming platform.
And then two was very much more like a, we kind of call it like there's a Netflix type
experience.
And then there's a Facebook type experience.
They're all under the same app.
And that's what was confusing.
We've only been selling really the, the 2.0 version, but we're kind of constrained with
like 1.0 sort of infrastructure.
And they, they started to compete with each other in some places like, yes, they both
have video.
Yes.
They both have users.
Yes.
They both have analytics, but they start to get different the deeper you go into it.
So that's where just splitting it out was, was helpful.
So at least now they're like on the, in the code space, there's a directory called V2
components and we can start to throw V2 stuff into that.
So it's just, there's nothing much more useful there.
I just illustrating that we kind of use the process to sort of get that point of clarity.
And then now we can kind of move on.
And so the rest of the project so far was just like chopping up each of the different
pieces that I would have to move over.
We've also considered like, Hey, work has been done.
A thing has been done.
Like, could we call this the project and move on and then just turn these other things into
projects?
So that's where we thought it would be helpful to, and this is very common when we have a
client.
So we had a client come in and they had built an app for two years.
They came to us now we're kind of building the next feature.
So we had like, and they had like, you know, eight things they want to change with the
app.
So this is a very common thing where we have a lot of things, different things we need
to change.
We need to sort of figure out how to chop them up into meaningful pieces of work and
try to identify or surface like what's really the underlying issue.
And then can we get a lot of value, which we kind of started to do that here.
We figured out like, Oh, it's this idea that we have two different things going on and
we need to split it out in the code very clearly, like one and two.
And we could push that into production and keep moving forward.
So we did ship that.
That's kind of in use already today.
So this slice, you could, you could call that done.
Yeah.
Uh huh.
Okay.
And so where do you, like, I can comment on things,
but like, where do you start to feel
like there's something that you're not,
you're looking at here that feels like,
either like, I kind of feel like we're stuck
on where to go next, or I feel like we have a path
for where to go next, but there's something
that I don't like about it, or I'm not sure about it.
You know what I mean?
Like, where would you wanna kind of put my attention
in terms of like, here's the place
where I'm not sure about?
Yeah, I think, so the first piece is done.
We've now got, you know, six or seven other
sort of scopes, you know, to kind of work through.
I just wonder, so we can't just do groups by itself.
We can't just do the notification center by itself.
We'd have to do each of these to get it
to a usable point to where we could actually
put a client into, to start using it.
The cool thing is we do, you know, have this way
where we can, like, release different pieces of it
and turn specific platforms to V1 or V2.
Like, we can control which experience they have.
But I can't just, like, I can't turn groups here
into NJS, this first scope, can't turn that really
into a one or two week project and then ship it
because there's nothing usable at the end of it.
So maybe the question is, like, do we sort of keep
all these under the surface in like a, you know,
and then kind of put the whole thing out there together
as one bigger release?
Or is there, like, do we need to kind of,
are we thinking of it too much, too modularly?
And, like, maybe there's a vertical slice of this
where we get, like, something can go shipped
in production quickly in two weeks
and we get instant value from that.
And then we kind of do that, then we add to it
and add to it and so forth.
Help me out with something that's not tracking for me.
When I look at this, I see two to three days,
one day, one to two days, and it kind of feels,
it gives the impression that this is all kind of trivial.
Like, so what, help me, help me with that.
So there's this new thing called AI
that we've been leveraging as well.
And we, so part of what we've done is,
and I think we're doing this in a kind of a unique way
is we've like, we've taken the two extremes
of this product process.
So like this part that you've been teaching us
is the human piece.
It's like, we nicknamed it the founder therapy.
Like you even did it now to me,
and you're like, what's really bothering you, Bruce?
Like, tell me more about that.
And I just like sit on the couch
and you tell, you know, that's kind of the mode.
We do this with clients all the time
because they get frustrated with something.
We go like, okay, well, what's really bothering you?
Like, can you tell us more about that?
Why?
So that's sort of, there's this human piece of it,
which is very real and we have to untangle this chaos
and bring it into some clarity.
And this whole shaping, framing process
we've been doing with you has been phenomenal
to get things concrete.
Cause then it turns it into kind of translate it.
Once we've got it concrete,
we can get a really clear plan.
And then we've been built working to build
like a project requirement doc that is AI friendly.
And then using something like cloud code to like-
Move these things.
And one thing cloud is phenomenal at,
but refactoring code from one thing to another,
very, very reliable.
So we kind of had this challenge like,
this massive project's been looming above us,
which like this could be a four to six month endeavor
to go and like redo this entire thing.
So yeah, but what if it was like two weeks?
Like what if we just did it in two weeks
and we got a version of it
where we got super clear on the requirements
like we're doing here.
And then we did the super precise,
like refactoring with AI and then cleaned some pieces up.
We probably could get like a,
at least a early release version that's maybe not bug free,
but it's a working version we can start to build on top of.
Totally.
In two weeks, kind of as a challenge to us.
So that's why the estimates are ridiculously small.
And we do have a functional production code in Flutter,
which we can use as a reference.
So we're just, we would be moving,
like instead of the Flutter UI to read out of the database,
we would be using JavaScript to read out
of the same database.
It's very, very much the same
that we could pull from one feature to the other.
We're not having to think through UIs and experience.
And one of the requirements,
one of the things we're not doing, we listed out,
was we're not changing the UI.
No behavior change.
Yeah, just keep it as, you know, so that's kind of where we got stuck.
And Lucha and Jonathan and I were the ones working on it.
I don't know if you guys want to weigh in on your thoughts.
I know we talked about just making this a project and calling it done and then chopping
it into something else.
And part of it is because it wasn't super clear, we kind of have a scale, like people
were like, we start to think like, oh, we're finished this step.
And then even internally, we'll say, you know, this feels about 40% shaped.
This feels about 30 is like, actually not, we're not in the 80 90% mode here.
This is maybe 60% clear.
And so because it wasn't super clear, it just got put on the back burner and we've done
other client projects.
So this, this, we opened it up, like maybe six weeks ago, did a week of work on it.
And then it kind of just sat there and we just sort of came back to coming back to it
now.
Yeah.
But yeah, so.
OK, let me ask you a question here.
So what is what is plan A?
In terms of if you don't, if we didn't have this session today, what's your what is
here and what's your approach?
We could start.
So.
Well, the plan A is we kind of we've been doing plan A, which is avoid the problem and
just do other work instead, which is what we've been doing.
OK, so OK, but let's say let's say we've we've we've at least cracked the seal of
like, you know what I mean?
Like we've we've we've broken the seal and we are like in this in this refactoring.
Yeah.
OK, I got I got to ask you one other thing, actually, because I'm still not totally
clear on the framing piece.
So what I'm trying to do, I'm I read this, but this this isn't really helping me to
understand why anything needs to change.
This to me is a little bit more around these are things we don't like and these are
things that we want.
When when when when I started to question you about this and I started to get this
story of like we don't know where to put the new feature, we've got stuff we want to
do, like we could put it into V2, but then it breaks V1 and it's like it's holding us
back from this other stuff we want to do.
So we're going to split the experience into these two different camps and then we're
going to have a clear place to build new features without breaking the other stuff.
Like this is a frame for me.
This is something where I can understand why you're choosing to spend time on this.
Do you know what I mean? Because like not having an answer for the for the new things
you want to do and like every time feeling like, oh, you know, like that's something
that at least kind of resonates with me.
What I don't understand is when when you kind of explained how that was sort of the
step one of like, first, we're going to have two separate camps, right?
We're going to have a separate V1 and V2.
We're going to do the code split.
How does what happens if you don't fix these things?
Is that some other problem?
Are you already out of the woods that like now that we've done the code split, if if
we wanted to build the new feature, now we know where it goes and everything is fine,
like what so like what is this stuff about?
I again, back to the house analogy, like we have like built on this separate house on
the same property.
Now we've kind of said, cool, we kind of have a big open.
Let's say we're going to add a second story to the house and that's where this new
thing's going to go. Only if we at this point, there's no rooms that are finished.
We couldn't send anybody into that yet.
So we couldn't add a new feature to this group's piece because right now the entire
application is still sitting on a Flutter app.
And so the V2 piece doesn't V1, V2 doesn't actually affect the current app that's out
there. I don't know if that makes sense, but there's there's kind of there's two
different actually two different apps running, like say two different houses and only in
the one app, the JavaScript side, did we add the V1 and V2 split?
So it's great if we want to add new stuff, but we have to get it to a point that's
that has enough of the features to where we could start to use that.
OK, OK, hold on.
So let's let's I need the concreteness in order to to to.
So let's spell this out.
So this is this is the current world.
And this is going to be we'll do this as quick as possible because this is review for
the rest of you guys, but this is to catch me up, can you describe to me in more detail?
The architecture of what you actually have in terms of different apps.
So there's, there's, there's the V1 V2 is about us is about a, is, is only
about one app and there's multiple apps.
Yeah, there's, um, I'd like, I know we've drew, I thought we drew this
somewhere and I'm trying to find it.
So you don't have to do it again, but, uh, yeah, so there's basically like,
um, you can go, there's a JavaScript CMS app here.
Um, that is, um, so we use it as a, do you call that something?
Do you have a name for that?
We have, I think that's, I mean, let me just call it that.
Um, okay.
So we just, it's one's JavaScript, the other is Flutter.
So that's how we've split it.
Um, this, the, what is the, what is, okay.
So you said you have a JavaScript CMS app.
Um, this is a content management system.
Uh, yeah, it, it, it, the legacy though.
So the 1.0 clients would use the front end of this to be more
like a Netflix experience.
And we started to build groups and other experiences into this.
Um, the backstory is that we then figured out that, um, we
needed iOS and Android apps.
So we switched to Flutter for Android and iOS, and then we realized
we could just build the web app.
When we were very resource, um, like we're tight on resources.
We just said, let's just make the Flutter web app, the web
domain that the clients see.
So they have like a web Android and iOS apps that come off
of this Flutter code base.
Um, uh, okay.
Um, so this is a single code base.
That's giving you all three apps.
Yeah.
And, um, so do you, do you, do you, in your mind, is this one Flutter app?
It just happens to compile in these three different ways.
Yes.
That's the same code base.
Yeah.
Got it.
Okay.
And you built groups here.
Um, we built like a, yeah, we built groups in sort of like a, call it V1 groups
there, and then we built V2 groups on the other one and the app is really.
Uh, the entire thing is a group.
So that's kind of the main thing.
It is, uh, uh, this is, this is a, this is a, this is like a key feature.
This is like, it's the feature.
So like you would, it's kind of like if Basecamp had projects, like
it's, it's, you just, it's the whole thing is sort of contained in a project.
Um, so this is like architecturally architecturally, many other things
are dependent on this thing.
Yes.
And all features kind of are enclosed inside of a group.
Yeah.
Um, and so because of this, we basically started adding pieces in the
JavaScript CMS that would then control the V2 groups, like, uh, would
update things, would, would change.
So we have basically, so that's why you're kind of in, because we needed
to have one place that the clients go to upload content and, um,
at the core of it, like it might be helpful for clarity, like in the
JavaScript CMS side, there's like the backend, like the admin side and
the V1, like end users, we're seeing this just because for us, it's
clear, it may be like helpful.
So, so I say that again.
Um, uh, so in the, so, so in the, um, uh, JavaScript CMS app, there is a backend
admin, and that's, that's not part of the Flutter code base.
Flutter is relying on the JS CMS app for the,
it's like that thing that you wrote pieces that control V2 groups,
part of like the, the backend admin.
Ah, this is, this is part of the backend admin.
Yeah.
Got it.
And then there's like the front end there's V1 and V2.
Yeah.
Like the actual end users, they, they would go to V1 or V2.
Um, and so, um, JS CMS app has a front end.
Yeah.
And, um, uh, thanks for being patient with me.
Front end, what you said, V1 and V2, like what is, what, what, what is this,
what, this is, what does it mean?
V1 or V2 in relation to this front end?
That, so the, this is what the new piece here is that we split this to where
there is now a V1 and a V2 front end before there was just kind of V1 front end.
Okay.
Um, so let's just say, um, uh, so I'm actually going to draw
this as world before code split.
Okay.
Um, there was a V I'm.
to recognize the pattern. We're unpacking a bunch of stuff that's in your guys' heads, I think.
So there was a v1 of the frontend that was already there in the world before the code split, yes?
Yes. It was just called frontend, though. It obviously didn't, it was just, yeah.
Okay. And this frontend, was this not used because you were actually pointing customers
to this, or were people using both?
Clients were one or the other, they were never both. So some clients were only using the left
side of that column, and all new clients really were on the right side, so the new thing we were
selling. Okay.
Don't worry, this is the simplified version still.
I'm with you, we're doing all right. Yeah, but we're at least getting closer
to the point where we can start to talk about it. So in this, okay,
in this world, before you did the, okay, so can you just describe to me in more concreteness
what motivated, what did splitting the v1 and the v2, what was that supposed to allow you to do in
terms of the frontend here? So we have this groups v1, which is,
in all sense, on the left side, depreciate, like we don't use that, we don't have active users using
it. So because it was so, it hasn't been touched for years, so in fact, pretty much everything on
JavaScript CMS, we hadn't touched for probably over a year until end of last year. So once we
started adding pieces, and we kind of committed to like, okay, we are actually going to keep this
JavaScript thing, this is, we kind of, we didn't know getting into, when we got touched Flutter,
that Flutter on web still leaves a lot to be desired, and is not as robust as a JavaScript,
as far as like, we happen to be dealing with a lot of large video files, and that by itself is
just a pain to work with in Flutter. Whereas JavaScript, putting stuff in S3, putting, you
know, there's just, it's doing a lot of things to it, it's transcoding videos, it's, there's a lot
of heavy lifting that has to be done. So that really, we basically realized we can't, we don't
want to get away from that. So then we thought like, we could have it to where, you know, the
JavaScript CMS and the JavaScript front end for that was all one app, and then you had these two
other things for Android and iOS on Flutter, that seemed fine. So you, do I understand, was the idea
to migrate the web away from the Flutter code base? Yeah.
Entirely. Okay. And there's all sorts of like, if you want to go down, like the things we had is,
because we, because we didn't have this, this connection, we were starting to add like a
settings page in the groups of the Flutter app to try to let people manage certain features.
So it just, it kind of went, you know, a little bit,
we were, we were basically building around it instead of just dealing with the real
problem. Okay. More precisely, Jonathan was dealing with it.
I, let me, let me capture one thing. So, so in this, in this world,
the, the web, the web version of Flutter is breaking down in different ways.
One I heard was it had something to do with video? Yeah, it's, yes, you could say that.
It's not bad. It's more just the processing and the management of something like a course or
uploading large, you know, five to 10 gigabyte video files and having it process.
It's not that we couldn't do it, you know, anything's possible. Yes. If you put enough
time and energy into it, it's just, we already have it working and it's working well at scale.
Here's an important detail is like, it's already working. The processing of the large video files
is already working over on the JS CMS app. Okay. So let me capture one other data points. That's
interesting here. And why, like, why even keep this silly thing on the left? We have close to
like half a million active users on the left side and closer to 20,000.
I was in monthly active users on the right.
So these are all the new paying clients on the right, but our legacy
clients have been using it for so long.
It's kind of got, it's, it's got the credibility of that thing at scale.
So this is great.
It's a different experience because the video is important on the flutter side.
It's just not the main thing.
Whereas on the left side, it's it think of it like Netflix.
It's like the video is the thing, like this, what we're trying to deliver.
Uh, content that way.
There's still courses.
There's still video on the right side, but it's much more like a Facebook
group or something where it's more social, uh, driven, um, so there's
shorter clips, shorter updates.
You know, it's not, uh, me sitting on the couch watching TV, which
is what the other ones are.
Okay.
They're kind of a different experience.
So I'm, um, maybe I'm slow.
What I'm, I'm going to play this back.
I'm hearing we have this, we have this legacy app.
It's as this old groups V1 code.
That's deprecated.
We haven't touched it in more than a year.
So it's gross in different ways.
Um, at the same time, you've got like 500 K active users.
At some point you made a decision.
We are, we, we want to be selling this new thing.
So you do the new thing.
You will now have 20 K active users.
Are you still onboarding new people over here or is this only old customers?
It's just, it's two customers doing all of that.
It's yeah.
Okay.
Um, uh, has something changed in your strategy that like, uh, are you still
intending, is this still the thing you want to grow it's but, but, but, but,
but the problem is the, um, flutter on the web isn't, isn't
doing what you needed to do.
Yeah.
I think if I had to draw, like, this was always the, the goal was this like
Facebook groups, clone the vision from 2020 when we started this, this was,
this was the vision, um, we started building over here and it was taking so
long and then we realized if we're going to do this right, like we got to get.
Uh, it has to be on mobile.
So that immediately, you know, we could, then we kind of explored react and we
also had graph native and we explored some things that could be closer to it.
Um, we took a worst detour is we actually went to like flutter flow,
which was a low code builder.
Um, and part of it is like, we had some clients that were like, Hey, can you
build this for us in two months?
And of course we said yes.
And then we just dove into it.
Um, and so, uh, that created a number, a bunch of technical debts.
So we kind of were able to get to sort of the experience here a lot sooner.
Uh, but now we're like, now we're looking back and we're like, okay, this is great.
Think it is almost like we, we did like this very elaborate prototype.
Um, if we're going to keep building this, uh, you know, the tribe social by
itself is like a profitable product.
And so now there's no, um, it's not like we have to go close 10 new clients next
month to, to keep everything moving.
It's just like, okay, let's just get this.
If, if, if this is an investment we've put years into our, uh, of our lives into
it, like let's make it, let's keep building it for the, for the next 10 years.
Like we're not gonna, we're four or five years into it.
We're probably going to be here again in five years.
So thinking a little bit more long-term.
Um, so we'd made some like short-term decisions, which had consequences.
Now we're sort of dealing with that and going back and cleaning it up.
Um, and we really wanted to sell.
And for me, I'll say like the vision was to have more of the Facebook connection,
building community, building, learning and stuff happening.
Um, because the, this thing on the left is very much the old school
version of e-learning, you know, courses and, um, uh, you know, more of a
Flix type, Kajabi, Thinkific, it's kind of the old model, whereas there's
kind of a new thing, think more like school or like these communities that
are coming up where it's more about connection and being on live calls
like this and learning and mentorship and stuff, so that's where we
started to, um, get the vision for that.
So it was able to kind of do this on a relatively low quote, I'll put
in air quotes, low cost, right.
Because we're literally having to do it again.
So it's not, it wasn't low cost going, going the Flutter flow route.
We did make the, at least moved ourselves off of Flutter flow earlier this year.
And we got ourselves just into a nice cleaner Flutter project where you can
have a lot more control over stuff.
And, um, so we can still build on it.
We can still sell in this mode.
It's not, it's not bad.
It's not bad.
It's just like, now we're not the same people we were when, Bruce is not the same person
he was when we started this process.
And now we're thinking a little more deeply about it.
We have these tools like we're talking about here.
So we thought, let's take these new tools and our new approach and kind of deal with
an old problem where we made bad decisions in 2022 and 2023 on architectural.
And there was a lot of discussion of like, which way do we go with this stuff back then?
But we at some point, we just had this, these deadlines we have to hit.
So we just had to make stuff work at the time.
So if we were taking a step back, let's build it right, kind of set it up now, not trying
to just, you know, I would say like, when we had to make these decisions, we were not
profitable at that point.
So this helped us get to profitability.
And now we have a little bit more money.
So.
Totally.
Okay.
I feel like I got the real frame around this now.
You know, the framing isn't around the code split.
No, this is the work of getting clear around like, what are we trying to do and what's
the business value and how do we know when we're done?
Because I just don't know how to interpret these things without a frame, you know?
So, so, so what I'm getting, what I, and I see these things are more about the solution.
I mean, this is all fine.
It's not that this isn't right.
It's just that like, the big picture was still implicit, which is like, yeah, got it.
So, okay.
There is, there is, groups is here.
These are main feature areas in the existing Flutter app.
Is that right?
They're kind of, I would say, yeah, it doesn't feel maybe, I'd say they're most, most of
the features, yeah.
That are in there.
I think if we did another pass, we'd probably come up with another two or three pieces.
But one thing we tried to do was like with this one, the whole direct messaging thing,
we only have one client that uses this.
And so in this new model, we can just leave them on V1, like, or they can just be, they
can just stay there.
They don't need to, we need to switch their domain or anything.
Got it.
Okay.
So we, we kind of carved where we could.
That's the only really big feature.
And this is kind of a hairy thing to deal with.
But the other things are pretty, pretty essential.
Just getting people in.
Yeah.
Okay.
How, so the other thing that I'm not fully clear on, we're getting close, is, okay.
So is there, what is the dependency between these two?
Are these truly standalone?
Because there's something here that's a little weird to me that suggests that these are not
truly standalone.
They're not.
Yeah.
So what's the, what's the relationship, what are the dependencies between them?
There's a database here.
That's like our main SQL database.
And then that's where everything lives.
All users live in here.
Groups live in here.
All stuff lives in here.
To make it, no, wait, it's not going to be that easy.
There's also, cause we, you know, it's good when things come in pairs, it's like, there's
also another database here, which is hosted in like Firebase for a wholly, totally different
set of reasons.
And so our goal ultimately would be to kill this two, the two database thing is an absolute
nightmare.
And we've, it is functional right now.
It's not great, but it's functional.
I think that, so, so there's, yeah, so this is where everything sort of lives on the left
side.
There's still some, so we have, for example, like when people create a piece of paper,
a video, the content gets created on the SQL database and then a copy of it gets made in
the other database.
So there's a whole bunch of like extra effort to keep these things in sync.
Oof.
Um, okay.
And that's it.
Just like that's, that's the easy stuff.
The user management and all kinds of stuff is, is rough.
So it, yeah, you can kind of see, feel the pain of, of it a bit.
That's the, that's, that's the first thing I, that's the first thing that, that, um,
that I could definitely flag now as like a real clear, clearly a real problem
is that there's, there's like between
Ryan agrees.
We should not have done the things we know we should have not.
We are aware.
So this is an issue.
Um, uh, uh, I mean, do you want more examples like that?
Cause there's, I want to know, I want to know where, cause here's the thing is,
um, um, the, the questions you, you, you raise some questions around, like,
should we be doing all of this?
Like all, and then releasing it at once.
And can we just do parts of this and are they separate projects or is it one
project?
And, um, I, I can't react to that until we have more information on the table.
And this is the kind of information that starts to get onto the table where we
can really start to talk about the, so what we're doing here is we're, we're
building up all of the knowledge on the, we're, we're putting all the problem
knowledge onto the table.
Cause you see, we're still drawing the old world here, you know?
Um, um, and then the more that we have a very clear picture of the problem, uh,
then we can have some very simple conversations or, oh, we could do this
or we could do that, or we could split this and not do that.
And you know, that kind of a thing.
So, um, I've got, um, uh, um, um, okay.
So I'm going to ask you a stupid question.
What's bad about having these things in, like, how is this biting you?
What's breaking because of this, um, sync issue.
Our efficiency, like, I don't know our speed to put new features out.
It seems overly complicated to always be considering these.
So this is, is, is this adding a bunch of scope every time you want to make
a change or add a new feature?
Um, another example is like, there's two databases, but they're not, they're
not actually like, um, they don't, they don't, um, match.
So, uh, for example, we needed a feed in the Flutter app on the right side.
So there's a, there's a kind of like a community feed, which has a bunch of
requirements and of how that's built.
Um, because we never needed it on the left, we don't even have any of these
posts that have been created on the right side there in Firebase, those
don't even exist on the left.
So when, when you start to say like, well, we really want, um, you know, new
features, we want to improve the feed experience or whatever.
We don't even have the, that data here on the left side.
Now we could like access it, of course, you know, from one to the other, if we
have to, but, um, there's a few things like that, the feeds, the main one, and
it's, it's kind of, it's a pretty important one.
Uh, okay.
Uh, so what I want to do is I want to start to look at this a
little bit in terms of slices.
There's a community feed, um, front end here and, and behind that
are, are posts in the, in the Firebase DB.
Yeah.
So I'm going to get rid of Firebase DB here.
And, um, in this case, I would think that this is, is this, is this an example
of you're in a happy state because you don't have to think about this other
database?
Uh, yes.
Um, so a use case could be like, in some cases, yes, it's, it's kind of
working, but let's say like people, uh, an admin wants to go moderate or do
something with these posts.
Um, you, and you're in this, like the JavaScript CMS, you don't
even know that these posts exist.
Um, so admins want to go like reply to posts.
So we've had to make like another admin.
We have, we have a tool, a feature called admin replies that we created
on the, on the, uh, where you are right here.
Yeah.
Um, that reads those posts and they can quickly line up,
work their way through that.
So it's, it's kind of working.
It's not, but we're having to tell them like, no, well you do some stuff
happens over here and then other things happen on this other app and they have
to constantly switch between two.
And it's very confusing.
So I, I, I had a wrong impression.
I thought that you had customers who were only using this app.
No, they're always, it's all one thing.
Ah, I just got to clarify like the customer, like the end users are
either using one or the other.
Yes.
But the admins, if they're, if the end users are using flutters, flutter, then
the admins of that, those they're using both, like the admins were CMS and in the
Flutter.
piece. So, okay. Maybe one. No, just one comment. Maybe we can rename like, it's not only like the
JS CMS app. It's actually a JavaScript code base that contains the CMS and also our admin
and also the groups V1. So we have the backend and we have users that will be the admins that
will be assessing the dashboard, which is the CMS. But we also have users that are accessing
this group V1, which are the end users of our customers. So, basically, it's a JavaScript code
base that kind of worked by itself. But now we have also the Flutter code base that our main
goal is to move all, let's say, customers of our customers to this Flutter version and leave
the JavaScript just for the dashboard part and not the admin stuff. So, in the JS CMS app,
you have a frontend that's used by end users. And you also have a frontend which is used by
Flutter app users. Okay. Frontend for admins of the Flutter app. Uh-huh. Uh-huh. Okay. Uh-huh.
The backend. Yeah. So, you have the user's backend. I see. Okay. Uh-huh. And then you
also have, of course, the CMS-related backend, yes, is also kind of in this app. And then over
here, then, you have, for example, the community feed frontend. You have posts in the Firebase
database. And you have an admin kind of moderation feature here. But in order to change who is an
admin, I have to go over here. Yes. That's a good example. Exactly. Yeah. And maybe just rename that
right there. Oh, yeah. Yeah. Uh-huh. Uh-huh. So, our customers I mean, we have customers and our
customers have customers. So, their the end user only sees this, of course, right? Most of the
time. And then there's one of the flags we put in the problems is like, except on something as silly
as a password reset, you know, this actually the users will when they have to reset their password,
they actually come over to here. They have to reset their password. And then they get stuck on
some random screen that basically is like, cool, your password's changed. Please go back to your
app on a different domain and sign in. So, that's where those redirects. I mean, it's not quite as
bad as that. I think it redirects or something. I'm going to call this a facade. I'm going to
say there's a facade for password reset. Yeah. Yeah. And also, another example of a problem.
We have the ability of creating notifications, push notifications when you create a new post as
an admin. But this push notification was only being triggered if you created the post within
the Flutter app. But if you created from the dashboard, this was not implemented. And now,
we implemented on we are implementing it on the dashboard. So, these are small things where
we kind of are losing track of where is the where was the best place to implement this feature. And
because users were kind of accessing both, especially actually only the admin users,
they were they had to access both apps. So, this was creating complications.
And so, okay, hold on. I want to capture that also. There's something called a dashboard on
the JSCMS app. You can just put the feature, there's push notifications. And what he's saying,
there's like, there's like a dashboard, like, we call it the dashboard, the CMS,
kind of interchangeably. But there's push notifications on both. And they're different.
And so, if you create a push notification on the CMS side, the JavaScript side, it can do
A, B and C. But if you do it on the Flutter side, you can do like, D, E, F or something, essentially.
And so, this is extremely confusing for clients. They're like, cool, I want to share something with
my users. Then they go and do it. And then, you know, we're like, no, of course, you can do that.
You have to go over here and do it over here. And then, you know, we tell them something else.
Anyway, it's just and then
from a from the Flutter side, we have to account for like, did
this notification come from the CMS? Or did it come from the
Flutter app? And then it's two totally different, like, you
know, flows.
Mm hmm. Okay, okay. Okay, so let's say, let's say that we
pause here with a bit. Now, this is a nice picture of some of
the problems in the in the current world. What is what did
code split do?
Not as much as you originally thought at the beginning, you
were like, cool, so you sold it.
So like, basically, we now have I think you somewhere you had
group V one, I think in a previous maybe was over on the
left side. Yes. Okay. Group V one. Yeah. I'll capture this so
that this week so that we don't lose. So we can continue to
build up at least a complete picture. So we had a group group
V one. And we were processing video files that I think that's
maybe not as relevant now.
If what you could do, maybe just for your diagram is to actually
have the CM the CMS split a little wider here, and then have
like the dashboard sides, what we call the dashboard, and then
we have like the front end, you know, side on the left column,
because there's kind of two pads there. For example, the and you
could split it however you want. Those yellow boxes would kind of
push one way or the other. So which goes where? So that one
you can leave on the front end. That's fine. This one goes to
the left because that's they're using there's the admins running
there.
This is underlying both
no usable users are, yeah, users, they could be under both. I
mean, it's really the user management happens on the
dashboard side. They're both the front end from a code of a front
end verse like an API, but we sort of split it to these two
different experiences. CMS back ends on the left, the password
reset is on the right here. And the push notifications would be
on the left side. And then what we did, though, was when you're
on the front end here, we can now split basically to like a v
one experience or like a v two. So we can send people down like
two different paths when you're on this, this flow. And so
that's all we did on the split there. And so we can start to
fix
it really was just a setting us up to start the process. Because
what it did was it allowed us to start building a v2 without
messing up all the legacy clients that were on
the, the ones that are just on this guy.
Okay, let me ask you this. So let me just clean up one thing
and then we can we can let's let's double click on it let us
start building a v2. We'll come back to that. I assume this I
mean, these are both front ends. So can you help me understand
like what is what is this and how is it different from this?
Um, they're not, I mean, the codes actually, technically,
Lucian, I think the code, the v1 v2 is actually like kind of
above both of those, right? Did I put that in the wrong?
But is this is what you're describing to me? Is this still?
Does this still describe the structure of things before you
made the v1 v2 split?
Yes, this is before.
Okay. And so this, this is this groups v1. This is
what does it mean that this is here and not here? Like this,
what you're calling dashboard? Is this is this all just admin
stuff?
Yeah, exactly. Yeah. Ah, okay. Oh, we should probably put the
word CMS there and take it out of the top part. I think that's
okay. Okay. So let's just, I'm just putting a soup of
different, a salad of different equivalent words there. And
we're going to say JS app. This is the older app. Uh huh. So
this is, this is the end users. The end users of this thing are
using this stuff. And the, uh, the
The admins are using this stuff, is that right?
That is, yeah, that's.
Uh-huh, good, okay, okay.
And, okay, so then when you said like we split,
okay, so there's a new version of this universe,
which is after the code split,
where we now have end-user front-end v1
and end-user front-end v2, yes?
Mm-hmm.
And are there duplicate versions of each of these things?
So we came up with an idea for this to have a common,
there's three directories, there's a common,
and then there's like common components,
there's v1 components, v2 components.
So we can actually share everything at the beginning,
and then we can sort of, over time,
we can create this new experience.
If we have a modal that has like a form we need,
we just reuse it for now, we don't rebuild it,
just reuse the components in v2.
I see, I see, so you just kind of factored those apart
so that you could compose with them as you do new things.
Mm-hmm.
Okay, so here's a question.
If we're looking at things that need to change
in order for you to be in a world
where doing new development on the,
you wanna continue to do development on this,
so this thing, which is called a Flutter app,
what is it called in terms of the thing that you sell?
This is Tribe Social?
The whole thing is, Tribe Social,
this is really what the clients get
as sort of their branded app,
and so the Tribe Social doesn't actually appear
anywhere on the Flutter apps,
it gets branded as our client's app,
kind of from end to end.
So it's the white-labeled,
and you can call it the white-labeled version
of Tribe Social is what it is.
So, okay, so is the idea that the things that are,
the reason that you wanna have a V2
is because there are things that have dependencies
to the stuff over here that you wanna be able to make new?
Maybe, maybe, I'm not sure I understood.
Okay, I'll give a dumb example.
This is a gross thing that you pointed out.
Is this the kind of thing that shouldn't be happening
anymore when you're done with this project,
or is this the kind of thing
you're gonna continue to live with?
Yeah, we'd like to be done with those sort of two things
that do slightly different things on two different pages,
two different domains, even.
Okay, so this is another one, the push notifications?
Yeah, push notifications definitely.
Password reset flow is not mission-critical,
but it's important.
It's not mission-critical.
It's something we can identify that,
but it's not as critical.
Okay, so when I look here now,
notification center, is this referring
to untangling this notification stuff?
Is that what this is about?
Yeah, so we kind of framed this first piece
of just kind of use the JavaScript front end
to also just be able to read things
out of the Firebase database as well,
so that at least from an end user standpoint,
we kind of fix it on the experience side,
and then we can kind of move.
So one of the things we put out of scope
for this project was changing the APIs around too much,
or basically moving the data itself.
So the reason you can't do the admin replies feature
over here is because the posts don't even exist
in the SQL data, so we gotta go fetch the posts
from this Firebase DB and get those somehow,
and then we could create a front end admin reply thing
over here relatively easily.
I'm sorry, that was if we were to do the admin replies,
but we could just read from that database for now,
and right now we're reading it to the Flutter clients.
We could just read it into the JavaScript one,
and just.
make it feel a little bit more cohesive, and then over time, the goal will be to totally get rid of
Firebase as we go and get rid of those synchronization issues that we're running into.
Again, it kind of works, but we don't want to go and create a post table, for example,
in the SQL database just yet, because I think that makes it harder on ourselves.
First, just initially just reading the front end. That's, again, why the estimates of time
was relatively low, because we're just building the front end. We're not going to go and
move all the sort of CRUD functions out of Firebase and into...
I see. I see. So what I think I'm hearing from that is that I'm just going to capture this on
a high level. So now I'm trying to capture for the first time kind of like your approach
as like approach A, which is, if I'm going to just try and do this at a big picture, it's
back end, DBs and APIs don't change. Is that right?
Yeah. We may be creating an API to read the Firebase potentially, I'm assuming, Luchin,
but it's really the data. We're not going to try to move data, would be maybe a better way to say
it. Yeah. Uh-huh. Yep.
Uh-huh. Uh-huh. Uh-huh. Rewire front end to fetch data from where it already is.
Like new front ends for a key feature. Yeah. I think one way to look at it is that by the
end of V2, like by the end of all these changes related to this V2, we would move our users that
are using the Flutter web out of it to use only on the JavaScript. And this will kind of, at the,
by the end of this process, we'll be reaching, we'll be getting the data from our Firebase,
but all the structure will be in place for us to slowly move out of Firebase by connecting
directly with our APIs and moving the data from Firestore to our SQL database. So it's a
kind of, this V2, it will be an intermediary step where the front end will be fixed for end users,
but the backend will be a little bit confusing, but we have all the tools in hand to fix it on
the next step. At least that's how I'm looking at it. Yeah. A different way to think about it
would be like our client's domain is currently pointed to a Flutter app, but their branded
domain will now point to the JavaScript by the end of this. Guys, that was very helpful.
That was very helpful because I kind of, I think that's the first time I see an outcome where I
feel like, oh, that's when we're done. Because that is actually a moment, you know what I mean?
Where you know if you were there or not. So the thing that's really hard about these refactoring
projects is very often we don't have a clear definition of when are we done.
You know, and that is fantastic. So we're literally going to shut down the Flutter web app
at the end of this. Is that right? Yeah. Yeah, that's the idea. Oh my god, that's fantastic. Okay.
So that's, thank you. That's very helpful. So this is literally like migrate from Flutter
web to JS to new JS frontend. Exactly. That captures what this thing is, yes?
Yep. And that's why this is one effort and not separate projects.
Very good. That makes me feel very satisfied of our job because like literally your aha moment
is like the title of our projects. I feel like we really captured. That's so funny. I literally see
migrate web app from Flutter. The thing is, so what I would have been looking for, so I mean I think
maybe this is just for me. But the way that I usually think about this is I want the frame
to be something where if all of us for some reason just like got pulled away to different
things, you know what I mean? And we all came back to this project like and we forgot everything,
how quickly could we load it back into our heads? And what happened here
is, and I'm not telling you this is a problem,
but this is kind of like a, maybe a,
I'm curious if this gives you any ideas, you know,
is like, it took an hour and 10 minutes
for me to get the aha.
And it could be that I have a,
it could be a failure on my side,
but usually what I'm trying to do in the framing
is create that aha as fast as possible.
So, if I were to try and write this,
what I would be doing would look something like.
That's definitely fair.
Cause I, I mean, we did this probably a month ago,
Lucian, I don't remember when, it's been a while,
but that's exactly what happened is the reloading
and into our brain thing is very helpful.
And I don't think we, we kind of, again,
maybe we took a couple of shortcuts because it was our app
and not for a client where we have to do this packaging
and presentation piece.
So I was actually, we only had the problem statements
and stuff written, put it in FigJam.
And so this morning I was just actually
putting it into Notion.
It was all the things we wrote down,
but I don't think we took that final step where we like,
Hey, really, this is the main event here
is the domain piece.
Cause once the domain shifts, then, then we're done.
Like, cause obviously it has to all work, you know,
before that, for that point, but we're working.
One other piece of this is we're working with another person
who's been helping us with just like communication
to clients and being super crystal clear
and getting things really concrete in emails and calls.
So this is just a kind of an example of that
where we could have been much more clear
and just basically being a better writer
is what it comes down to.
So that's the good feedback.
I think, yeah, I think, I think the, for what it's worth,
this is a little bit of a black art.
So it's, you know, the, the thing,
the thing that I'm focusing on here
and we can do a little bit of a, of a before after.
Let me, let me, let me first express.
So, so the real, the outcomes,
the aha moment outcomes are like,
we're literally going to be able to shut off Flutter app
for all customers.
Like that's a switch we're going to flip.
Domains are going to point to the JS domain instead.
I mean, that's, that's, that's kind of a spelling out
what this means concretely.
It's kind of a repeat of the same thing,
but it's, I like it there.
This is only about the front end.
So what I'm actually going to do is,
this is a case where I could reach for,
sorry, this teal draws a little bit.
Text editors are hard.
Yeah, seriously.
But I'm going to do like this less about,
more about, this can just be helpful
because it lets me really just make this extremely crispy.
And this gives me a place for, for this extra detail.
I'm going to say, this is,
this is not about where data is stored.
This is, this is all about front end wiring.
This is about,
no, whatever.
This is about ability to migrate backend.
It's, it's actually, it's not even about this.
This is literally not about where data is stored DBs.
This is all about the front end.
Then problem.
What I heard was something like,
the fact that we have things in multiple places
is like slowing us down and adding complexity
whenever we want to do new things.
Yep.
If I, if I, if I put the history in here,
the context history a little bit, it's.
It's like Flutter web was a quick way to stand up social,
to stand up FB style features
when we weren't yet profitable.
Now we intend to grow the,
I don't know what to call this thing.
Like you have these two worlds
and I don't know what to call them
from a business standpoint.
We've been talking about them
from an implementation standpoint,
Flutter app versus CMS.
Like this community style thing,
does it have a name like business-wise?
Product-wise?
I mean, this is, we joke about it
because it is the social,
it's the tribe social piece of it.
Whereas we really should name the other one
tribe streaming or something.
That's streaming for social.
Yeah, yeah, okay.
Uh-huh, uh-huh.
Yep.
Okay, so this, if I, yeah, please.
No, I just had a question
because there's things that,
as we said, because you mentioned
like the next five years,
like obviously that's just part of the outcome here
is just really, like you said,
it's really about front-end wiring.
It's the first step.
Yeah, I don't know if it's worth mentioning now
in the things we're not doing
or what this is not about.
It's not right now
about getting the long-term database stuff figured out.
Like ultimately we want to get rid of Firebase altogether
because that's the last piece
that's kind of messing everything up
is we're not getting away from Firebase, I guess.
I mean, you said that with the DB piece,
but it's kind of just an acknowledgement of like,
yeah, we're aware of this piece being,
because if someone could come and look at this
and be like, well, why don't you just pull Firebase out?
We're kind of got to the point of clarity
where like, I think keeping it in for now is okay.
So yeah, I don't know if that helps Chris, at least for me.
So the, I try for framing to be really like more about like,
why are we spending time on this
and why does this matter today?
And why wasn't it a problem a year ago?
And then shaping is more like,
what are we actually doing and what's in and out?
So as soon as we kind of get a little bit
into the weeds here about like, is it Firebase or not?
I kind of feel like I'm getting away from the bigger,
what this thing actually is.
So what could happen is,
so when you say implementing it in two places
across apps is slowing us down,
this isn't because of Firebase.
So we could say something here about what it is
that's actually slowing us down here.
That's not Firebase.
Yeah, I'm not sure.
I think that.
So if it's not Firebase, like what is it?
That's, it's all the tangling of the,
yeah, it's like.
It's the fact that like you literally have to move
through multiple, you really, you have to be thinking
about like multiple like flows through both apps
whenever you're like, it's not only in Firebase,
it's also in the front end.
Yes.
I think, I think if we like, it's, there's so many,
there's lots of problems with it, right?
It's just that these are not problems
we're gonna solve here.
So it's just obviously we're gonna list out the things
we are gonna solve and assume everything else
is off the table.
But it is, this is where I kind of feel like
it's kind of like, this is the first project is this,
the second might be to now start to remove dependency
on Firebase would be the second phase of this,
but it's not a, but we can't fit those two
in a six week cycle.
So this is where to me, it's like,
there's kind of project one, two,
and kind of having stacking a few different pieces of this.
So we, but if the goal is to shut off Flutter
web app customers, we don't need to change Firebase
in order to do that, right?
No, no.
So, but what do we, what needs to actually change?
Like what, so like, if we look at our heat,
so when I go back here,
I'm seeing things that are not Firebase are,
I don't have a, there's unclear.
Like, like, like, like there isn't clear workflows.
Some of the workflows are unclear right now.
There's, there's confusing different policies
about what happens because of duplication.
These are the kinds of things that are like.
Yeah, one, so this is, if we think about it,
maybe a deeper underlying thing is that
everything was highly functional,
like need a button, put a button there.
There was not really any thought as to the user experience.
To make that worse,
we have this whole separate code base thing
to make it like more complicated.
So my first step was like,
let's at least get it to where we can work on it
in the same place.
We're not moving between domains.
Cause that's kind of a big experience problem thing.
You're jumping between these two domains.
That's so jarring.
Then we really need to dig into the under,
like that's again, that's maybe another project,
but it's kind of the root cause of like,
why are we doing this now?
Well, it's the speed of the features for sure.
But I think in order to really level up the user flows,
it's gotta be simple and it's gotta be less surface area
for people to have to like realize,
figure out what goes where.
I don't know if that makes.
Yeah, let me capture that.
That makes more sense.
Again, it's the two houses next to each other
and being like, yeah, the flow of this house isn't great.
And she's like, yeah,
you just have to go to this other living room in house two
and then the kitchen in house one.
So yeah, it doesn't flow well at all.
But it's like, it's okay.
Cause we have 17 hallways we built between the two.
So it's fine.
So let me try this.
It kind of sounds to me,
if this is actually what this is about,
is that you could have a successful project here
where none of the UX flows actually improve,
but you're able to shut off the,
like everything looks and works exactly
as it seemed to before,
but you're able to shut off the Flutter web app
and send people to the JavaScript domain instead.
And then you could do subsequent projects
to actually fix these different things.
Is that right?
It kind of sets the foundation for sure.
Yeah, that's a good way to write it.
So this is also not even yet about fixing the UX problems.
Okay.
That's helpful.
So this to me, for example, sounds like a UX problem.
Yeah.
So we're still, we won't have that as much
because just by simply moving the domain,
it fixes that forgot password
because just from the simple fact
that like once you reset your password,
you're signed back in
and then you can just click into your group
from there very simply.
Versus trying to go to another domain
after that is much more complicated.
I see.
So some of it will, I think it'll fix some,
I think it will fix UX problems just switching the domain
without changing the actual design
or the layouts and things like that.
I see.
Okay.
So, okay.
So when I, okay, so this helped me a lot.
So now if I understand,
this is literally about shutting down the Flutter web app.
We're not actually gonna be rethinking UX flows yet.
I guess, unless there's something
that literally like doesn't translate,
in which case you have to rethink it at that moment.
And this is all about just being able to flip the switch.
Like it's almost like the railway tracks.
Like you wanna like flip that switch of like,
they are now onto this other domain
and then you can still do subsequent projects
to fix the UX problems and stuff like that.
So the-
Yeah.
And I wouldn't, the domain is a good analogy.
I think one thing we also talked about,
I don't think I wrote this anywhere,
but we also said like,
we don't have to move anyone to any domains after this.
Like we don't have to switch this,
flip the switch on anyone after this.
There's no pressure.
So we could prep it, get it close,
maybe move one or two clients over and then leave it
because some of them may feel immediate.
It may be actually a step backwards
as far as a missing feature or flow, for example.
So we thought we could do it in pieces until like,
it's maybe the UX is improved.
and it is, you know, much better than, I don't know.
Now that's, those are two very different universes, if I understood right.
So in this universe, where we are literally throwing the switch,
this forces us to ask the question of what is acceptable and what is not acceptable for a switch
to happen. If you're saying, well, we don't have to throw the switch, and then later we'll throw
the switch when we're ready, what I hear there is like definition of ready TBD.
Yeah, that is true.
That's fine. I mean, because you can, I mean, there's a million ways to work. So there's
nothing inherently wrong with that. But all of my tricks don't work if I'm in that world.
Because then I don't know how to wrestle piece by piece with like,
does this need to happen now or not? You know, and like, when can we move on?
And that is the biggest risk with a rewrite.
The biggest risk with a rewrite is that we don't have a definition of done.
Right. That's where we've been stuck for sure.
Yeah, so I think we're at a point where we could flip to the shaping side of this.
And the way that I would, though, I'll preview that, I think we also were an hour and a half
in so we could take a short rest. What I want to think about is, in the whole space of the
current app and the current function and every possible feature, what are the things that we
could simply port over without a single change in behavior, according to this more strict frame,
you know? And what I'm curious about is, is there a contradiction in the frame?
If we don't fix any UX problems, and we literally port everything over one to one,
do you know what I mean? Like, kind of what's still, what's not, what's holding us back saying
we can't actually flip that switch, right? And then I think what that will, I think that test
will help us to identify, you know what I mean? And this can be, we can look at this as
scopes of a single project, or we can look at this as a monster, which is multiple projects before you
have a final launch. But in the end, it's kind of the same. It's just a question of whether or not
you're inside of a manageable time box or not. If all of this still with AI adds up to less than
your typical appetite of, you know what I mean, three weeks or four weeks or whatever that is,
we can treat it as scopes inside of one project. And if it starts to feel like that switch flipping
is further out than what you can commit to right now as a single project,
you know, then we can look into, okay, well, then what we have to do is frame the intermediate win.
And how do we know when we're done with that? And do we feel like we're ever going to reach
that other piece or not? That's going to be a big thing. Any reaction to that before we break for
for 10 minutes to breathe here?
Yeah, I think these are all good. I think it's like breaking into little steps to get us
on the right trajectory. I think there's sort of this bigger arching thing, which I said,
we're kind of dealing with now with the UX problem is like, yeah, there's these underlying
UX problems. Because the one thing I did in between us shaping this and I was like, because we basically
didn't do any work on this for a few weeks, we got busy with other work. And so we didn't,
we just deliberately deprioritized it. Is that I just did like a little spike project where I said,
hey, let's just sit and like, and this was a legitimate vibe coding thing, like make a branch,
have like, just mock up the what the post would look like mock up with the media, like don't do
anything with API, just pure front end. Let me just see if I can get the experience, like a
new these prototypes and by coding, we deliberately like delete them when we're done. So it's a very
freeing experience to go in and cool, use these tools, look at it, this is great, like maybe take
a screenshot and then delete the whole thing and kind of Yeah, cool as a reference. But it lets us
go down. And basically, we ended up with something that looks relatively the same as what we have
now. And then of course, this is I'll throw this last wrench in the whole thing. And Lucia knows
what it was like, well, why don't we just make Flutter the main app? Like, why don't why don't
we just improve the UX of Flutter? You know, instead of doing this whole other project,
like we could actually just leave it in Flutter. And so like, which is it's, you know, and there's
reasons for that as well. But I just wanted to show this is sort of the back and forth. We've
playing with for a while.
That's why we haven't made a clear decision.
So yeah, Lucian, you were saying?
Yeah.
So one of the problems, OK, we don't
want to work in two places.
And another problem is that there's
a lot of little UX issues that are really like, eh.
And so this framing is really good
because it's like, OK, approach A would just port everything
over exactly as is.
And as we're approaching this, it's really cringy.
Do we really want to just copy this really bad thing
into V2, JSV2?
And it seems like we use this thing as a doorway.
OK, if we were to approach porting everything over,
we're considering porting notifications.
But really, it's bad.
So let's make a project to actually fix notifications.
And then we port it over.
And then we just kind of find what
are all the different projects to fix the UX issues.
And once we fix the big pieces, then we can, in good conscience,
port it over.
Got it.
That's a good thing.
Let's come back.
That's a good thing for us to come back
to when we come back from break.
Foreshadowing.
OK, we'll come back to that.
Shall we take 10 and then come back?
Cool.
All right, we'll see you in 10 minutes.
you
hey okay so we're back
um that was a good place to to to land with this observation from from lucian about um there are
things there's things we can port over and there's things that if we port them over we're gonna feel
bad about those things we're gonna feel like i don't want to port that over that is i think
fundamental so if i share my screen and i go to where we landed on the frame we put
we put this for so for example with the notifications if we just poured it over
can't is that real or can we actually live with that what what that tells me is that there's a
there's a contradiction here this is not true this is not true that we are willing to
live with all these ui ux issues and we're just going to give ourselves a foundation to fix those
later um there might be there's a step along the way there right but the problem is that if we only
have a step on the way which is like we you know we're in a better place then we don't have a
and then i and then i think i think i have a direction for us here is it is it indeed true
that um there is a sense of time pressure like we want to be able to actually shut
we want we want to get we want to reach an end of this rewrite and like be in the new world
uh by a certain date
i don't know if the domain is as mission critical but i feel like it feels like this is like
This is like a necessary step to do this piece before we can kind of fix bigger problems or fix more pressing problems.
So in that sense, this is an urgent problem because it's holding us back from other issues.
What is a more pressing problem that this is holding you back from?
Well, I just like, yeah, more of like Luchin was saying, if we have this setup, we can then improve pieces at a time to not have to do all at once.
Or like having this as a gate was a good idea.
I mean, I think if we were going to go deeper on using like, we're kind of hitting like a point where we're trying to make the user experience faster and stuff in the app.
But it feels like we're running into issues where it just doesn't feel as fast as like the CMS, for example.
It's like a really big generalization.
But there's nothing like, I mean, there's lots of little things I think we could work on.
Like the go live experience of hosting a meeting is very slow in the current process.
Could we fix that in Flutter?
Yeah, for sure.
We could totally fix that in Flutter.
And that could be like a one week project.
But if we could fix it here, I think it would be a better experience overall to have it in the right framework.
You know, as we just started adding some AI moderation pieces to it.
So like the JavaScript piece has open AI integration.
The Flutter doesn't.
So like, can we add open AI to Flutter?
Of course we can.
But it kind of makes sense to do it just in one place and have it be simple, you know.
I don't know.
Is there anything else top of mind?
And also, you know, we're kind of building this stuff.
But also Macy's kind of on the front lines of supporting the users and getting asked the hundreds of questions.
And like, why can't this button do that?
And which dashboard should I look at?
And that type of thing.
If you have any thoughts as well.
I don't know.
So what I'm trying to suss out here is, and I think this is what you're, it's coming up that it's not as cut and dry as it might have sounded at first.
Are we really, really committed to getting off of Flutter for the web?
Is that really, like, is it like we all want to get off of Flutter web and like that's when we have succeeded?
Is it true?
Or is it that, look, there's a handful of different problems.
And maybe as we solve all of those things, it might make sense to migrate away from Flutter web.
Yes, I think.
I'm not sure.
Got it.
Okay.
So, I'm going to propose a completely different approach here.
Because I'm just, I'm not so, I keep trying to boil this down.
Ryan's going to be like, have you guys heard of Ruby on Rails?
We create a third app.
Wait, no, stick with me, a third app.
Hang with me for a second here.
No, I keep trying to boil this down to, like, the one thing that this is all about.
And I'm just not hearing that the alignment is there.
I'm hearing, like, yeah, but also what about this?
And yeah, but what about that?
So, my inclination then is, like, I just don't feel like we're getting there.
With, like, there's a unitary frame and we're going to do whatever it takes to get to the end of that.
Because, like, getting off of Flutter is the clear goal that we all want.
So, my inclination is to flip this around and say there's a basket of related projects here.
There are some different things that are causing experience issues.
And there are different ways to solve all of these things.
And some of them might entail a debate around whether we should be on Flutter or not.
Some of them might not.
And there's going to be a totally different space of tradeoffs for all of these things.
So, there is a project that has to do with notifications.
With push notifications across the two apps.
Is that right?
There's a family of issues here.
When Luchin brought up, do we...
Do we want to port this and, for example, with notifications,
like, we could port it, and then once we fix it,
then, you know, we, like, the thing is,
there's, here's a way to think about this.
There are two completely different universes of work
in a refactoring like this.
There's either a 100% port, no thinking,
literally no thinking, or there's rethinking.
And there's gonna be things that you might be able
to put in either category.
These are the things that you're gonna be able
to give the AI, and you can lump together,
and you can just do, you know?
These are the things where, if they're all different,
every one of these things, we're gonna wanna have
a little bit of framing around in order to understand,
well, how do we know when it's better?
How do we know when we're done?
Like, what is this thing?
What is it not?
So when I hear notifications,
it's not enough just to port it over.
It needs to be rethought, you know?
That's the place where my head goes into.
There's some project, there's some,
so these are candidate projects.
There's some project to formulate
where we actually would need to shape
what is wrong with notifications?
What specifically is bad about the experience?
How would we know if it was better?
I think maybe what's also missing,
and we're slowly getting caught,
is between Junauda, Lucian, and I,
we sort of have these framed loosely in our minds.
And so there's just this common thing of,
okay, this two-domain thing's killing us,
and this Flutter JavaScript thing's killing us
on all fronts.
So I feel like if we cleared it,
and we got that behind us,
then it would sort of free us up
to take on the first project.
Because I think the common thread,
the thing we just framed above,
I think will be pretty universal to the issue, to this.
And potentially, it's also the Flutter Firebase,
the Flutter single-domain thing,
and potentially a single database
would be the only other massive thing
that I think would click it into place.
And then, because that's like a secondary thing,
I don't want to go too deep on that.
Because we've kind of stopped thinking
about how to solve these other things,
because it feels like there's this fundamental root cause,
that if we solved this,
it kind of opens us up to a different way
of solving these other problems.
Or I think you probably were going to break it down
to basically get to that same logic, but try it out.
Well, here's where I'm struggling,
is when I say, is this really about,
you want to be able to shut off,
you really want to just get off of Flutter,
I didn't hear, like, yeah.
I mean, I would be good to get off of Flutter.
Okay, okay.
But I would, I'm one,
between Junauda and Looch and I,
we're the three people working on this at the moment,
so I have different motives of why that might be.
You know?
So do we have any,
because here's the thing,
if this is contentious,
if getting off of Flutter web is indeed contentious,
you know, then there's ways that we can work through this.
Like, we can look at these things one by one.
Okay, what would a better push notification experience
look like?
We can shape the version of that
where Flutter is the way to do it
versus going to JS is the way to do it.
What would a better workflow
when you have to do something in the admin
and you have to jump between these two places
for administrating something?
Like, we can go through all those things case by case
and come to alignment there,
but I don't know if that's necessary.
So is there anybody who's actually,
is anybody want to play, like, the...
Is there a pro-Flutter argument here?
Or can we, because if there is,
then let's hear it and see,
maybe there is a place where we can go into
to come to some conclusion about that.
There's something we could wrestle with,
but I didn't hear it yet.
So does anybody want to raise, like,
a hesitation about getting rid of Flutter
or a pro-Flutter argument?
I have one comment.
It's not exactly like pro-Flutter
because I think in general,
the experience of Flutter web is not great
because of a few different technical things.
It's possible to get it better,
but it's not great.
It's my only concern, I think, like looking at our, at our, uh, current
architecture, I started specifically during this meeting, I started to kind
of question, question myself if, uh, the easier approach wasn't, is not like to,
instead of, uh, moving the front end to the JavaScript part as our first step,
we kind of work on the, uh, one backend thing first, like first we fix the,
the not needing like Firestar and needing a SQL and like just having all
our front ends consuming from the same basis.
And then we, uh, can change the, the Flutter web, uh, to a JavaScript.
And I think that would be even easier because, uh, from the, from the current
standpoint, uh, we will not be like reducing the number of things that we
have to do maintenance for, uh, we will actually on the first moment we'll be
like increasing it, then we'll be able to decrease it.
But, uh, at the first moment we'll have more things to give maintenance for,
because we'll have the V1, V2 and the Flutter app for the Android and, uh,
iOS, so the code base will be larger.
Uh, and I don't know that what makes me feel like, Hey, is like moving out of
Flutter web, the first thing we need to do, I know that we need to do it, it
will be better, but, uh, it just like this discussion raised a question in me
of whether or not we should approach this as a first step, or if we should
look first thing, removing the Firestar dependency and removing the Firebase
dependency, and these will like reduce our surface of problems.
Let's say our area of possible problems by like removing one piece of our
infrastructure that currently is not needed anymore, let's say, because it
was needed in the past because it made it easier for us to work with Flutter
flow and this backend, which is Firestar, but now it's not needed because
we have the Flutter app and we can just work with our API and our own backend.
So, uh, I think that's the main thing why I was kind of not saying, Hey, let's
go with this Flutter migrate, let's go with this change now, because I was
thinking about like, maybe it's not the first thing that we should look at.
Yep.
So your, your proposal, I think, and you drew this a second ago, uh, somewhere,
right, I can remember where, before we got, but basically just pulling the
dependency of, um, Firestore out first, I think was, was what you're saying.
And you're not like basically move to move to, um, and the, and that like end
big goal that we would look for is that an outcome would be like, we're now
like pointing to a JavaScript node JS API instead of Firestore queries.
Like that would be a big, you know, aha moment of like moving that, um, so yeah.
And I do see the value of that.
I see the, I see the value, like it's kind of, you know, it's which one we do
first, you know, if this is, takes a couple of weeks and the other one takes
a couple of weeks, we kind of want to do both.
I think, I think everybody agrees.
We need to do both.
Uh, okay.
So you actually do agree on doing both.
Cause here, here's what I was hearing.
I thought, I thought it's kind of like, we, we need to move.
We need to make progress on this in a shorter period of time.
We don't know.
Like when we'll get to the further stages of this, but Bruce, am I hearing
that, like, these are, these things all need to happen and it's just a
question of like how we get through it.
I think, I think, yeah.
And we have talked, so we're, you know, there's a number of conversations
the three of us have had to, to this.
Like, I think we know back of our mind, like Firebase is, is that there's a, um,
time limit on it of how long we'll be using it.
Uh, and, and then, so we've, we've been working our way out of it.
Like we took, we made one horrible technical decision in 2022 and we're
paying for it three years later.
Like finally got rid of Flutter flow.
Now I got to get rid of Firebase.
Now we're getting rid of Flutter.
Like it's, it's a, it's three major projects to get work, work our way back.
But we, we learned a lot and we're able to sell stuff along the way.
So it, it, it kind of worked.
But, um, the that's, those have been our, our, like, at least we sort of pulled
the Flutter flow piece of this.
Cause that was adding even more complexity to it.
And that was something we did earlier this year.
So to me, like.
Cleaning up this tech debt piece could kind of set us up for things in the future.
But it is, it's, it's getting rid of the, the fire, Firebase stuff, Firestore stuff at the end of the day.
And then finally moving off of, and you know, if we want to be specific, I think it is, let's use the words like we kind of throw Firebase and Firestore around, but really it's all of Firebase, I think needs to be out because we also using Firebase for hosting, for example, which if we moved to the JavaScript app, it would just be all hosted in one domain.
So, and it's, there's no other problems for the clients for anything on those pieces. It's just, it's not like it costs us a lot of money to be on Firebase or anything. It's all those stuff. It's all relatively cheap.
But I think it is, you know, which I can kind of see Gennady's point, like, I think it could be more immediate value for us to move off of the database, the Firebase database stuff.
There could be value in that.
But I think, yeah.
So can I, can I, can I do a quick, a quick update?
Can we, can we simplify and say that no matter what, this is all more a question about how and what order and how to tackle this, but like at the end of the day, everybody actually wants to get off of Firebase and everybody wants to get off of Flutter web. Is that right?
Yeah, I think so.
Okay.
That makes things easier. Then we can just flip over to the solution side here.
We can flip over to the supply side.
And so the, the thing, the thing that, that, so let's say that you've got, and you've, you've got a, you've got a sense that like it should be possible to do all of this inside of, do you have kind of a maximum appetite for this, Bruce?
Like if we, if we lump this all together and we say, look, we don't know what order we're doing it in yet. We don't know exactly what it all entails, but there's some version of this where we are going to port everything we need to port.
And there's going to be a couple things that need some rethinking, like notifications.
Is there a, do you have a, do you have a kind of a goal in mind in terms of time of like when you're through all of this?
I mean, other than, you know, 2025 would be great, but as far as date goes, but appetite, you know, it probably realistically we can, we can probably put, you know, 10 weeks all in towards it.
How are we going to break that up into projects?
So if that would feel, yeah, that would feel good to you.
That's fantastic.
Okay.
This is great.
Okay.
Very good.
So here's what we don't want to do.
We don't want to take on, here's a failure mode that I think we want to try to avoid.
We don't want to start working on something like migrate off Flutter web, which is a horizontal definition of the work, you know, and, and then we are, we're moving a bunch of things that we know how to port over.
And then you hit notifications and you're like, oh, what do we, how do we do this?
And now you're actually in a different project that has all of its own problems.
You know, and then same thing with Firebase.
We don't want to be migrating away from Firebase.
And then all of a sudden they're like, oh, there's this weird thing where now we have to rethink the way that we do this, like where we store this information and then it affects this other flow.
And like, what are we doing here?
You know, so the, my first thought about how to get some clarity on this is to actually map out the existing functionality.
So basically what I would want to be seeing here, we're fully now switching to the supply side, to the, to the solution side is the current new app universe.
I want to literally see a breadboard of everything that's in the Flutter web that's powered by Firebase.
So like, and in terms of workflows.
So what we were, we were trying to see if this could start to become clear by kind of talking through this architecturally, you know, where we just like, we're piling everything that's inside of the app to try and see like if there were some major seams or something like that.
And I feel like we didn't get anywhere there.
And what I think, knowing that we want to get to the end of this, but we don't understand which roadblocks are in the way and what to slice apart, what I would be looking for here is picture something like this.
Like.
Actually I'm just going to grab a fat breadboard from something else so that I can just copy and
paste and give you a preview of what this would look like. So if we had a breadboard
that spelled out more or less all the major flows, not every tiny, tiny, minute detail,
like all the major flows, then what we could do is we could take our pen and we could say,
let me get rid of this, this, and this. So let's say these are all the different feature areas
in the Flutter app and that are also implemented with Firebase, some of them,
and we could be saying, oh this thing here, we don't have to rethink, we can just port.
This thing here, we totally have to rethink, you know what I mean? This thing here doesn't even
use Firebase, this is just Flutter and it's going to be exactly the way it currently behaves.
This thing we have to totally rethink, you know what I mean? And then so what we can get out of
that is different scopes of work, some of which are going to feel more like projects,
and some of which are going to feel more like stuff we just have to get through. Yeah Lucien?
Yeah, so definitely I get the, like one thing is like the monster of Firebase is definitely
community feed for sure. Everything else we have, like for example, like we got a bunch of stuff
that like was built just in Flutter, just with like Firebase and has no equivalent in MySQL,
for example, reactions to posts. So for those, we can just like create a new table, create new
columns, and it's just additive, but like community feed is the only thing.
The feed is the core of it, because reactions are-
Yeah, and it's like a core piece for sure. It is the only thing that there is like community posts
in MySQL, and there's different, completely different like community posts in Firebase,
so we gotta like think how like bring them together, and if we fix that, I think we'll be
just fine to like remove. There'll be like a bunch of work, like creating new API routes, and like
yeah, it's nothing like unknown as far as I can tell.
Okay, so we have community feed as one example.
We have reactions to posts. I heard the push notification flows.
Yeah, and then the comments as well, and now this, it's funny because we kind of did a version of
this exercise of like let's pull everything apart, and we said, okay, really the chat needs to be
common between the two platforms, so we have a tool now that like, well, basically we moved
everything to where there was chat that didn't exist in SQL and didn't exist in Firebase, and
they are more, they match essentially, so it's the same. So there's a bunch of things downstream
from community feed. For example, like reaction posts, they exist only on Firebase, but there are
reactions to community feed that's in Firebase only, and same thing for comments, like some
comments are unlike, there's like a different tab in the group. There's like replay tab,
so that's like content that exists in MySQL, and it's like synced. Because you're right,
the post comments don't exist, correct? That's right, we did escape that.
So I think if we fix like community feed, like we figure out how to like
put it together, and all the things that are downstream, like reaction, then okay, we can
create now in JavaScript in the API, and like comments, we can finish migrating the rest of the
commons. So what I would be looking at here is in terms of planning the monster.
So I think what's happened is we've shifted from this is one project that we understand that
has like a single, you know, if there was a version of this where it's like we're not going
rethink anything, and we're just going to do this migration and power through, then maybe it could
be a single project, but what I'm hearing is actually this is a monster. The overall budget
for the monster is 10 weeks, and what I mean by monster is that it's many different projects that
all have to require thinking through of like what is actually better and worse for this,
and what's the new version versus the old version, and stuff like that. So the way that I'd be
looking at this is it's almost like when we're shaping a project, but instead we're actually
shaping a bundle of projects, and what we're trying to ask ourselves is do we get to a place
where we believe that each of these projects still falls within?
in 10 weeks, you know what I mean?
And then we can kind of sequence
each of those projects one by one.
And the difference here is that
what we would like to be able to do,
and I think Lucian, this is, if I understood right,
this is what you're describing.
Every one of these, whatever these different things are,
I mean, we could, it's, I think this is a different,
session than, I think this is a session for you guys,
because we, I mean, we have 45 minutes left
so we can do what we can do.
I would be looking at, I would really be looking
at having a clear flow of, a breadboard of the whole app
so that I could understand where to slice, you know?
And that way, because this picture of where to slice
when I do a slice like this, these are vertical slices.
And it's the verticality that lets us actually get
to a place where we're feeling done with something, you know?
And what we don't want to do is like, as I said,
like have like this, like migrate away from Firebase
and it's a never ending string of things
versus if community feed is one thing
and then you can vertically slice and say,
that is now, we are now in the new world for community feed.
And then we do the same thing with reactions,
with comments, comments, with push notifications, you know?
Then you're gonna get to a place
where there's still gonna be stuff maybe left in Firebase
because there's different areas of the app
that are still relying on it.
But the surface area of Firebase is shrinking
as you do each vertical slice.
Does that make sense?
And I think, can we, as we go through that,
these are shippable like pieces.
So like if we just did the community feed,
we could potentially move that API over.
And then reactions so that we delete
the Firebase dependency for community feed, right?
Would be like a.
Yes.
I mean, the thing is, if you do this,
if you do these things vertically
and you can ship them independently,
you won't get into trouble.
That's the, you know what I mean?
Like you won't get lost with it.
I think we've clearly proven we can get into trouble
for the last two hours.
But now we're doing it a better way,
thanks to all the things.
So what I, when we come into here,
what I feel like, so what I expect
after a breadboarding exercise is that
I expect a whole bunch of detail.
You know what I mean?
To fill in here.
We're like, and then this, you know what I mean?
And this goes here and then I connect to this.
And you know what I mean?
Like where there's all of these details everywhere
and this feeling like I'm at 10,000 feet.
And the thing that made me a little nervous
when we started was when I look at one of these things,
I just kind of feel like if there's decisions to make here,
if there's rethinking here, you know,
I kind of feel like I'm already down in a corner
and like I don't have enough room to really like
kind of problem solve and understand like what is this
and really where does it start and where does it end?
You know what I mean?
Versus if community, if you get to a place
where we have a set of vertical slices
and maybe also some of these are gonna be even internal too.
It might be that one of these has two slices inside of it.
You know what I mean?
There could be different stages of these things.
I wanna get to a place where like every one of these things,
if this thing is one week and there's a one week piece
of this and there's a three week piece of this
or a two week piece of this,
every one of these things actually has its own set of scopes.
Do you know what I mean?
Like every one of these things has like a little bit of like
as you said, you actually did kind of this framing around it
and you did this work to understand it.
So what we're trying to do is kind of look at
how does that all link together?
Does that make sense?
Yes.
And also one interesting thing of like looking
at more vertical form is that we'll be releasing
more value as we go.
Because when we fix like the community part,
it will be fixed in across all the front end.
So the overall user experience will be.
better in a lot of different fronts, let's say.
Yes, I think that also reminds me like what I tried to do and what didn't work when I've
tried to come to some overall frame, this decision about like we're not fixing the UX problem or we
are fixing the UX problem, it's going to be different for every one of these slices.
Mm-hmm.
You know, so like each slice is going to have this,
like these different answers to do we change UX, right? Do we change the back end?
Like, what do we rethink or not? Like this is going to be different for each slice.
And then the thing, one of the things that you're going to be doing is just like this should be
familiar to you like from the scoping exercise is there's going to be some of these things,
like for example, the push notification flow where you're going to flag that early on,
you know what I mean? As this is something that's going to require thinking, you know,
so we're going to want to kind of do more work to sort of shape it as a separate project versus
you might have some of these things that feel a little bit like it's just a task, task, task,
and you already know what it is. It's basically already downhill.
I think Bruce says he's listening.
Oh no, I'm here. Sorry, I've just been off camera for a minute.
Oh good, okay. Yep. Does that, Bruce, does that resonate? Like that's a big difference,
right? Between making a policy for the entire effort versus like, okay, we're going to make
a slice-by-slice decision. I think that's fair, yeah. Those should, if we can hit the UX thing
or back and change and we're clear about what we're doing or not, I think that'll help
create clarity. I do think that more than half of everything we're talking about is what Lucian
brought up here with the community feed. Like that's not like 20% of it, like that is the
community feed. It just happens to have reactions, it happens to have comments, it happens to have
chat, like it has all these pieces connected to the feed. We kind of solve for that. We're more
than halfway there if we can solve this piece. So if we were to go back and breadboard this or put
the rest of the architecture together, this is going to be more than half of it will just be
in this community feed bucket. It's just that there's lots of little things that you've drawn
here that we would have to make sure we account for. And it's because community feed isn't
moved over, the push notifications can't happen, the chat can't moderate comments. So it's like
it's kind of the boulder in there. And I don't think the user experience has to change at all.
It's one of the easy ones actually. If we could keep the same, I think that one is,
we could get a huge value there. Incidentally, I created a task and this was the pre-Ryan era
of shaping. I came back and reused it, but in the chat I put the task we created for
the community feed for shaping that up. It's really on the purely back-end,
taking technical decisions about that. Sorry, how do I get chat? Okay, I'll click on that.
Maybe not purely back-end because it touches the dashboard as well, Bruce. I happen to not
have access to that. Just a second. Everyone with link can view. Try now.
There you go. Replace broadcasts with tribe content. Yeah, to add to it, it is a community
feed, but a developer three years ago named it broadcasts and it doesn't matter why. Let's not
confuse Ryan even more. It's called broadcast, yeah. Yeah, technically it's called broadcast,
but it is the feed. It should be called posts. Yeah, I feel unconfused finally.
I'm proud to say, uh, I, so, so the, the, I think, you know, maybe this,
in the end, I'm kind of curious, Lucian, maybe in the end, what happened is we
just kind of put what was already in your heads into maybe just a, a slightly
different form here, you know, where there is this overall, there's, there's
this overall, um, um, migration from Flutter and Firebase, there's this over,
this is the monster, right, is, is, is this whole thing.
And then there are projects inside of this, and one of them is community
feed and community feed is, has some framing around it now that we've like,
I mean, I think you already knew that, but which is like, no, you exchange
needed, you know what I mean?
Just implementation.
Right.
Um, and then there are then these other things that I'm not sure what they are,
but like, like, like we said, like notifications, you know what I mean?
Like, um, things that are downstream from community feed that you can't, that
you're carving out from the first, from this project, whatever this is.
Right.
Um, and then there's, uh, each one of these things.
So, so, so I, I, yeah, I think now I'm just repeating myself, but if, if, if
this whole thing is a 10 week box, right.
So then what we get to is, is we are in a little bit of a new territory of what
does it look like to, to not just be doing appetite for a single project, but
to kind of have this macro appetite, you know, um, and then, uh, what we want
to have is for sure that there's enough wiggle room that we are, we want to be
hitting the big things and acknowledging the things that require
rethinking like notifications.
Is there anything else other than notifications that's going to require
like different, like changes in workflow changes in UX, not just
literally porting it over.
Would the domain change over?
Like, cause we're the actual hosting is we're talking about switching the domain
over and that's one step of getting away from Flutter, but it could like, obviously
that'd be the final step.
And there's probably a lot of little cleanup things between those two.
Yeah.
There's a one thing that like, I'm not sure how it ports over, which is like
admin management, because in the JS side, we have like the, the dashboard and in
Flutter, we have like another, like, it's like group settings type thing or like.
No, I think those are pretty much this, those would be fine to just move over.
Cause it's okay.
Then it's yeah.
The admin, if like, if we dealt with the community feed, we could, those are, I
think we're like placeholders.
I know what you're thinking of.
There was like a whole bunch of settings on that screen.
Like I think badges is in there, but that, I don't know if anyone's actually
using that so we can, we can just, some of that stuff can just be deleted.
Some of it was very prototype, like.
Should we just dive into the monster of community feed?
Cause to me, it seems like pretty clear, like community feed and then rest of
Firebase into API and then Flutter web to JS web, like the other things that
order makes sense in that orders.
Yeah.
Um, uh, how does that play out in just, in terms of vertical slices?
So community feed is, is, is, is, is, is, is, is, is, is, is, is, is, is, is, is,
is a vertical slice, but then the other things I didn't understand kind
of where the boundaries of the slices are.
We've got Firebase into like API.
Like everything that like the, like the later app is read, reading from
Firebase instead, like make API routes for that.
Um, uh, yeah.
Okay.
When I, when I look at community feed, I know how to draw the lines in terms
of the UX all the way down to the backend.
Same thing with notifications, roughly, even though we didn't really unpack that
yet, this to me sounds like it's not a vertical slice, it sounds to me
like a purely backend thing.
So are, what are there things which are, um, which are, uh, user facing or
do you know what I mean?
Like where there is something that you can interact with that's
covered, that's included in this.
What are these things?
Like event handlers, you know, like you click on reactions, it's writing to
Firebase and just replace that with like writing to API, but I think no, like
behavior change, it'll just find all references to Firebase, like create
models, whatever, what Ryan's saying.
And what I understood was like community feed, we would be.
taking all
We would be dealing with the firebase issue when we deal with community feed like anything that's touching that chat comments reactions
Like get off of firebase and for community feed then kind of move to the next one like notifications
Can we get off of firebase for notifications and fix the UX and do it? Is that right? That's what I'm thinking
Yes, yeah, and and Lucian were you thinking of things just now that are not that are not community feed and they're also not notifications
To me all the other things are really straightforward because they're additive they're just like it doesn't exist in my sequel
So there's no decision. It's just you can just like no thinking just like porting from like firebase to API
so this is the fire put them all in the in the same bucket like and it just the size of the bucket can be
Like I'm not entirely sure but to me they're all in the same category
So here's the thing. I think that there's a danger there
Which is that we don't know what other dependencies those things have I
Just don't know what's in the box
For example it notifications is notification something where you think you could just swap out the fire stop using firebase and
And swap it to a different end point like I
So what I want to do is say I'm actually just gonna insist on it what are these other things
You know, this is is this this is a this other any off the top of your head that you could point to from
Of from a vertical standpoint and knowing that it's not a comprehensive yet
Like let's say you might have to grep the code base or ask cloud code to like find me everything that touches the firebase API
Do you know what I mean? But like if we were to list those
What are some examples?
Reactions we mentioned already
Comments that touch community feed
I think that we have other comments were already migrated
What else we have I can pull up the I mean
Because Ryan I think one of the things is like community feed we could move that to the off of firebase
we can move it off the web into them into the
JavaScript web so we can do everything for community feed which will touch a lot of things
but there is probably a project here to
pull
The things that aren't related to community feed
Yeah
Those have to also be built because we can't switch the domain over let's say until everything is done
What is that? What is everything is kind of what you're wanting to exactly and I just I want to define that vertically instead of horizontally
so
So courses
It's easy, but it needs to be written down
So we have courses that exist in the UI on the Flutter side would need to be recreated
and right now the course is all read right out of
Firebase as well. So there's quite a bit to do there even though yes courses do exist in SQL
There's just not like marking as something is completed. There's just there's certain things. We just we aren't connected yet
To that whole user but again no decisions on UX no, you know, all that can be just as is just move it over
Direct messaging is a big old hairy thing
We don't want to probably touch if we can avoid it and I'm oh, it's so big not big
But it's one of those things we could slice out of the ten weeks
Now this is a good example of what vertical slicing exposes. So we just found something that might
Technically qualify as this but what we're excluding
Mm-hmm
Because there's only one customer that uses it and they're fine with it kind of as is
It's just like it we could do it after this
It's just a good place to like it's a good place to draw a line for a project to not
Introduce that I'm clicking through each screen while we're talking. I don't want to miss anything
mm-hmm, but
honest, yeah the
I'm clicking through all your settings screens illusion. And none of these are being used anymore
So there's some cleanup stuff here that it's good to know that there's nothing there
I
Mean, there's lots of little things. I don't know how small but like when someone joins a group
Currently, we're on the JavaScript side. Let's say they like enroll in a group or they join a group
that flow from like
Paying for a group and then getting into the group right now
It's like they're jumping from the JavaScript back to the flutter
Or they're in flutter and they want to join a group they jump back to JavaScript pay for it and come back
So there's that flow will change if we're all in one and we see two just little things like that
the password reset flow will actually stay the same doesn't need to be moved or anything, but
Yeah
That's one of the things that will just be fixed
once we fix the domain.
So that's kind of included in the scope of this?
Yeah, it's kind of like automatically will get fixed.
And I'm looking here on-
The week and the to-do list associated with the week.
Oh my gosh, that's a good example.
So here's the thing.
So this is the thing,
is because these are much bigger clients,
they kind of use the app for different things.
And this is the point.
So this DM feature, there's only one client does that.
Maybe we do that in the future.
We can call it, and what do we call it today?
The today page or the week?
Is it the week view?
I don't know what-
Yeah, it's the week view.
Yeah, it's its own thing.
Only one client and one group uses it
and we totally can move it.
It's not hard,
but there's no immediate value to moving them right now.
And if I can just point out as well,
what I like about the slicing idea here
is if we fix the community feed
and we did just that project,
the two clients that are over there on the right,
those are two different clients,
one for DM, a different one for week view.
They would both get the benefit
of us moving off the community feed immediately.
So they would actually get all that value.
They just wouldn't necessarily,
we don't have to switch the domain right off at the top
to get this over because we could,
and maybe we'd need to scope this in or out.
But I'm assuming when we fix community feed,
we're also updating the Flutter app
to now look at the API and not to Firebase.
Yeah, and that's why I think it's useful for us
to kind of break that Firebase to API in vertical slices
because that's, because I think if it doesn't exist
on the SQL in your MySQL,
it will be kind of easy to just create
and create new API routes.
But the work will be on the Flutter side
of replacing the current usage of Firebase
with the new API.
So if we break this down in smaller pieces,
we can kind of deliver value in the Flutter app.
Like, so for instance,
we just kind of did a rework of the feed
in terms of code base,
which is now a lot easier to,
it's a lot faster, it's smoother.
And if we add on top of this,
the changes to our backend,
then our whole feed, our whole community feed,
we'll have a new frontend code and a new backend code.
And we can kind of do these small slices
for all the other parts of the app
because currently a lot of our components
are the ones that are generated by Flutter flow.
And these are like, overall, they are poorly built.
So we can improve a lot of that.
And these can be connected
with this vertical slice in terms,
hey, if we are going to connect with a whole new API
and we are going to replace the Firestore,
then we can take this opportunity to,
instead of, let's say, using a infinite pagination pub
that we were using, that's like two to three years ago,
we can create our own component
and connect with our backend
and overall the experience will be smoother.
And we'll be moving out of Firebase
at the same time that we are, let's say,
improving the code base in the Flutter app
so we can think of it in vertical terms,
like we are moving the Firestore
and we also are improving the connections
and the way we handle the connection with our backend
in on the front-end side in the Flutter app.
So, and this is not even touching like the V2
on the JavaScript part yet.
And it doesn't even need to
for it to create value for the user.
It can be seen as a different part,
like the V2 on the JavaScript
can be seen as a different thing
that can be done independently
from the changes on the Firestore Firebase to API
and the changes on the Flutter
to connect with this new API instead of the Firebase.
Yeah, that raises an interesting,
that's interesting when I hear about V1 and V2 again
and this original code split.
I mean, I find things like that much easier to understand
if I'm inside of a vertical slice
that we're trying to accomplish and ship.
And I think that's also part of what made it challenging
in the beginning of the conversation here
is because there were these things like this V1, V2
and I think because they're horizontal,
it's just hard to get your hands around where do they stop
and what do they really mean?
you still retain all of the optionality
to approach any one of these things
how you want to approach it, you know what I mean?
With a code split or whatever,
but it's much more clear kind of why that's happening
and like what the payoff is
and like when you get to release something.
Yeah, I think we want to jump into the,
because we talked about this community feed thing
like months, months ago,
but we didn't want to jump into that,
I think without a holistic plan,
because there was this feeling of like,
okay, if we're committing to this overall migration
flutter to Firebase, cool, we got it,
that's the big overarching vision,
then all these other things kind of fit into that
in case we're like, if we make that one decision,
then it kind of feel, you know,
now it helps us make these other decisions faster
because we didn't want to go and invest all this time
moving community feed to the SQL in case we're like,
well, what if actually Firebase is the way,
you know, like you don't want to flip flop.
So now that we've made that big decision,
that kind of clarifies the rest of the things downfield.
And I'm going to comment something else
just because I love my black hat thinking.
Well, first of all, yes, yes, yes to everything
was fantastic.
I was approaching from like the 10,000 foot view
of like horizontal slice, you know,
we're going to remove all of these things.
I think vertical slice so much better,
but that kind of compromises are, and I think it's fine.
The kind of point in time that we're like,
we just switch completely off Firebase.
Cause if we say like, okay,
weak view is probably fine to like keep it somewhere.
So we will like keep Firebase
for like indefinite amount of time.
So I just wanted to mention that, which I think it's fine.
That's a really good point.
You know, I often think about that.
Like when we imagine like,
you know, like when we imagine a borderline with something
and we say like, you know,
like we're going to reach the end of the flutter world
and the end of the Firebase world,
there's going to be this hard cutoff,
but like usually in real framing and shaping,
you always ended with something that looks like this,
like a borderline that looks like this.
You know what I mean?
It's like, it's like a, almost like a, like,
like between real countries or States.
It's always like jagged.
Do you know what I mean?
Because what happened was you actually basically said like,
we gave ourselves a more specific definition
of what it means to be done with this thing,
which is that like all of these clients, except for,
you know, this is only two clients, right?
Who are here.
But the cost of getting all the way to this perfect shape
for to get to these two clients was what?
Like quite of a dish, there's a lot of,
there's a lot of work here, right?
For these two things.
Yep.
So, so this is a, this is a case where you're like, okay,
we're willing to make this compromise.
And then it basically means that like,
if the before was completely stop using Firebase,
you know what I mean?
The after, which is a little bit crispier
is all features for all customers,
except, you know what I mean?
These two clients are off of Flutter Firebase,
you know what I mean?
And this actually gets you what you wanted
when we were framing around like, we, you know what I mean?
Like, we're going to be able to develop new features.
It's the basis for the future
into the next five years, blah, blah, blah.
Like we get all those benefits here, you know,
but we don't have to spend the very,
we don't have that last mile problem
where we spend most of our resources
on the last mile that we don't actually need.
Yeah, that's helpful.
One comment that's interesting
because it's, it feels a lot safer
like doing this approach of like vertical slicing
and kind of accepting that some stuff
will be left behind at least for a while,
then like kind of trying to have the psychological relief
of like abandoning the old stuff
and moving to the new one
and having like this hard to cut points to do it.
It like feels that you have more relief at that point,
but actually it feels a lot safer
to have like this more flexible border
and to do things a little bit like smaller steps
in vertical slices,
because then we don't have to like compromise too much
and we can do things a little bit more gradually,
which I think is very important in our structure
that has like big customers.
Like we don't have like a lot of small customers.
We have fewer customers that are bigger
and we deal with them and they have.
lot of customers. So in this structure, it feels a lot safer if we can like, let's say almost
micromanagement the status of each customer and how and which customer has access to each thing.
So, and this structure of vertical slicing things allow us to have this flexibility
more than like, hey, let's do this. And like, because our original goal was to have like this
initial web JavaScript version that will be kind of allowing a few customers to access at the same
point. And looking at this now, I feel like we almost can do it more gradually and select more
in more detail, which customer will have access to each feature and at which point. So yeah,
I feel like safer when looking at this solution. That's right. Whenever you slice vertically,
you get a bunch of things for free. You get separated QA moments. You get separated rollout
moments. You get the ability to ramp up or feature flag things. You know what I mean?
Like there's things, there's a lot of that stuff in terms of deployment and testing and stuff that
it's not just this giant pile of a million things that all have to happen at the same time.
Perfect. That's good. And I think if we were to go and like, we've been doing a lot of framing
and shaping and breadboarding on the small. So I think if we like tomorrow to go and sit and do the
community feed, I feel like I don't feel any hesitation. Like I feel like we could knock
that out in two hours and have a really clear to do's on that. Cause it doesn't feel confusing.
I think this was helpful. Cause it's kind of like the, like zooming back, taking a step back from
all that. Cause now community feels like, okay, yeah, we could totally frame that, you know,
just like if a client was coming to us, we can do that piece very well.
Yeah. This is cool. It's kind of like you're using, you're using all of your skills that
you've been improving. You, cause you can, you can do those loops on each of these things now,
right? Like each of these things, you know how to do. And, and this was a little bit like this,
I think especially emphasizing this vertical slicing of how to look at this from the big picture.
Yeah. Yeah. I think this is a very helpful exercise. I know it's, you know, if you get into
the beginning, we were like kind of makes sense in the middle of it. You're like, I don't think
this is going anywhere. And then at the last 30 minutes, we're like, aha, we figured it all out.
It's part of it is like seeing your workflow. And we ran into some of this, even we started
getting deep with it and there wasn't yelling at each other. It was very respectful, but it was,
it can get tough. Yes. So between of some certain things, cause we were trying to drill down to
this. So I think it was helpful to see like how we would have, how we could have gone through it a
of it is also just doing it a second time and having to explain it all a second time.
For sure. We've kind of built out some neural pathways of how we have thought about it in the
past. But so this was helpful because it's, it, we, we haven't done anything on any of these
little boxes yet because we didn't really have like a whole picture. And so we're kind of just
in this like, quote unquote, like maintenance mode where we're just patching and fixing things.
I think this will be a good unlock at least for me, as far as, and I can see,
you know, if, if the community is four or six, it's a pretty, it could be a bigger project.
There's so many features that will come out of that, that are client facing that we would be
able to announce and say, okay, now that's nice and search your posts, you know, in the dashboard,
for example, because it's such an easy screen to create when all the data's right there,
but that was such a hard thing to do in the past. So, and then the one thing that's a little new is
when you're framing and shaping this, you know, I guess it's actually like everything else. Like
you have your appetite in mind, right? And, but your appetite is also fitting into this puzzle,
right? Of like, oh, the more weeks I put into the list, the more I take out of the 10.
And what about notifications or what about, do you know what I mean? Some other things that
might need thinking. So that's also just good to have in mind in terms of your sequencing.
There's certain things that you're going to want to do sooner because there's a technical
dependency, because as you said, like you need to migrate community feed first for technical
reasons. And then there it's, it's just like with scopes, it's going to be helpful to think about
some of these things we might, what are the things that if we ran out of time, we would be okay with
the fact that we didn't get there. And what are the things that if we ran out of time, we would
feel bad about that. So we should actually sequence those earlier. Yep. That's helpful.
Yeah. And that's just one comment because it's very interesting because
this, I think it's the first time that we are kind of having a project of projects,
like officially in some sense.
because one of our customers, which is Hackstack, basically it's exactly this. We have like this big
giant thing that needs to get done within like let's say one year and we are trying to vertically
slice it and but we haven't been doing like I almost say let's say unconscious because we
haven't like specifically thought about this way and but looking at it I feel like I almost want
to do a similar process in this sense like having this big box with all the smaller pieces and we
know that they need to be shaped but they need to also fit in this bigger picture of what's being
built and it's very interesting how we can kind of adapt that smaller appetite but to a bigger
project that has like almost one year of appetite but has this specific outcome in mind that
needs to be broken down into various things that already have delivery value by itself
so it's very useful in terms of thinking of our projects that are bigger and that will have
longer timelines like this one. Yeah, the pattern you'll see is we did some framing, there's some
framing around the 10-week appetite of like what do we get at the end of the 10 weeks which is
this and there was you guys work very clear on like why now is the time like where that to do
that you know and then there's going to be a little bit like frame shape on a per project
basis inside of that too so the same thing will happen with the client we're like they want this
monster thing if it's a project of projects then what's going to help is there's going to be that
first conversation with the client is going to be more at the like why are you willing to spend the
six months on this or the 10 weeks or whatever you know what do we have to get to at the end
and then there's the slicing inside of that of what are the major pieces that are going to get
us there and what's out also you know that's. Yeah, it's starting to make sense of like how
recursive this process really is. Totally, that's a great frame and then you're gonna frame the
scopes and then you're gonna just keep going. It's really like you wherever you are you can kind of use
it because this so basically what we ended up doing was actually we ended up we did we did
some framing and then this is actually kind of the shape right at this level at this monster level
you know and then and then you dive in and uh and and and then you you rinse and repeat yeah
that's good yeah and we started doing a little bit like uh john with x tech but i think this is a
better this is a better language around it because we started to look at just the time of okay it's
august they want to have something done by december there's just that much that is our
budget we have you know 12 weeks to work with of or whatever the the time's like um october
november december we've got the q q4 what are they basically where do you want to be at the end of
and what like and then we could kind of drill down to like oh well we really want to be able to like
sell an mvp okay well that's different than like so we kept it have some trade-offs of like maybe
you don't need all these features because the goal was to sell it right like that's a great example
of this macro framing like where do we need to be at the end of this and then that helps us make the
trade-offs of what's in and out yeah that's great that's cool perfect that's great awesome we've
still got 10 we've still got 10 minutes anything else that's in that's that's uh that's in your
minds yeah and uh i wrote chris i know you guys uh have touched the tribes of the least but
thoughts on i think i mean unifying it for better user experience would be huge i know it solves a
lot of headaches on you know our end you know the ones who are providing it but i think it makes it
way less confusing i remember i still remember that time when i was trying to figure out how do
and then you're like oh yeah you gotta go to this dashboard over here and it's just like why
and it makes sense now obviously right like the whole story of it but i'm so glad that we
i think for me like as we look at the frame of things it's like it gets exponentially bigger
until we can wrangle and corral all the things and that's the hardest part of this process for
me because my brain is like well what about this what this you know and just the way that you ryan
kind of put things together and um just kind of just kept digging deeper right until you hit that
aha i think that's great so thank you it's true that's that that really converging is is hard
right like getting more and more down to the nugget of what it is that's that's true
awesome and we
We've been doing, like Chris has been working a little bit
on like what we're calling like scouting out.
This was probably like a better,
but kind of going ahead of like,
cool, we've got the 12 weeks.
Let's start to like prep these projects.
It's almost like a step before framing
because some of these things-
Oh, that's a good word for that, scouting, totally.
Yeah.
What are the candidates that we might really try to get
through framing into like something
where we really want to do?
Yeah, and just getting, you know,
all of our clients touch different industries.
And so Chris has been digging deep with the clients,
digging into like how their business operates
and like what are the HIPAA requirements
for this particular project?
You know, we don't know that yet.
So we're kind of getting ahead of it a little bit
on getting familiar with it.
So we've kind of flipped it around
to where that's become,
that's our sales and marketing right there.
It's like the next thing we're going to sell
from a business standpoint
is going to be that thing.
So rather than like look up halfway through the month
and be like, oh my gosh,
what are we doing in September?
Like, you know, and then trying to like pitch something,
we're kind of like, cool,
let's get out a few months ahead of it.
And it kind of takes the pressure off.
And then everybody's been thinking about it
and sort of prepping it a little bit first,
you know, trying to crunch that down.
So that's one thing we've added the last few weeks.
I took on a fractional CPO role
and that was the first order of business
was like kind of building the pipeline
of like what might be a project?
What are we actually framing?
What's past frame go into shaping
and what's shape go into building?
Like that was, yeah, that's important.
And also just one quick comment
regarding what Chris brought,
that I think one of the major learnings
from this time together
that we are being able to like practice
and experience more is really about understanding
like that empirical feeling
of when things are like converging
and you almost feel that you want to start
as fast as possible.
Like you are thinking,
hey, I'm so confident about this
that I just want to like close this call
and like get into work
because everything is crispy clear.
And the interesting thing is that we had one experience,
me and Bruce that we shaped one specific part
actually regarding to the notifications.
I change, I improvement to our notifications
in your dashboard.
And we ended up the call with this feeling,
hey, we just want to get this done.
But I wasn't able to start at the moment,
at the same day.
We had some issues and I was only able to start,
I think almost one and a half week later.
But since we've got like the download
from our minds to the paper
and we got like that feeling of concreteness,
I almost, I just opened the notion
and it was like almost like that memory card
from PlayStation where you reload your save.
So I was like, hey, I just opened it
and I had the same feeling
and I was able to continue the work
from the point where we stopped.
So this is very valuable,
especially in working in this kind of agency style
where you are serving different customers
and you are context switching.
So being able to kind of memory card,
save to a memory card your work
and then continue from there,
it's a very important skill.
So, and being able to hone this feeling
and to understand and be able to grasp this feeling,
this is good enough and I can start working from here.
I think this is one of the major learnings
as well from these sessions.
That's awesome.
I love that.
Yeah, to kind of like save and load
the whole context of the project.
Yeah.
And just being patient with the process,
I know we're three hours into it,
but we've been on two or three hour calls
with different, and I'll be,
we'll be pretty far into it.
And we're like, cool, we got that moment of clarity.
And then we're like,
we'll go make a task grid later or whatever.
And we're like, no, let's,
if we just did it right now,
a little bit more patience.
And like, cause we, and then typically I'm like,
we'll have the whole task grid done in 10 minutes
or 15 minutes.
And typically from that point,
it is it's 10 or 15 minutes,
cause everything's fresh.
And then we've got this nice little hit list
to go do after that.
But it's just in previous times,
you don't want, we want to move on to the next thing
or switch context and then you don't really go deep
in this stuff.
It is, it is very deep.
You gotta go deep work style into it
and get the clarity.
So it's been helpful.
And I think also we've done
pretty much all these sessions have been
me and someone or two combinations.
of the two or three of us working together
and not trying to just sit by yourself and do it,
I think is helpful.
Yeah, that's key.
Yeah, totally.
That's awesome.
I want to just throw out some thoughts just
on the piece of the dark arts and pushing it a bit further.
Feels like we are refining this feeling of, oh,
have we got the aha moment?
Do we need to dig more?
And we get all those benefits that Giannata mentioned,
like we just pick it up and go.
And I'm just wondering, do we all have to be there?
Or you picked up this project page and you read it
and it's like, OK, it's not enough context.
The framing was not clear enough.
And I'm just wondering, OK, if we're all in the room,
then after that, write it down and we
can give it to someone else who is not just
going to read the whole thing.
And they have all of the nuggets that they need.
So I'm just wondering about that.
Does it translate to like, OK, we just transfer the project
to someone else?
We shaped it.
We all have the clarity.
And we just decide later, OK, someone else will do it.
Will they also have this clarity?
Does it translate?
Do we need to do a call with them?
So I'm just kind of reflecting on that.
So the more there's kind of like these two extremes in my mind
when I think about your question.
I've been in teams where we all did it all together
and we were all involved in every step.
And in that case, it's like the messy whiteboard
is kind of enough because we all kind of know what it means.
And the other extreme is I've got like seven or eight
different people who all need to play
different roles in this project.
And they're going to be involved in the process.
They're going to be involved at different moments
of the project.
And then I'm going to have like, so for example,
I just did a project with this team
that I'm doing fractional CPO work for.
I had three or four people who I was involved with in framing,
like framing and shaping.
And then when the kickoff started,
I had a totally different set of four people
that were coming into the project.
And what I needed to be able to do
was I wanted to be able to very quickly get people in,
like up to speed,
like I needed to be able to like load it into their brain too,
you know, as fast as possible.
And I knew that I would have to do it multiple times also.
Do you know what I mean?
So like, this is just for your eyes.
I think, but actually, I think it's very similar
to what you guys are doing, actually.
So this is a, this is a write-up for a project.
And you can see the frame is really, really boiled down.
And, but I think you guys are doing something similar.
And then in the end, the,
I wrote all this stuff out into this shape,
into this write-up for the shape.
But what's interesting is I noticed
I have to keep retelling the frame over and over again
to keep everybody like in the, focused on the right things.
And like when the scope starts to get too big or whatever,
like this is really,
I have to keep coming again and again back to the frame.
What I noticed is that even though I try really hard
to write this well, people just,
they don't really read it that carefully.
They miss things, you know, like it ends up,
so what it ends up being is I do refer to it
from time to time, but what I really rely on
when I have to transfer the knowledge
to another party is the kickoff call.
So when we have the kickoff session,
it's like, and other people are getting involved.
I spend a lot of time talking through this.
I make sure that everybody's on the same page.
And then I like really carefully talk through this,
like step-by-step, I like really talk through it.
And then a lot of questions come up.
We whiteboard, usually what happens
is we have to detail this.
So we're in the whiteboard changing this, you know,
cause somebody said, what about this?
And what about that?
And there's some things I didn't spell out,
and then we end the session
with a first draft of the nine boxes.
And that's basically like, so the frame I kind of,
before this project started.
and it was just in framing we had this document in our I'll show you our
bedding table so we have candidate frame go and shape go so when this was a
candidate and then when it was frame go it basically looked like where am I just
this top part you know and we kind of we got to a point of like yeah we got it
you know and I needed to be able to retell this to again and again so I
there was important for me to boil that down into like the right words you know
and then this I didn't write up until it was just before kickoff this was like
the last step for kickoff to give them to read in advance and to refer to to
make sure I kind of covered everything but then it's actually the kickoff
itself where I walk through this and then we do the scopes together where I
really feel like the transfer happens I don't know does that answer the question
or did I talk about slightly different things definitely very helpful yeah
yeah okay it's like a work of art but it's like you know it's but it's like
you know the actual work along the way is you know we had an initial frame here
first framing session I don't know first shaping session we came to a
reasonable shape this was the first shape and then we had some very big
unknowns so then I had a framing session again with a with a salesperson so
totally different person these are just a million notes but then a couple key
takeaways the answers then went back into a shaping session with the updated
frame you know and then and then we we you know kind of work through a couple
different approaches different UI issues you know and then and then in the end I
think this was actually this was the from the kickoff so then there was a
little bit of circling and talking through things calling out issues
looking at screenshots and then a little bit of spiking like on the spot kind of
clarifying a missing piece in the workflow and then we switched over to
MonsterMap and they did the nine scopes and that was that's what the kickoff
looked like. Okay, I love how iterative it is. It makes me feel a lot better because I feel like I keep failing forward a little bit each time.
Yeah those were so yeah so like what I like to do too is because like I I find
that if I keep modifying the same thing it can be really hard for me to pull
somebody's brain back to something we talked about before so that's why I'm
pretty religious about like if we really have different ideas doing the
ABC and then these vertical lines here are actually the breaks and sessions so
this was August 1st this was August 4th with senior engineer and sales you know
this was my packaging private work my private prep off and this is kickoff you
know so yeah so you get a sense of so that you know this case was not so this
was not super deep this was one two three shaping sessions and then a little
bit of private work on my part to package it up. You had some kind of spider
capabilities diagram thing over there too in the middle it's kind of interesting.
This we I think Lucian maybe we looked at that on a previous call so this is
this is the interdependency diagram so what happened was here's just just I'll
just I'll show you what it what what because you don't see what was in my
head because I did this for myself I know this is something I don't do with
teams usually because it's a little too nerdy but what happened was I had boiled
down these are the things that I need the team to understand at kickoff these
are these are all the things we designed so like I boiled down the
breadboard to basically like these things and like I'm like okay I need to
write this into a document I didn't know what order to put them in so I put them
around the circle and then use just this trick of like which one of these things
helps me to explain the other thing so it's like oh if I talk about failed
payments that helps me talk about the owner alert and if I talk about instant
retry that also motivates the owner alert you know so this is like getting
to the sequence of things and then this is just actually just there's a way to
just flatten it you know and then this is the flattening of it and then this
literally is if I go back to notion oh that's the wrong
I want Notion.
You see this sequence, failed contract, email alert, contract invoice screen, retry now.
That's the table of contents here.
That's failed payment, email, contract, sale fallback, instant retry.
It's like it's the, that's where that came from.
Yeah.
But that's, it's, yeah, it's, it's, it's, it's pretty nerdy, but like, um, I do have
moments when I, I just feel like, I don't know, I don't know where to start.
I don't know how to, you know what I mean?
Like, I don't know how to get through this and it, it unblocks me.
That's a trick from Bob.
That's cool.
Yeah.
That's these little, yeah, that just saying the process is very helpful like that.
Awesome.
All right, guys.
So I, by the way, I just want to praise you.
You're doing really nice work.
Like I, it's really cool how the sessions feel additive, you know, um, and especially
going from like individual projects up to the meta project this time, you know, that
was a, you know, that was a nice leap.
So, you know, thanks for that.
Yeah.
Thank you.
This has been great.
Awesome.
Cool.
All right.
Take care.
Have a nice day, everybody.
Thank you.
Take care.
Bye-bye.
See you.
Thanks a lot.
See you.