MARTIN OMANDER: Hi, Aron.
You told me the other day that you helped a small business
evolve their serverless app.
ARON EIDELMAN: Yes, I did.
As their business was growing, they
went through several iterations of their application
architecture.
MARTIN OMANDER: Couldn't they just have
picked the correct architecture right away?
ARON EIDELMAN: Well, at each stage of their growth,
they picked the minimum technology
to support their business, which I think was really smart.
By iterating their architecture, they
could learn from each stage, and they
avoided spending a lot of money upfront.
MARTIN OMANDER: Can't wait to hear more.
[MUSIC PLAYING]
MARTIN OMANDER: All right, Aron, what kind of a business is it?
ARON EIDELMAN: So it's a mobile hairdresser and makeup
business for special events, like weddings.
Unlike a salon, they perform the service
at the client's location.
MARTIN OMANDER: It sounds like a lot of businesses
are similar to that, like plumbers, electricians,
and so on.
ARON EIDELMAN: Well, I would say the one major difference is
that the quality of makeup and hair is much more subjective.
So the client and the owner really
need to have a strong mutual understanding
of what the service will be before the owner agrees.
MARTIN OMANDER: Ah.
So what was the first iteration of their workflow?
ARON EIDELMAN: It was very bare-bones.
They didn't have to write any code at all.
MARTIN OMANDER: What?
No code at all, Aron?
ARON EIDELMAN: Well, if a business
can get away with writing no code, they should.
It'll mean lower upfront costs and less maintenance
down the road.
MARTIN OMANDER: Yeah, that makes sense.
ARON EIDELMAN: So here it is.
Customers would call in to schedule an appointment,
the business owner would take the call,
and write down the appointments in a Google Sheet.
MARTIN OMANDER: Well, that's about as simple as it can get.
But it seems like a lot of work for the owner.
ARON EIDELMAN: Yes, it was.
And it wasn't great for customers either,
because they could only make appointments
when the business owner was available on the phone.
MARTIN OMANDER: Got it.
So how did they simplify the process?
They built a website?
ARON EIDELMAN: Yeah, for a while they
wanted to make a website that could display their work,
link to social media to follow the artists,
and answer FAQs about the services.
Still, they didn't want to write code for their own forms
or a back end to store responses.
MARTIN OMANDER: Yeah, it sounds like that
would be a lot of extra work.
Did they find a better way?
ARON EIDELMAN: Well, they hosted the site in Firebase Hosting
and put a link to a Google Form in their site that
would send inputs directly to their Google Sheets, which they
were already comfortable using.
And this is important.
They're designing this workflow around what they are already
good at.
So now customers could request appointments any time,
even if the owner wasn't there, but the owner
can still see everything the way they're used to.
MARTIN OMANDER: I like it.
Still not much code, besides a static HTML website,
but partial automation of their workflow.
So are they still using that setup?
ARON EIDELMAN: Well, as the business started to grow,
the owner was getting more client requests
than they could handle.
Likewise, from working in the industry,
they naturally started to meet other makeup artists who
would occasionally refer clients when they were overbooked.
MARTIN OMANDER: Ah, so the owner didn't need
to hire their own employees.
Artists could just work with them temporarily as needed.
ARON EIDELMAN: Exactly.
And the owner didn't want to share the entire Google
Sheet with these other artists, just the customer
information that mattered for the specific jobs
that artist was working on.
They also needed a way for the other artists
to give status updates, like job complete or appointment
canceled.
MARTIN OMANDER: So now they need to manage these artists
somehow.
ARON EIDELMAN: To an extent, but this part of the business
should run itself as much as possible so that the owner only
really needs to intervene if there
was something like a last-minute cancellation.
MARTIN OMANDER: And how would the existing architecture
help them with this?
ARON EIDELMAN: Well, the owner needed a different approach
for managing the other artists.
They wanted dynamic updates to and from Google Sheets
and some form of auth to only let assigned artists see
their specific clients.
This should be a separate experience from the front end
that customers see.
MARTIN OMANDER: Sounds like a developer
would be needed for that.
How did the developer build on their existing architecture?
ARON EIDELMAN: Well, the owner found a freelance developer
who could meet those requirements
at the right price.
Now the owner didn't insist on a particular tech stack or Cloud
provider, because those types of preferences
were beyond their expertise as an owner,
and they trusted the developer to use what worked.
The developer preferred containers
as a single deployment unit that could go anywhere.
MARTIN OMANDER: That's a good reason for using containers.
ARON EIDELMAN: Yeah, the developer's container
met the needs, it was easy and manageable,
and they deployed the whole app in Cloud Run
as a single container.
MARTIN OMANDER: Ah.
So they just connected the Cloud Run app to Google Sheets?
ARON EIDELMAN: Yes, and you did a video about that.
MARTIN OMANDER: Yes, I did.
I'll share the link in the description.
And after that, they were all done?
ARON EIDELMAN: Sheets worked great for them
at a small scale.
But as the business grew even further,
they felt the need for a proper database.
Sheets is really designed for several humans
to use at the same time, not for several applications
to be constantly adding or looking up information.
A sheet doesn't perform at scale compared to a proper database.
MARTIN OMANDER: Wouldn't moving to a database be a big jump?
ARON EIDELMAN: In this case, the developer
wanted to use Firestore, which would be a smooth transition.
It was easier for the developer to set up and connect
to Forms and Cloud Run.
And since Firestore is serverless,
it's much easier to set up and manage
than a self-hosted database.
MARTIN OMANDER: Firestore seems great for the applications
connected to it.
But what did the owner think?
ARON EIDELMAN: Well, remember, the owner
liked Sheets because they were familiar with it.
They could do weekly analytics to see trends
in their business, such as the frequency of new appointments
or what times of the year were getting
the most heavily booked.
And these aren't trivial issues either.
They affect pricing and the demand for artists.
So they're important for the owner to stay on top of.
MARTIN OMANDER: And it sounds like they
missed those requirements when they replaced Sheets
with Firestore.
ARON EIDELMAN: Exactly.
But this situation is easy to recover from.
These are pieces you can take out and put back in.
So Firestore belongs in the place of a database, yes,
but you can export the data to Google Sheets
to make it easier to analyze and navigate for the owner.
So with all the things we've added and improved--
MARTIN OMANDER: It all started and ended with a Google Sheet.
ARON EIDELMAN: So one thing that was really clear in this case
was the focus on the small business.
Even though it's a very simple application,
every business should care about keeping complexity
to a minimum.
MARTIN OMANDER: And it sounds like you
should be fine with updating your architecture
as requirements change.
ARON EIDELMAN: Yes, the idea that you
have this perfect image on day one just isn't reality.
And it's actually better to expect
and be able to adapt to change.
So owners need to make sure their needs are being met,
regardless of the tools, and developers should
have the freedom to build things that meet those requirements.
And I think one thing we noticed is that serverless patterns are
great at supporting both owners and developers because
of their flexibility.
MARTIN OMANDER: Well, thank you for sharing their journey
with us, Aron.
And thank you, everyone, for watching.
You will find a link to the other episode we talked about
in the show notes.
If you have any questions for Aron and me,
or suggestions for future serverless topics,
please enter them in the comments below.
We read every single comment.
Until next time.
[MUSIC PLAYING]